关于测试人员绩效考核的一点儿想法

每一个测试经理都面临这样的问题，如何对测试人员进行绩效考核。因为测试人员参与的工作不单一，需要的技能也各种各样，考核测试人员的绩效似乎不是很容易的事，除了一般需要考核的对工作的态度，工作的责任心，积极性这些方面以外，还有一些其它方面的内容。

要想对测试人员进行考核，就需要开始工作的时侯明确测试人员的职责，对测试人员的期望等，一个团队中不同的测试人员可能职责不同，比如测试负责人，测试设计人员，自动化测试人员，普通测试人员等，那么对这些人的期望也是不同的，进行绩效考核的时候需要根据对测试人员的期望进行考核，而这些职责和期望测试人员也是很明确的。

测试人员可能参与不同的软件开发过程，比如需要参与需求和设计的评审，那么也需要对这些工作进行考核，比如需求评审时可以从测试人员对需求的理解上，测试人员对需求提出的问题的质量上等作出评价。

如果需要测试人员准备测试文档，如测试用例等，那么可以通过评审测试文档来考核一个测试人员的能力。如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段一个测试人员的能力。

对于执行测试的测试人员来说，可以从测试人员所发现的问题对测试人员进行评价。测试人员所发现的问题是复杂的还是简单的，是隐藏比较深的，还是一些表面的问题。还可以从问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。或者测试人员书写的问题是否是自己的操作问题，一个问题是否写多遍等。

而对于已经发布的产品，也可以从用户反馈的问题来考核测试人员的绩效，但是这个可能需要的时间比较长。

测试人员的沟通能力也是考核的一个方面，无论是书面的还是口头的，测试人员都应该有较好的沟通能力。

另外测试人员的接受指示，把握细节的能力也应该进行考核，测试经理希望把任务分配给可以按照指示完成的人来完成，如果测试人员自行其事，即使技术能力比较强也对工作无益。

首先我们不能单纯的以测试人员提交的bug数量进行考核，那样的结果可能会导致测试人员为了bug 数量而互相攀比，导致bug质量的下降。

所以我觉得下面这几点可能会更合理一些（仅供讨论）：

1：有效bug率用来衡量测试人员发现的，被确认为缺陷的有效缺陷比率，比率越高则测试质量越高。这个比率剔除被开发人员拒绝修改和删除，以及重复的bug之后，剩余缺陷数占缺陷总数的一个比率。

测试人员不能只重视bug的数量，为了让领导感觉测试人员每天都在工作而随意的提交bug，从而导致bug数量很高，但质量很低。造成很多bug都被拒绝修复或者bug不能重现以及bug重复报告等问题。

2：测试覆盖率主要用来衡量测试人员对功能点遗漏测试的情况。我觉得这适合测试组人员较少的公司，每个测试人员要单独负责一个完整的项目，在这种情况下，进行这样的衡量是有必要的。

3：bug描述质量主要衡量测试人员对于bug报告的描述情况。bug报告的描述是否清晰、简洁。开发人员是否能很容易的理解并依据报告描述重现bug。很多情况下开发人员拒绝修改bug是因为bug报告的描述很难理解，并且依据描述不能重现bug等。

4：严重bug率主要是根据严重程度分类的缺陷数比全部缺陷或者有效缺陷。这有助于让测试人员将注意力集中在关键问题上，减少产品的致命缺陷。

5：市场反馈缺陷率产品正是发布推向市场后，客户在使用产品的过程中发现的缺陷数占缺陷总数的比率。用来总体衡量测试组整体的工作情况。

6：最后一点，让开发人员来评估测试人员的表现。我不太肯定这样做的效果会怎么样？我的想法是：测试最直接的服务对象是开发。开发人员对于测试人员所报告的缺陷进行确认，修改（或者拒绝），对于测试人员的工作表现以及缺陷质量来说，开发人员是最有发言权的。当一个质量很高的bug被报告的开发人员那里，他们是很乐意接受这样的问题，因为你报告的bug有足够充分的理由和足够准确的描述可以说明问题，让开发人员没有借口来为自己辩解。开发人员对于这样的问题会有很好的印象。所以我觉得让开发人员来评估测试人员的表现可以作为考核测试人员的一个重要依据。