测试人员的绩效考核应该如何开展？？（09-3-2）（获奖名单已公布）

默默巫

企业越来越重视对员工的绩效考核，对于一些传统的计时、计件类岗位工作比较容易确定考核的指标，但是对于测试人员来说，如果只凭Bug的数量、用例的数量这些简单的指标来衡量并不是很准确，而且每个人负责的模块不同，针对的开发人员技术水平不同
也有很大的差别。尤其是随着时间的推移，在项目结尾阶段发现的Bug数量肯定会减少。那么针对软件测试人员，该如何设定考核方式、使用指标、评判标准等内容呢？


如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	摆饐ＰǎＳe	当当购物卡50元	16#
二等奖	zte_boy	300论坛积分	7#
三等奖	阿七	100论坛积分	23#

相关文章：

测试人员能力考核方法—业务能力掌握程度考核

软件项目成员的业绩考核面面观

软件测试工程师考核标准

更多内容请点击＞＞＞

kuailederen

想想这个问题，测试人员的绩效考核，有几个公司做了？又有几个公司做好了？即使强制做了，下面的人员全部接受吗？
我也经历过做绩效考核的公司，基本存在以下弊端：
1.浮于形式型。
   公司要求这么做，部门就这么做了。做了以后并不影响个人的利益。
2.经理一人独断型
   无论有没有具体考核内容，但经理不理会这些，自己凭自己的主观最后打分。
3.不公平型
   没有经过实践，就相当的觉得以数据说话最公平，于是就以执行用例数，发现缺陷数等为标准。我亲自经历过这样的事，自从
以发现缺陷数为重要考核标准后，大家都争着测文档，一个错别字提一个缺陷。。。。何必呢？
4.敢怒不敢言型
   这种是与工资挂钩的，或者末尾淘汰。他们考核的无非也是从工作量，积极度和看得见的数据，
整不好，你在埋头苦干，却告诉你被淘汰了。怪谁呢，只怪你不会做面子工程。

绩效考核大家都理解，提高效率，提高质量，说白了就是节约成本。
我觉得绩效考核有几个工作外的东西必须考虑进去。
1。文化背景
   一个国家的文化背景。在中国就不适合做互评的考核，让同事一起打分。就象让你指出别人的缺陷一样让人不知所措。
  一个公司的文化背景。公司的文化氛围，团队氛围。
2.公司发展定位
   人力资源管理上讲，一个处于迅速发展期的公司，不适合做严格的管理制度和考核办法，公司应该鼓励员工去积极的发挥
  个人能力，因为公司要靠这个迅速发展；而一个处于稳定期的公司，却要通过比较严格的制度来维持这种稳定；处于衰败期的公司，
  最需要制定严格的制度来控制成本。
3.公司测试制度的完善程度
    一个测试团队如果连最基本的测试制度都没有（我指的是测试体系方面），比如你连鉴定缺陷等级的细则都没有，连有（无）效测试  用例的标准都没有，你凭什么来统计这些数据？
4.测试团队对考核制度的支持情况
   如果被考核的人都觉得制度不公平，太片面的话，那最好别执行了，心理抵制比言行抵制更可怕。
    鉴于上述，我想公司给测试人员做绩效考核，要根据具体情况来实施。

下面我分析的要考核那几方面：
1.工作量：
这是无可厚非的，不干活的人是没有绩效的。
2.工作质量：
写出无效用例多，提交的缺陷开发看不懂等，负责测试的模块有明显的重要缺陷却视而不见。（注意不能以偶尔现象为准则）
3.工作态度：
这点很容易理解，就是不好好干活，应付任务。
4.工作角色。
为什么说只凭工作量不公平呢，因为测试是分角色的，比如测试组长，他可能很多精力放在沟通和进度跟踪，缺陷跟踪
  等其他方面，而执行的用例较少。所以不同角色不通对待。
5.贡献度。
在工作过程中，凭自己的特长，为公司测试过程改进，测试方法提高，测试团队建设做出突出贡献者。比如编写出测试工具，
  极大提高测试效率。
6.挽救风险。
  比如测试已经结束，但他还是凭着怀疑精神坚持自主测试，在上线前测试出重大问题。

总之，测试部门考核的目的是为了提高测试水平，规范测试流程，约束自由懒散者，鼓励个人智慧的发挥等。所以，
我觉得范有违这个目的的考核，还是不做的好。

