测试员的工作效率和所查毛病的数量

测试员的工作效率和所查毛病的数量

测试员的工作效率是否应该用所查毛病的数量来测量？回答“不可以。”我原来以为这样的衡量方式是正确的业绩衡量方式。但是这种想法只能肤浅地表达一个测试员工作业绩，而且在不同的因素影响下，和不同的情况下，是无法真正反映一个测试员的业绩，如果简单利用测试员在一定周期内找到的毛病数量来评判业绩，对测试员来说是不公平的，同时会促使测试员以对抗的态度和开发者较劲，将合作关系变成相互歧视的关系。

有许多各种因素能够影响一个测试员找到的毛病的数量，举几个例子来说，如果一个测试员进行头到尾的测试，他的测试任务中很大一部分时间用于清理系统，重装系统，然后进行测试，在整个过程中，测试占用20分钟，这些清理和重装需要4小时，这样的活动，肯定会影响找到的毛病的数量。这并不是一个很好的例子。因为很多步骤可能可以自动化，然后提高测试员的工作效率。但总有一些情况下，手动安装是必须或是必须等待自动化安装完成，然后才能进行测试，由于这些活动（清除，重装）花掉的时间过多，而给测试的时间段过短而造成测试员无法查找更多的错误。

著名的测试专业培训师和作家Cem Kaner曾经提到过一个案例，在一个工程开发完毕后的测试中，他手下的一个测试员在测试自己的部件时找到很少一些毛病，但是这些毛病的影响是很坏的，这些毛病的数量远不及其他测试员找到的多。当时开发组的老板对这个测试员发现的毛病的数量不够信任，于是要求Cem Kaner再增加更多的人手来进行同一方面的测试，Cem Kaner找了一个资深的测试员协同那个原来的员工，两人后来一直没有发现太多的毛病，但是两人还是找到了一些很糟糕的问题。这些重大的问题把整个产品的推出时间推后了6个月。在工程结束后，后来的测试员高度赞誉了前面的员工的工作。再后来等到产品卖出后，客户在这个部件中发现的问题和其他部件相比是微乎其微。

我在测试过程中，发现另外一个问题，就是开发者的工作能力和测试员所发现的毛病数量是成反比的。开发者的设计水平越高，测试员在其产品中找到的问题也是越少。我曾经对两个不同程序员开发的部件中进行源码测试，第一个是很有能力的，第二个就有点马虎。我在第一个程序员开发的产品中找到几个问题不大的毛病，但是在第二个程序员的开发的产品中找到找到不少各总各样的问题。这也说明产品自身的质量好坏决定测试员拿到产品后所发现的毛病数量。这也顺便带出一个新的问题，如果测试员接到一个已经经过不少修改的产品，里面的能找到的毛病数量已经很少了，这个测试员不一定能在测试过程中找到多少问题。还有就是测试员自己的技术问题，刚出校的大学生，和刚从开发者转变成测试员的，技术不一定很好，这也会影响他们找到的毛病数量。对这些新人，不能苛求发现的毛病数量。

如果测试员在老板的允许下，进行流程改进，自己设计开发自动化测试工具，为以后的工作奠定基础，但是一时间没有足够的时间进行测试，这也会影响自己找到的毛病的数量。或是帮助新人适应工作环境，给新人提供问题解答，这也会影响自己找到的毛病的数量。同时也影响很多好的测试员花费时间在文档总所有这些例子，还有更多各种各样其他未列举的例子都能很好地说明不能轻易用毛病的数量来说明一个测试员的业绩。

如果老板使用毛病的数量来说明一个测试员的业绩会造成什么后果，首先，测试员会故意将影响力小，微不足道的各种毛病，甚至已经存在的毛病报告出来，以增加自己发现的毛病数量。这种做法浪费所有人的时间，开发者，老板，测试员。开发者会开始怀疑，甚至轻视测试员的报告造成毛病泄漏错误。同时造成开发者测试员之间的政治性冲突。再者，测试员会开始制造大量肤浅测试案例来进行大网捞大鱼的，他们不会用心设计覆盖面更深，更复杂的案例来找出潜伏更深，影响更大的问题。使用毛病的数量来说明最终是个很不公平的做法，它能伤害好的测试者在帮助他人，仔细做好文档总结工作，在测试中花费时间来设计更好的测试工具和改进工作流程， 甚至妨碍测试员之间的技术交流，和帮助新人上手。

在考核测试员的业绩方面，没有什么准确地手段能百分百地保证主管来进行公平的评估，最好的方法是注意每个人的日常动向，向测试员周围的人来问取这个测试员的平时的工作能力，交流能力，在测试中有没有做出什么贡献。从其他方面也可以评判测试员的业绩，比如他的毛病报告的质量，他的文档总结，他在工作实践中的工具开发，他和其他工作人员的交流互动等等。考核要全面，才能显示管理者的开明和公正，也能显示出管理者对整个项目的进展有一定的了解，让大家信服。作为管理者，时不时地关注下属的工作进度能够帮助评估一个下属的工作业绩。管理者最好能了解每个员工保证完成的任务和期内真正完成的任务来对比，获得下属的实际工作进度。管理者通过了解和下属工作的开发者的反馈，诸如测试员能够查找出重大的毛病问题，能够为开发者的设计提供建设性的建议，能够分担毛病解析，能准确详细地描述毛病。管理者所要做的另一件事是，和组里其他的测试员了解属下的工作情况，看看属下是否帮助其他组员解决面对的问题，是否能够很好地进行工作上的交流，是否和其他组员一起合作做好本职工作，在本职工作的基础上能够完成更多的工作等等。最后，在评估时，要了解下属的在工作范围内外所完成的任务，在整个开发中发挥的作用等等。只有这样才能给测试员公正的业绩评估。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1516436