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

Garfield_Cat

昨天回家的路上突然想到的一些内容，然后参考《软件测试项目管理》和网上的一些文章总结的，一起讨论吧。

    每一个测试经理都面临这样的问题，如何对测试人员进行绩效考核。因为测试人员参与的工作不单一，需要的技能也各种各样，考核测试人员的绩效似乎不是很容易的事，除了一般需要考核的对工作的态度，工作的责任心，积极性这些方面以外，还有一些其它方面的内容。
    要想对测试人员进行考核，就需要开始工作的时侯明确测试人员的职责，对测试人员的期望等，一个团队中不同的测试人员可能职责不同，比如测试负责人，测试设计人员，自动化测试人员，普通测试人员等，那么对这些人的期望也是不同的，进行绩效考核的时候需要根据对测试人员的期望进行考核，而这些职责和期望测试人员也是很明确的。
   测试人员可能参与不同的软件开发过程，比如需要参与需求和设计的评审，那么也需要对这些工作进行考核，比如需求评审时可以从测试人员对需求的理解上，测试人员对需求提出的问题的质量上等作出评价。
    如果需要测试人员准备测试文档，如测试用例等，那么可以通过评审测试文档来考核一个测试人员的能力。如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段一个测试人员的能力。
   对于执行测试的测试人员来说，可以从测试人员所发现的问题对测试人员进行评价。测试人员所发现的问题是复杂的还是简单的，是隐藏比较深的，还是一些表面的问题。还可以从问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。或者测试人员书写的问题是否是自己的操作问题，一个问题是否写多遍等。
    而对于已经发布的产品，也可以从用户反馈的问题来考核测试人员的绩效，但是这个可能需要的时间比较长。
    测试人员的沟通能力也是考核的一个方面，无论是书面的还是口头的，测试人员都应该有较好的沟通能力。
    另外测试人员的接受指示，把握细节的能力也应该进行考核，测试经理希望把任务分配给可以按照指示完成的人来完成，如果测试人员自行其事，即使技术能力比较强也对工作无益。
    首先我们不能单纯的以测试人员提交的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有足够充分的理由和足够准确的描述可以说明问题，让开发人员没有借口来为自己辩解。开发人员对于这样的问题会有很好的印象。所以我觉得让开发人员来评估测试人员的表现可以作为考核测试人员的一个重要依据。

    上面只是我今天上午把昨天晚上的一些问题总结了一下，考核确实很难，也很难找到好的标准来考核。对于考核的一些常规标准，大家都知道，我就不多说了。

上面的只是想跟大家讨论讨论。看大家有什么意见？？ 可以联系我，MSN：jiw_han@hotmail.com

swallow0918

恩，这个问题也是我们公司测试部门最近在考虑的问题。感谢楼主给予了一定的启发。

testuser99

正在考虑绩效考核.感谢楼主的贴子.
关于最后一点,让开发人员来评估测试人员的表现。有点疑问.
因为开发人员的绩效是通过本身代码的质量,工作量等评判的,所以有可能不能客观的评价测试人员的表现.

walker1020

谢谢楼主的提示！ 最近我在组件一个测试团队，正在考虑怎么样合理公正地对测试人员进行考核呢。

Ironside

谢谢楼主
我也正在准备这方面的资料。
说实话，考核是最痛苦的事情，其中会有很多主观的因素在里面。

testying

谢谢共享 我正在组件一个测试团队，上面的内容可以参考

sense

不错，可以结合一下，但真正做起绩效考核的难度还真不是一般的大啊

archonwang

1：有效bug率 用来衡量测试人员发现的，被确认为缺陷的有效缺陷比率，比率越高则测试质量越高。这个比率剔除被开发人员拒绝修改和删除，以及重复的bug之后，剩余缺陷数占缺陷总数的一个比率。测试人员不能只重视bug的数量，为了让领导感觉测试人员每天都在工作而随意的提交bug，从而导致bug数量很高，但质量很低。造成很多bug都被拒绝修复或者bug不能重现以及bug重复报告等问题。

衡量bug率的情况是否有标准？bug不能重现的问题和重复报告bug的问题，需要管理人员进行筛选甄别。


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