最后补充一点，测试工作并不是独立存在的，它要与其他部分配合工作，我们很难把测试部门单独考虑做考核，我所经历过的是
以项目为单位进行考核，只要与这个项目有关的所有人都绑在一起，这样比较合理。
另一点，某个考核标准如果采集数据或者是依据，如果比较困难，麻烦，那么这点基本不可取了。还是那句话，脱离了实际的一切行为都是纸上谈兵。

[ 本帖最后由 kuailederen 于 2009-3-5 15:04 编辑 ]

zajy

初来咋到，还 希望 多多指教 啊 ！

xinwuhanqqm

学习中！

lansemogu1985

作为一个测试人员，受教了。

lcyrb

才看到
学习一下吧

sogoc

说白了，就是要看考核的最终目的！
大家都知道，考核的最终结果难免会在工资上提现！
一个没有人情味的公司是不太可能的，一个没有人情味的主管也是不太可能的，考核带有片面和主观性，导致结果也不是很让人满意或者不公平！
考核的形式是以奖励形式还是淘汰制度只能根据公司实际情况出发
我觉得大家讨论来讨论区的实际意义并不是很大，从根本上来说，大部分人只关注一个地方：工资！
从根本上来说，如果你的工资比别人高不少，那你去搞末尾淘汰制度吧，如果你的工资跟别人差不多，还是不要去搞这个末尾淘汰的，免得人员都走光了，不是我偏激，这是事实，不管怎么考核，都有不公平的，比如说用发现BUG的数量来考核，又不是所有测试人员测试同一个模块来发现BUG率的比较，而且不同人测试不同模块甚至系统，而BUG多少主要是靠程序员的程序把握，虽然测试人员很重要，但是程序员如果控制得很好，BUG可能就会很少了，甚至很那发现。

潇潇雨语

好贴，谢谢！

阿七

原帖由 puchonghui 于 2009-3-6 23:23 发表
懂得软件工程的人都明白数据积累的意义，其中很重要的一条就是便于对个人能力和特质进行衡量。
没有经过长期的数据积累是不可能进行有效的绩效考核的。 所谓的绩效考核纯粹都是一些欺上瞒下的形式主义。

23#的表格就是个典型例子。 整个表格都充满了含糊不清的界定，比如第一项：

由于不严格不认真，导致工作出现了疏漏，且没有及时补救；
工作出现了问题，但能够积极补救，不推卸责任；
1 如果我尝试去补救了，怎么才算及时？怎么样又算不及时？
2 事实上碰到问题只要不先想着推责任，首先去积极补救就行。 如果确实是别人的责任，当然应该别人为后果负责。

还有什么迟到早退，只有分不清人跟机器的区别的人才会拿这种弱智标准去衡量技术人员。 至于规定迟到10分钟更是拍脑袋的扯谈，难道这和迟到9分59秒有什么本质区别么？ 只要我该做的事情做好了，你管我什么时候来什么时候走。

不想多说了，忠告喜爱类似考核的人： 如果没有一定量的数据积累，不要去试图做什么个人的绩效考核（上级有要求的话自己想办法应付），把实际精力致力于有效的团队建设才是正道。

１　及时... 　　比如你在ｔｅｓｔ一直没测试出来，等模拟部署的时候，才测试出来．导致程序又要修改，重新ｔｅｓｔ到模拟到真实部署
　而不及时　就是你在真实部署完了　，好久都没测试出来，导致客户使用出了问题

２　至于迟到问题，　我们公司是用ＯＡ系统考勤，不是用打卡机，所以定义了１０分钟为迟到时间，比如你迟到了９分针５９秒．ＯＫ　我不算你迟到．但是要扣考勤分．而且类似这样３次，就直接扣钱，但是迟到１０分钟１秒．ｓｏｒｒｙ了　你迟到了，直接扣钱了.

３　我不知道你为什么这样愤世嫉俗，也不知道你高人说的"把实际精力致力于有效的团队建设"是如何做到的，我只知道公司必须要有刚性的制度和人性化的管理才能使团队有序．

４　另外想说的是，越是害怕考核的人，越是无能的人．生怕别人发现自己的缺点．

完了...　　　看样子你会跟帖ｊｊｗｗ的．．．

deanaa

