是否你已经将测试变成机械运动

今天收到我们经理的一封邮件，邮件的主要意思是一个项目发现手机开机后，来电无法呼入，呼出也失败，之后他们抓了log去给开发人员分析，开发人员A愤怒的指出他们测试方法不正确，抓包方法也不正确，同时测试人员自身也不先去思考问题原因，没有进行初步问题确认，导致最后开发人员花了大功夫分析后，根本不是软件问题，浪费了很多时间，由于这样的情况不是第一次出现了，所以开发人员A比较愤怒，所以发mail给测试经理，反映此问题，测试经理希望我整合出这方面的信息，对整个测试处进行宣导。看到这个mail，我先和开发人员A沟通了下，其实也就是劝他不要生气，我也告诉了他，其实类似的整合信息我也发布过很多次，同时也作了培训教材，但我知道没有几个人会去看，会去做，因为公司的测试已经开始变成了机械式的操作。

我早就发现公司每个部门的测试方式不一样的，但主要就是两派，一类就是测试出bug，并会追究软件问题原因，并思考相应回归测试用例的，一类就是只是完成测试用例，发现bug，提交bug，由开发人员修改，只需要一个最终的bug，或是开发人员修改这个bug，或是开发人员确定这个不是问题，他们不需要知道问题原因，也不愿意知道产生问题的原因，因为原因和他们没有关系。

我把我的观点和A说了下，他也非常无奈，因为确实因为测试人员的工作方式的原因，让她做了很多无用功，但是我知道这一切至少按照目前公司的测试文化来说，很难去改变。因为公司崇尚建立测试系统，大家开始变成一个机械化的测试工具，也许这样的企业文化是出于管理的模式，也许当每个人都把自己的价值转化成测试系统中后，人的价值在慢慢对于公司变小，而也许某天此人不在公司了，对公司的损失也最小，当然这只是我的想法，不代表公司的想法。

我相信我们公司的问题，并不是中国软件行业的特例，我相信很多企业也都是在糊涂测试中，所谓的糊涂测试我的定义就是能够将产品测试完成后交付使用，但是没有人能肯定是100%的测试过的，当然我指的100%测试不是指测试用例的100%完成，而是类似于代码100%覆盖测试。

所以我认为如果要测试作的更好，就首先别让自己的测试成为一个机械运动，而激发每个测试人员的积极性是每个测试管理人员需要做的事情，因为一个leader的测试方式深深的影响你的下属，鼓励测试人员多思考，多学习，多扩展所属行业的知识、信息，多交流，提高测试理论理解与测试技巧掌握。最大的发挥人的能动性，才是测试品质提高的一个重要因素，将测试用例在测试中完善，才能保证用户发现的问题越少，而机械的工作，只会变成客户常常反馈严重bug，用户对产品失去信心。