浅谈以缺陷数量作为测试人员绩效考核的弊端

《浅谈以缺陷数量作为测试人员绩效考核的弊端》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、缺陷数量可以作为测试效率的度量指标，例如：每千行代码中发现的缺陷数量、每天发现的缺陷数量。但是，缺陷数量是不是可以作为考核测试人员个人能力的度量指标呢？例如：用来评估测试人员的生产率、效率和技能？尽早和尽量多的发现缺陷是测试人员的重要测试目的之一。同时，测试人员提交的缺陷报告是测试过程中的重要工作产品的输出。由于测试人员提交的缺陷，在整个软件开发生命周期中具有举足轻重的作用，所以测试人员发现的缺陷数量也常常作为考核测试人员的指标。尽管缺陷是测试人员在整个测试过程中的重要工作成果和输出，但是，纯粹的缺陷数量

2、并不适合作为考核测试人员的指标。本文将从两个方面阐述其中的理由：首先，以缺陷数量考核测试人员并不客观；其次，以缺陷数量考核测试人员，除了不客观之外，由其引起的危害多多；1）以缺陷数量考核测试人员并不客观缺陷数量并不能很好的反映测试人员的工作内容，同时它也不能覆盖测试人员的各种测试活动。因此，通过缺陷数量对测试人员进行考核，并不能客观的反映测试人员的生产率和测试技能等。以缺陷数量考核测试人员，其不客观性可以表现在各个方面，例如：ü        测试的对象不同，例如：有的测试人员关注在以前版本的功能上面，而

3、有的测试人员负责新开发的功能上面。测试的实践经验表明，对以前版本的功能进行回归测试，发现的缺陷数目比较少，而针对新开发功能进行的测试，发现的缺陷会多得多；ü        测试类型的不同，例如：有的测试人员主要负责产品的基本功能测试，而有的测试人员进行非功能的测试。一般来说，非功能测试，例如：稳定性测试、性能测试等，单位时间内发现的缺陷数目比较少，但是通常来说发现的缺陷都是对客户而言是比较严重的；ü        开发人员水平的不同，例如：针对类似的功能模块，对于新手或者没有经验的开发人员，可能在模块开发

4、过程中引入更多的缺陷，而经验丰富的开发人员则可能更好的避免缺陷的引入。因此，负责测试没有经验的开发人员开发的模块，相对来说可以发现更多的缺陷；ü        功能模块复杂程度的不同，例如：有的功能模块复杂，而有的比较简单。因此，在相对简单的功能模块中，可能可以发现的缺陷数量比较少，而复杂的模块中可能会发现的更多；ü        缺陷可检测性的不同，例如：有的缺陷是产品图形化界面的显示问题，比较容易发现，并且容易复现和问题定位；而有的缺陷，例如：长时间测试导致的系统重启，不仅耗时耗精力，并且难以检测和难

5、以复现；ü        测试的目的不同，例如：有的测试人员主要负责在开发阶段的测试，其测试的主要目的是发现缺陷；而有的测试人员可能更多的是在用户现场测试，那么他们的目的可能更多的是证明我们的产品是可以正确工作的，发现缺陷并不是他们的主要目的；ü        测试的工作不同，例如：有的测试人员可能将更多的时间和精力放在测试文档的设计上面，例如：编写测试规格说明；而有的测试人员主要负责测试执行；ü        缺陷发现的阶段不同，例如：有的缺陷是在早期的软件工作产品的评审过程中发现的，而有的是在测试执行

6、过程中发现的；ü        ……上面罗列了在不同测试条件和环境下，发现缺陷的数量是可以迥然不同的。因此，不考虑测试人员之间角色和职责定义的不同，而统一用发现缺陷的数量作为考核的基础，显然是不合理的。2）以缺陷数量考核测试人员危害多多以缺陷数量考核测试人员，除了存在前面讲的各种不合理和不客观之外，它还可能会引起各种各样的危害，从而影响整个产品的开发，例如：2.1）为了缺陷数量而查找缺陷人，不仅是测试人员，都擅长于改变个人的行为，以满足被考核的指标。假如以缺陷数量作为考核测试人员的指标，尽管测试人员会更加

7、积极的查找缺陷，但是他们可能更多的的关注在如何快速的增加缺陷数量，而对严重程度高和难以复现的问题缺乏足够的重视。例如：测试人员会将关注点放在容易发现的、肤浅的、表面的缺陷，以快速的增加缺陷数量，而对难以发现和定位的缺陷，其重视程度不够；或者，为了达到缺陷数量的增加，提交一些类似于已经存在的缺陷报告；2.2）降低测试团队的地位假如测试人员的考核将依赖于他们所发现的缺陷数量，开发人员知道测试人员会为了增加缺陷数量而改变自己的行为（参考上面的2.1），那么开发人员就会怀疑测试人员提交的缺陷，例如：测试人员是否确

8、认这是一个缺陷，还是他们只是为了增加缺陷的数量？导致开发团队和测试团队之间合作的危机。另一方面，假如测试人员为了追求缺陷的数量而提交了很多表面而肤浅的缺陷，开发人员会对测试人员提交的缺陷的价值产生怀疑，从而对测试人员的测试能力和技能产生怀疑，他们会说“测试人员只能发现一些肤浅的问题，不能发现一些重要的问题和缺陷”。从而导致测试团队在整个研发团队内因为能力和技能不能得到认可而地位低下，测试人员的声音越来越小，也得不到应有的重视。