如果贵公司在前端的需求管理和需求变更上控制很严格，那么才有实施的意义，否则很可能就是无效考评标准。每个测试人员独立负责项目测试，进行该衡量必要，但是要注意前端支持和保障信息通畅。

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

还是那句老话，描述到什么程度可以称之为Good？现在很多公司都使用了缺陷管理系统，可以简化放彼岸对bug描述内容的控制，问题还是在于我们是否具备这种传达和沟通能力。很难理解这句过于宽泛了，建议楼主读下《bug提交的艺术》一文。

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

严重bug率的考评似乎和测试人员的关系不是很大，更多的还是和开发有关。我们可以从测试的不完备性上对重点的内容进行控制，但是不可能全部。例如：需求的问题，如果不参与需求过程，不参与调研，如果没有数年的行业经验，几乎是无法发现的。再比如，系统架构及设计上的问题，如果没有一定的开发经验，是不能发现这些极其严重的问题的。

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

这点很重要，大多数公司都是采用这个量化指标来衡量测试的整体质量的。当然在划分责任的时候，往往是以后续提交的问题的类别进行的，例如，bug或是需求变更等等。出现bug，就要检查用例设计中是否涉及到对应的用例，是否属于测试范围之内，当时版本是否测试通过等问题，不能一刀切——实质上是对数据归档和管理工作提出要求。鉴于目前，大多数公司在这一块的投入和实质性的工作方面，所存在的问题，可能需要设立专门的组织进行管理，例如QA。

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

不管怎样，不可以让开发人员来评估测试的表现。这会增加几个问题：
1. 开发人员和测试人员往往对质量的意识和概念是不同；如果仅仅是通过bug的提交数量和质量来评定，内部就可以解决，不需假手第三方；
2. 开发人员和测试人员在一定程度上存在矛盾，即使目标是一致的。对于测试人员的工作表现及缺陷质量而言，开发人员有发言权，但不是绝对发言权，最有发言权的应该是测试部门的部门经理/组长。如果在流程上，测试人员是直接通过开发确认和修改问题的话，那么最直接的不良后果，要么是同流合污，要么是水火不容——这些情况都不是我们所乐见。如果开发和测试在组织级别划分上没有对等，就很难产生公正公开，更别说公平了。
3. 个人认为对测试人员最有话语权的还是测试部门的负责人，对应的开发部门/项目负责人也具备对等话语权，对测试人员的考评最终应该是数位相关的人员的共同协商的结果。


[ 本帖最后由 archonwang 于 2008-11-20 10:06 编辑 ]

歇斯底里

就最后一点来说，我认为让开发人员来评估测试的表现未尝不是一种方式。这个是体现测试人员的工作是否得到了其他人员的认可，这一点也是很重要的，如果工作得不到大部分人的认可，我认为这是失败的，如果在你提交一个bug后，开发说：“恩，这种情况我确实没有考虑到，我改一下”那就是说他认可了bug，同样也认可了你，这样的结果就是测试人员最希望看到的。但是这也要求测试人员在有一定的测试技术的同时有良好的沟通力和协调力。
其实在绩效考核中，即使有很细的标准，也不可能真正做到公平。通俗的说，有时候人缘好，交流能力强的，往往会比较占优势。只能是尽量做到公平。

liulinzhu

#10说得不错
#9的版主：有一定道理，但从根本上考核不是目的，而是手段，希望版主能理解这一点。

woza

以BUG数之类的作为考核标准不是很可取，而且有可能向个人传递错误的信息。
尽量以团队考核，代替个人考核。以整个团队能否在规定时间内完成任务为标准会比较好。当然，这个任务量必须是团队能够接受的。
个人感觉，传统方式的考核对于软件质量的提高没什么帮助。对于团队建设也没有什么帮助。不过，目前我也还没发现什么非常好的考核方式。

Lola1123

对于一个管理不健全的部门来说，要制定绩效考核制度，难题

Lola1123

与销售人员的考核有本质的区别，测试人员的考核难以量化，如何保证绩效考核中不存在主管的意见，头疼啊

ericzhou2009