对于测试人员的绩效考核确实是一个很头疼的问题。我觉得应该是主客观相结合，个人发展和项目/部门利益相结合来考量。
主观的评定主要是根据部门主管，项目主管，项目测试组内部，项目其他组的综合评定来定性\定量评定。评定的依据应该包括工作态度，主观的工作能力，学习能力，管理和领导能力，沟通能力等等。为了在主观评定中尽量减少由于个人喜好导致的评定不合理，可以由HR或公司层面制定一个评定指导，根据每一项来打分。
客观的评定则主要是根据统计数据来进行评定。包括工作量（用例编写数量，自动化测试用例数量，执行用例数量，发现缺陷数量等等），工作质量（缺陷遗漏率等）的评定。客观评定可以最大程度的减少人为因素在评定中的影响，但是随着软件行业的发展，软件复杂度的提升，个人英雄主义已经逐渐被团队精神所取代，所以客观评定还是应该和主观评定相结合。

我想说的很重要的一点是个人发展和项目/部门利益相结合的考量。
对于软件行业来讲，人毫无疑问是决定性的因素。我们在整个管理过程中，对人的尊重也是越来越重要的一个方面。当然在绩效考核中我们不仅要考虑项目/部门利益，也需要考虑到员工个人的意愿。这就需要在制定考核目标和进行考核的过程中充分听取被考核者的意见。在项目\部门利益保证的前提下，我们应该尽量满足个人发展的要求，为个人发展提供有利的环境和条件，把考核转变成为帮助员工实现个人发展的一个催化剂，只有这样，才能使公司和部门获得最大的人力资源效益。

lky3

我们这里是多个人员共同打分。

puchonghui

懂得软件工程的人都明白数据积累的意义，其中很重要的一条就是便于对个人能力和特质进行衡量。
没有经过长期的数据积累是不可能进行有效的绩效考核的。 所谓的绩效考核纯粹都是一些欺上瞒下的形式主义。

23#的表格就是个典型例子。 整个表格都充满了含糊不清的界定，比如第一项：

由于不严格不认真，导致工作出现了疏漏，且没有及时补救；
工作出现了问题，但能够积极补救，不推卸责任；
1 如果我尝试去补救了，怎么才算及时？怎么样又算不及时？
2 事实上碰到问题只要不先想着推责任，首先去积极补救就行。 如果确实是别人的责任，当然应该别人为后果负责。

还有什么迟到早退，只有分不清人跟机器的区别的人才会拿这种弱智标准去衡量技术人员。 至于规定迟到10分钟更是拍脑袋的扯谈，难道这和迟到9分59秒有什么本质区别么？ 只要我该做的事情做好了，你管我什么时候来什么时候走。

不想多说了，忠告喜爱类似考核的人： 如果没有一定量的数据积累，不要去试图做什么个人的绩效考核（上级有要求的话自己想办法应付），把实际精力致力于有效的团队建设才是正道。

archonwang

阿七的答案比较实用点。之前曾给测试部门做过一个绩效模型，改天发上来。

believe

1.bug数量、严重重度、优先级等比例
2.有效bug与总bug数的比例
3.根据实际情况（如：阶段性测试），对bug把握程度是否恰当，下阶段的bug点数
4.无效bug数的比例
5.跟踪bug情况
6.所提bug的深度、广度
7.遇到有歧义bug是否有强的说服力

阿七

一个季度  考核一次

阿七

项目组自评表

评价指标	典型行为或事件举例（参照标准）	自评得分	自评说明	上级评分	上级说明	最终得分
严格认真	（1分）由于不严格不认真，导致工作出现了疏漏，且没有及时补救； （2分）工作出现了问题，但能够积极补救，不推卸责任； （3分）按本岗位工作要求做，没有出现工作疏漏； （4分）发现他人的工作疏漏，告知对方，并协助其补救； （5分）严格认真地履行岗位职责，发现隐患，并预先采取措施，避免问题的发生。
主动高效	（1分）被动执行上级安排的工作，遇到困难被动等待，对工作中的问题视而不见； （2分）反应工作中的困难和问题，但没有改进建议；——至少没有主动去思考问题， （3分）主动调动各方面资源，以达成目标； （4分）工作中主动发现问题，提出有价值的改进建议； （5分）独立提出确实可行的解决方案，并推进实施，并取得良好的成效。
服务意识	（1分）不关心客户的需求和感受，对客户提出的需求没有响应。 （2分）在上级要求和客户投诉的压力下，为客户解决问题； （3分）积极响应客户意见投诉，及时满足客户的需求； （4分）主动征询客户的意见与感受，并以友善愉悦的态度提供服务； （5分）提供的服务，超乎客户期望的满意度。
团队协作	（1分）不与团队成员沟通，完全按照个人设想来工作； （2分）告知团队成员自己的设想，但不响应团队成员提出的建议和要求，固执己见； （3分）能够认真听取团队成员的意见，修正个人的工作设想； （4分）当他与团队成员意见发生分歧的时候，不仅能够听取对方的意见，而且能够提出有价值的建议； （5分）在协助对方获得成功，并达成团队整体目标的同时，实现个人目标；
纪律意识	上班时间是否经常打私人电话或发送短信（经常的定义为：考核周期内5分钟以上的打私人电话或发短信达9次或以上）； 是否经常迟到、早退（经常的定义为：考核周期内10分钟以上的迟到和早退达9次或以上）； 上班时间是否浏览与工作无关的网站； 上班时间是否看报纸、杂志和与工作无关的书籍； 上班时间是否大声喧哗或吵闹； （以上每一项行为，否为1分，是为0分）
学习总结	（1分）多次出现相同的失误； （2分）能够不出现相同的失误，但不能防范于未燃； （3分）在工作中学习，能够从失误中吸取教训，举一反三； （4分）有意识地学习岗位要求的知识、技能，和业界先进的经验，并在工作中加以实践； （5分）在岗位要求的知识技能以外，还主动学习与他相关的知识技能，工作能力明显提高；
合计

