51Testing软件测试论坛

标题: 测试人员绩效考核 [打印本页]

作者: hzjceshi2009 时间: 2012-3-1 17:08
标题: 测试人员绩效考核
公司要求我编写测试人员绩效考核，内空可查看附件希望各给点意见

作者: nakasnake 时间: 2012-3-2 11:18
个人不太喜欢把加班作为考核内容
有可能出现加班完成本该工作时间内就该做的事
一般把加班算到工作态度项里进行考核
全部客观不现实，而且也需要掌握一定的主观评价权力

作者: archonwang 时间: 2012-3-2 16:35
我更建议以一段时间之后的用户反馈bug数量作为测试有效性的依据和考核依据。这个比较真实一些。

另外，个人觉得若计划充分，加班应该扣分。

加班期间测试出的Bug是平常的Bug分值的2倍，员工加班可按小时个数加分（1分/小时）
这个规则有点坑，感情这里1分大概能等于多少RMB来着的。如果不能，那这个还是算了。

举例来讲，一个项目的测试出来各阶段的bug数量是可以估算的。粗略的说，一个N万行的系统，所能接受的bug数量应该是多少是可以定义的。所以，觉得以bug数量作为考核依据实在有点不妥。

作者: archonwang 时间: 2012-3-2 16:36
1.若是代码错误方面的Bug分值相应的要增高
2.若是界面优化、标准规范方面的Bug则分值要相应减低
3.若是需求变动、新增需求这个要跟项目经理确定后若修改后对系统使用和界面更符合客户则分值可相应的再增高些

这些个觉得是没啥用？增高怎么计算，减低如何计算？

作者: archonwang 时间: 2012-3-2 16:38
若是在测试前用来写测试用例则分值正常打分，若是边写边测则用例分值要扣除一半（因主要分值都体现在Bug上），若是测试完成再写用例则用例分值就是正常的4分之一

这种情况要建立在良好的开发过程上，如果本来开发过程中决定了测试必须在编码结束后介入，又因为上线要求的关系，必须在特定时间内上线，对测试人员而言，起点就是不同的。

在大量的实践中，边写用例边测试的情况很常见。但是用例内容应该是和测试内容错开的。已经编写用例的部分才能进行测试。

作者: archonwang 时间: 2012-3-2 16:40
整个文档中，对于加分和减分的部分规则是很不明确的，也没有上下限的说明。

比如这种情况：
了解客户的需求　以小时来打分，1小时1分。
晕，整个测试过程中，假设：我花了10天解读需求，那么岂不是一下子就80分了？？

作者: ll110 时间: 2012-3-6 14:44
说实话用bug数量来量化不行的，测试人员发现多少bug和开发质量有关。个人觉得bug的数量和严重程度可以用来考核开发

作者: luol1986 时间: 2012-3-6 17:02
持续学习中哟，最近部门也是喊我出一份测试组的考核办法，有点头疼

作者: 泡芙拓 时间: 2012-3-8 20:44
顶！顶

作者: 31463683 时间: 2012-3-12 20:17
回复 3# archonwang

我比较反感用BUG数衡量一切，但是没有BUG又不能说明一切。所以bug只做辅助考核

作者: love682 时间: 2012-3-13 14:05
我觉得用测试后发布上线之后，用户发现BUG的问题数作为考核测试人员的指标会更有参考意义。

作者: chaomimi 时间: 2012-3-13 15:50
我是新来的

作者: xuli107 时间: 2012-3-14 09:43
个人认为这份考核没有人会同意的，太含糊了而且不符合实际

作者: valiant 时间: 2012-3-14 11:02
新来的啊不知所云

作者: mogaochao 时间: 2012-3-14 11:28
其实大概差不多就可以了，不过这个绩效还是让所有员工进行查看通过并同意，就可以执行了，执行一段时间后可以再次召唤员工来多一次会议讨论嘛。

作者: missoflong 时间: 2012-3-14 16:38
这个业绩考核一般。
个人观点：
1. 上级安排的任务，是否有效时间完成
2. 加班是因为上班的时候不给力造成的，还是的确一直在忙，工作量大造成？这个玩意儿很监控，最好的方法就是参见第一条
3. bug的数量与测试、开发都有关系，所以不要考核数量，更多的关注流出去的bug，当然也要看项目的大小，大项目应该流出的比较多，可以算流出率
4.用例的质量，不能看个数，要看有无遗漏的用例。一条用例可以拆成两条写，也可以并成一条写，这就是漏洞

..........

作者: forsomething 时间: 2012-3-14 23:29
说实在的，这份考评太复杂，可执行（可量化）性不高。
其实要评价一个人，3~5项最关注的指标就可以分出优劣。
另外，加班我不提倡，正常的工作安排是不应该有加班出现的。
考核缺陷数量，需要有其他辅助，只算绝对数量会造成考核出来的排名和你心目中的排名差很远。

作者: hzjceshi2009 时间: 2012-3-16 15:21
回复 6# archonwang

谢谢 archonwang 给的意见，首次写这个东西，看了你的意见才知自己考虑的很不全面。

作者: hzjceshi2009 时间: 2012-3-16 15:28
公司目前考核测试人员，就是以Bug为主来考量，若设计绩效时把Bug数量为辅这样好吗？

