在本专栏的前几篇文章中，我们提到了敏捷测试的概念、组织，以及敏捷测试中的自动化测试组织方式。在这篇文章中，我试图来讨论一个更加困难的话题——敏捷测试中工程师的绩效管理。众所周知，绩效管理从来都不是一个容易的工作。甚至，我认识一位测试经理，他视绩效打分和沟通为畏途，每到季度结束需要为员工做绩效的时候就格外紧张。

　　为什么绩效工作不容易？从我自身的感受以及听到的抱怨中，主要有两个方面的原因。首先是评价标准的确定。对测试工程师团队来说，通常测试工程师都会分散在不同的项目中，追求建立一个“公平的”标准非常困难；其次是在对绩效工作的理解上，绩效工作包括目标设定、绩效评价、绩效跟踪、绩效沟通几个主要部分，但不少测试管理者仅仅把重点放在绩效评价上，忽略了目标和基于目标的沟通，导致绩效工作变成了一个单纯的打分，这样自然引入了许多的问题。

　　首先来看看测试工程师的绩效管理。设定绩效目标是绩效管理的第一个环节。我以为，对绩效目标正确的理解是建立合理的绩效评价原则和体系的前提。例如，“发现的缺陷数”和“编写的用例数”大概是最多的测试组织对测试工程师绩效评价的标准，那么这个标准是否合理？实际上，在实践中，“发现的缺陷数”并非一个好的衡量成员工作的指标：首先，不同的项目中，缺陷数量本来就不同，发现缺陷的难易度也不同；其次，并非每个缺陷都有相同的价值，发现缺陷的数量多不见得意味着发现的缺陷的质量高。既然这样，为什么“缺陷数”仍然成为了大多数组织的绩效衡量标准？我想，主要的原因，恐怕在于这个数据具有典型的“量化”特性，在一定程度上反映了测试工作的状况，且具有表面的“公平”的特性。

　　1. 设定绩效目标

　　在讨论这种方式是否合理之前，我们先讨论绩效目标本身。为什么要为测试工程师设定绩效目标？答案可以是“为了发奖金”，但在我看来，奖金的发放只是对绩效完成好的员工的奖励，而绩效目标本身是对团队成员的一种指引。简单的说，设定绩效目标是为了让员工明白“组织期望你做什么”，通过这种设定来达成组织的目标和期望。所以，设定一个绩效目标的目的不是为了“绝对的公平”，而是为了让所有的团队成员都明白“怎么做才是组织期望的”。设定“发现的缺陷数”作为主要的绩效指标只能导致一个后果：所有的团队成员都把自己的价值定位在“发现更多的缺陷上”。表面上看，这样并没有问题：测试团队的工作不就是发现缺陷吗？这里有一个有趣的虚拟场景（这个场景是我最喜欢的，用来挑战这种衡量标准的场景）：

　　测试团队成员A加入了P项目，在开始的一个月中，平均每个版本他能发现50个缺陷；半年后，A可以在每个版本中发现100个缺陷。你认为他应该得到很高的评价吗？

　　从“发现缺陷的数量”上看，显然，成员A做得非常出色。但是，如果从项目的角度来看呢？这个项目的质量显然越来越糟糕了。这样岂不是非常危险的信号：“测试团队所期望的目标和组织的期望是背道而驰的”？太糟糕了。

　　为组织中的测试成员设定什么样的绩效目标才合理？简单的说，取决于组织的目标是什么。在敏捷环境下，我们期望整个测试组织能够持续的提升生产率，能够持续的提高产品质量，因此，在设定绩效目标的时候，需要把员工的绩效目标与组织的这些目标牢牢的绑定在一起。此外，目标本身需要是可度量和衡量的，因此，从生产率和提高产品质量等角度入手，可以考虑以下这些绩效目标：

　　（1）提高生产率

　　　　● 更短的产品的发布周期

　　　　● 更短的测试周期

　　　　● 更少的产品测试迭代次数

　　（2）提高产品质量

　　　　● 更少的线上缺陷

　　　　● （同样测试覆盖率下）更少的系统测试中缺陷数量

　　　　● 促进更好的代码质量

　　（3）促进可测试性

　　　　● 单元测试覆盖率

　　　　● 接口和系统的自动化测试覆盖率

　　　　● 促进更好的可测试性