项目组内部互评表

——测试方面

一、
完成工作量情况
A、
季度内在整个测试组中完成的工作量最高；
B、
季度内在整个测试组中完成的工作量较高（处于中间水平之上）；
C、
季度内在整个测试组中完成的工作量一般（处于中间水平）；
D、
季度内在整个测试组中完成工作量较低（处于中间水平之下）；
E、
季度内在整个测试组中完成工作量最低。

二、
测试过程质量
A、
测试过程质量令人放心, 基本能全部测出一般情况下的Bug外，还能测出隐藏很深的Bug，项目交给他进行测试把关很放心，在整个测试组来说，相对是最好的；
B、
测试过程质量较好, 基本能全部测出一般情况下的Bug，隐藏很深的Bug偶尔能测出，在整个测试组内来说，处于中间水平之上；
C、
测试过程质量一般，能测出大部分一般情况下的Bug，但总觉得欠火候，在整个测试组内来说，处于中间水平；
D、
测试过程质量较差,有些一般情况下的Bug都不能够测出来，或者总是那下某个功能点，在整个测试组内说，处于中间水平之下；
E、
测试过程质量极差, 有些明显的Bug都不能够测试出来，在整个测试组内来说，相对是最差的。
说明：
指提交功能测试开始到项目最终发布的测试过程质量。有些人测试过程质量很好，总体上能够把基本问题全部揪出来，而且还能够揪出一些隐藏很深的问题（当然，我们不能指望揪出所有的问题）。而且还有很重要的一点，这些人能够很早的把问题发现，而不是等到快最后来发现（不是说快最后的时候发现问题不提）。其实，作为一个开发人员，还是很欢迎测试揪出问题来的，但缺很厌烦快到最后了，才把它揪出来，心里总会想，为什么不早发现呢。而有些人测试过程质量就很差，很多很基本的Bug都测不出来，而且还丢三落四的。搞得最后都提心吊胆的发布系统。
其实，测试过程质量，虽然表现在整个开始测试到最终发布的过程，但实际上与前期准备工作还是很有关系的，就像系统实现过程质量与需求和分析设计的质量很有关系一样。测试准备工作做得好，测试用例想的很周到，编写得很全面，而且能够按照测试用例认真逐个执行，再加上实际测试过程的一些功底，测试过程质量就会明显的好。

三、
测试用例编写质量
A、
测试用例编写质量很好，编写的内容除少量细节外，一般一次可通过，在整个测试组来说，相对是最好的；
B、
测试用例编写质量较好，编写的内容虽然有些时候通不过，但明显看出，是经过认真思考了的，在整个测试组内来说，处于中间水平之上；
C、
测试用例编写质量一般，虽然由于能力有限，存在比较多的问题，但文档需要描述的各个方面都已经想到了，在整个项目组内来说，处于中间水平；
D、
测试用例编写质量较差，其内问题较多，且需要描述的好多方面，都没有提及。不过经过讨论后，修改的质量很好，在整个项目组内来说，处于中间水平之下；
E、
测试用例编写质量很差，文档只是涉及到了梗概，很多细节都没描述到，讨论后修改的结果也不理想，要修改多次，或者因为别的原因，没有达到要求还是放过去。在整个测试组内来说，是相对最差的。
说明：
指测试用例提交评审的质量。有些人写文档前想的很周全，文档也写得很仔细，提交出来的文档基本上一遍就可以通过。而有些人写的文档，提交出来讨论，一遍未通过，讨论完了改，改了再讨论，而且很多细节也没有写出来，搞得负责审核的人，最后没办法，就直接改。因为叫当事人改，还不如审核人自己改来得省心。当然，测试用例的编写质量，在测试过程中会反映出来。