作者: ff411 时间: 2012-7-5 15:00
谢谢。。。学习

作者: barcelona 时间: 2012-7-6 20:15
开发初期需求的饿分析 bug的预测这个很重要开一个人的前瞻性
bug的质量
沟通能力表达能力
文档的标准化能力
就这么简单

作者: tianlong1285 时间: 2012-7-7 17:04
学习了

作者: sharonioy 时间: 2012-7-13 10:33
目前我们制定的测试人员绩效考核大概为以下（供参考）：
指标项：
1、测试项目按期完成率；
2、缺陷提交（缺陷数量，及时性、有效BUG数）；
3、测试文档的规范性与是否及时提交到配置库；
4、测试进度跟踪反馈的积极性；

Smart项：
1、经验文档的提交；
2、培训与学习交流；
3、周计划和周报的提交；
4、工作态度（责任性、勤勉度、团队合作）；
5、综合能力（测试技能的提高、公司产品的熟悉程度、创新、沟通能力）

作者: 爱apple 时间: 2012-7-13 14:13
不喜欢绩效考核

作者: xiao_haozi 时间: 2012-7-20 12:14
实行过程不好衡量

作者: gyyflying 时间: 2012-7-31 16:40
考核的内容中很多人应该都会有些意见，真正实施结果与实际情况很可能落差很大。。。

写测试人员的考核绩效，首先要了解测试的工作。。。了解的越深入。。。相信写出的绩效表越能考核出测试人员的价值意义。。。

作者: mainer 时间: 2012-8-16 17:08
建议发起外部360，让该测试接触的开发人员、产品人员、技术经理对他进行打分和提意见，加入到绩效中。

作者: lintongyan 时间: 2012-8-16 18:56
凭啥要把加班纳入绩效，不该用bug的数量和回归的数量来考察一个测试人员的绩效，模块不一样，bug量本身就不一样，不公平也没有实际意义。可以考虑反正看，可以用遗漏的bug来考量

作者: 斯琴彪娃 时间: 2012-11-23 11:04
个人认为应该将质量和效率看重一些，其他都是次要的。
比如质量方面：重点是客户反馈问题和bug数量
效率方面：看测试执行效率和测试设计效率（毕竟效率高的测试人员花费的工作量较少，降低成本）

作者: 志在远方 时间: 2013-2-18 14:19
公司目前考核测试人员，就是以Bug为主来考量，若设计绩效时把Bug数量为辅这样好吗？

作者: kellyangl218 时间: 2013-2-19 15:02
QA 第一大考核指标当然是根据任务的完成情况在打分，任务超额，按计划或者的没有按时完成等情况来打分，以下几个方面就是作为辅助
1. Case覆盖率和bug的发现率是两个重要指示
2. 还有就是bug流出的多少，以及严重程序来设定扣分的值
3. 发现bug后，当开发修复后，是否在规定时间内验证，对于其他状态的bug也可以设定一个考核的标准
4. 加入其他合作部门的印象分
5. 提出的建议，书面，口头的，是否被采纳的
6. 提供的知识分享次数和质量以及受群情况
7. 测试报告是否及时反馈
8. 团队合作，对其他人的工作是促进，帮助还是拖了后腿，或者需要提供帮助的时候，没有积极响应（这是一个态度问题）
9. 沟通能力

作者: Sky-Test 时间: 2013-2-25 09:32
呵呵，参考下还是可以的。感谢提供。

作者: Miss_love 时间: 2013-11-8 10:47
考核感觉覆盖面应该更加广些

作者: goopy 时间: 2013-11-19 15:07
这个要是执行下去，测试人员估计都会走光的

作者: 68480850 时间: 2013-11-20 15:25
谢谢分享，学习中...

作者: Zgi46Z 时间: 2013-11-25 15:07
好多啊，哈哈，谢谢您

作者: jiangbiqing 时间: 2013-11-27 11:37
考核是个难题，很多东西还是需要评估人员更加的用心才行，如果太主观、片面，估计团队凝聚力就差了。还是要多方面考虑。建议加班不要算在考核里面

作者: barcelona 时间: 2013-12-4 10:22
案例数量质量。然后bug 多少兼考虑下系统的复杂度安排的任务完全的及时性有效性文档邮件日志写的规范性沟通能力发现问题的能力

作者: ishare0755 时间: 2014-1-3 16:14
不应该鼓励加班

作者: vivilin 时间: 2014-2-13 10:02
测试考核指标，供参考：
一、硬性客观指标：
工作数量、工作质量、工作效率
统计日常测试任务（有工时、计划完成时间、实际完成时间），可知数量、效率；
抽查测试过程文档、测试流程执行情况、发布后问题反馈、项目组反馈等，可知测试质量
二、参考主观指标
收集项目组、维护组反馈：沟通、协作、积极性、有价值的评审意见等
三、技能学习与提升
测试手段、工具、专业理论知识积累等

作者: auto_tester 时间: 2014-3-5 12:34
haha,学习中

作者: wuzuohui 时间: 2014-11-5 15:53
千万别个BUG数量来考核，我都准备修改考核方式了，用BUG数来考核测试真的不公平。也不好量化。现在我们是以客户反馈的BUG做为量化点。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)