[ 本帖最后由 阿七 于 2009-3-6 11:24 编辑 ]

moondall

测试人员的考核是很多方面的。。
经常有不公平的情况存在。而且，最重要的，我觉得要让测试人员知道考核结果啊。
我们公司很怪，考核完了，什么也不说，也不通知 。你到年底也不知道公司考核的到底是个什么标准，什么结果。。

月野幻儿

月野幻儿

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

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

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

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

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

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

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

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

    当然我想不同的公司的绩效考核制度不同，不能一概而论，自己总结而已。
转载自qingyue2008的文章
http://www.51testing.com/?uid-11 ... space-itemid-103728

gongju

我们现在针对于测试人员的考核主要基于以下几个大的方面：个人的工作质量、项目组内其他人员的评价、客户对系统的反馈综合来进行考虑。

1、个人工作质量
主要考核测试各个阶段的测试用例设计、测试用例执行情况、缺陷提交情况以及测试提交物的质量。
2、组内人员的评价
主要考核项目组对你的沟通、工作态度，团结协作情况，给你进行考核的有其他测试人员，开发人员等等。
3、客户反馈
主要将系统上线试运行后客户发现的问题做为一项考核指标，因为这个最直接反馈出项目的质量，反馈问题的严重度直接影响到你的考核分数。但是这个周期可能会跨度很长。

都说考核不是目的，但是还是希望能够依据考核结果来鼓励测试人员更好的工作，好的就是要给予奖励，例如绩效奖金、推荐培训等等，总是不好的肯定要处罚和淘汰了。



顶

我要我的快乐

测试人员的绩效考核应该如何开展？

关于“测试人员的绩效考核应该如何开展？ ”的问题，本人结合实际，总结了以下几点：

一）熟悉测试人员的工作职责，根据测试人员职责内容执行情况进行评估

    一般测试人员的工作职责包含三大块：

    1）测试前的准备工作
    测试需求的提取，这是测试人员测试时是否明确测试需求的一项非常重要的指标
    测试用例的编写和细化完善，编写较好的测试用例是可以比较全面的覆盖产品的各项功能急功能点，而且通过编写测试用例可以让测试人员非常深刻全面的了解产品功能。
    测试计划的制定，实际测试时就可以检验测试计划制定是否合理了
    测试环境的搭建，通过该项工作也可以反应测试人员实际是否细心收集客户问题环境及相关的需求环境。

   2）测试执行，在测试执行过程中会有bug的提交及bug质量情况，测试人员对bug的描述是否简洁明了，bug优先级的把握是否合理，是否只追求数量不追求质量等都是可以看出一个测试人员实际的工作效率的。

   3）测试总结及相关测试文档的编写。


二）制定合理的工作计划，根据测试计划执行情况进行评估

    一般绩效考核是对测试人员一段时间内的工作进行考察，那么制定一份合理的工作计划是非常重要的，一般组长会协助测试人员

安排好一段时间内的工作（临时插入工作也是在所难免的），然后制定好计划提交给经理确认，最后双方签字确认后，工作计划便生

效，测试人员在实际工作中就要按计划执行了，绩效考核时工作计划达成情况及计划之外的工作情况（计划之外就需要领导细心掌握

了）对于领导来说是一项非常重要的指标。


三）有相关的流程规范遵守及执行情况

    一般每个公司都会有一定的工作流程，作为测试人员对测试流程的掌握情况是需要非常清楚的，而实际测试人员对流程的遵守及

执行情况也反应了测试人员的工作态度，这也是绩效考核时一项重要的指标。


四）测试相关的经验交流

    可以定期组织一次测试经验交流会议，通过交流，领导也可以初略了解到测试人员理论及实际技能提升水平。

五）测试人员心态情况

   良好的心态对于测试人员来说至关重要，所以作为领导要随时能够了解下属的心态，领导可以根据下属的心态波动情况进行绩效考核评估。

总之，只要大家用心观察，工作绩效尽在眼底了。

[ 本帖最后由 wanghua2009 于 2009-3-5 00:18 编辑 ]