写一份关于测试部奖罚制定方案，大家一起讨论。

zhong3269

目前测试部，想自拟一份关于测试部的奖罚方案，

奖罚目的：为了加强员工质量意识，促进和保持公司员工工作积极性和自觉性。

我想对于每个测试部这样的制度，这样测试部的全体员工更有积极性，更有责任心。

希望大家参与讨论哦！！！！！ 如过现成的制度希望分享哦！！！！我觉得这是好事

但不知道如何下手。提笔难写。

楠族开心果

为什么一定要有惩罚制度呢？

zhong3269

我呢，最近亲自参加一个新的项目，与大家分享一下，我觉得从以下几条
1.工作流程，是否都按着工作流程工作，比如：没有需求盲测，不需要冒烟的冒烟等等。
2.测试计划，一个新项目或者一个新功能的测试是否按着测试计划一直在做（这条跟周报配合最好）。
3.用例的覆盖率，每周是否有更新用例，好的测试方法当然推广并奖励。
4.特殊能力，这个特殊能力的人也不是一般人能做到的，光用QTP写自动化脚本不算什么，是否能自己编写一个独特的测试脚本、自动化脚本和性能脚本，能写出测试工具那就大大的奖励。

Circleyq

回复  coolchen
不可取！发现一个大问题，你就奖励500，那是不是开发的人就要扣掉500啊！测试人员和开发人 ...
wangsc_testing 发表于 2010-11-22 14:02

    支持你的观点，这种方法也许能激励测试人员更努力去工作，但破坏了团队

guoguo2005

人是有创造性的
不能如此量化

test_me

1、每位员工一天寻找BUG票的任务是10个，超过10个的每个票奖金10元（BUG明码标价：逻辑BUG，功能性BUG每个5 ...
Scott86 发表于 2010-11-12 16:40

“每位员工一天寻找BUG票的任务是10个，超过10个的每个票奖金10元”，设计或编写这个软件或者是产品的太LJ了吧，一个员工一天就算找10个bug，就算这个测试组有5个人(我们组是10个人)，一天最少找50个bug，别说时间很长，就算一个月或一个季度(我们项目测了2年多了还在继续)下来有多少bug了。
所以我觉得以bug数量来衡量的话不是最有效的方法。
我认为每种bug设置一定的权重，每个月或者一个季度按照某种算法计算每个人的值。在这里bug的权重、算法以及结果达到多少算工作合格或者是效率达到了，这些都是有公司或者项目组自己来设置

test_me

回复 12# Scott86 “每位员工一天寻找BUG票的任务是10个，超过10个的每个票奖金10元”，设计或编写这个软件或者是产品的太LJ了吧，一个员工一天就算找10个bug，就算这个测试组有5个人(我们组是10个人)，一天最少找50个bug，别说时间很长，就算一个月或一个季度(我们项目测了2年多了还在继续)下来有多少bug了。
所以我觉得以bug数量来衡量的话不是最有效的方法。
我认为每种bug设置一定的权重，每个月或者一个季度按照某种算法计算每个人的值。在这里bug的权重、算法以及结果达到多少算工作合格或者是效率达到了，这些都是有公司或者项目组自己来设置

wangsc_testing

回复 7# coolchen
不可取！发现一个大问题，你就奖励500，那是不是开发的人就要扣掉500啊！测试人员和开发人员本来都是软件质量保证的一部分，这样做只会鼓励测试人员整天找开发人员挑刺，破坏团队合作的意识，而且，测试人员抓住一个问题不放，而和开发人员讨论，那势必会影响项目开发进度。考核测试人员可以从测试用例的覆盖率、缺陷探测率、缺陷维护是否及时、测试报告是否符合标准化等等来考核

篱笆藤萝

关于这个问题，我们公司有个需要改革又找不出很好方案的制度
测试是按工时计算的，每月有工时数，完成则是满工资，少了就扣，往往开发有时候任务很多就可能超，不过此机会相当小，大多时候是不够，所以扣得时候比较多。还有测试人员每发现1个bug奖测试0.5个工时，扣开发0.5的工时，总之这样有很多问题，想了讨论了很久也找不出一个好的办法激励测试人员好好工作，及早极多的发现软件问题，保证测试质量。

netwalker2000

回复 16# liangliang1


    我也觉得不能“按bug量来做惩罚奖励，bug的多少并不能代表测试部人员的能力”，建议考核包括如下：
1.质量，是系统上线后发现的问题，此类问题越多则质量低，要惩罚
2.效率，是系统没上线前测试人员发现的问题数，此类问题越多则效率高，要奖励

moonjew

--测试用例交流补充别人的，奖20-100。没有被比别人补充的，奖100。
--测试总结交流互相打分，高于平均分20%的，奖100-200。 低于平均分50%的，重新总结。
如果我注重员工互相学习，那么就会设这种交流和总结的内容。

要看你的管理目标，不能盲目地列一堆奖惩项目，那样得不到效果，反而让大家反感或者不重视。积极性和责任心这种东西太空泛，你从理论上就没办法说谁不积极，谁不负责。
你追求质量的话，看你们的项目组织是否能倒旧账了，可以看现场反馈或者交叉测试来进行评估。

liangliang1

不能按bug量来做惩罚奖励，bug的多少并不能代表测试部人员的能力，他和多个部门有关系的，部门之间需要合作的，应该是看最终产品的质量如何来衡量各部门之间的合作力度。我觉得我们每一个人都是有主见和思想的，有自己的工作和思维方式，每个人都觉得拥有主人翁的感觉是最棒的，这比给予物质奖励更能调动员工的积极性！所以，我建议充分尊重每一个员工的想法和建议，你可以不采纳，但是请尊重他，一定不要打击他！即使他的建议再烂！否则，你的老大位置也会慢慢的变得没有任何意义，每个跟随你工作的人都仅仅是工具而已！当然，物质奖励也是必须的，毕竟我们工作还是要吃饭的！

liumengjun517

回复 12# Scott86
这样一刀切很糟糕，完全不具备操作性！举个简单的例子，bug到后期肯定越来越少，再说了，你找出了那么多bug，系统还要不要上线啊

archonwang

个人建议从需求开始，仅仅看bug数量最后可能会造成部门不平衡。

archonwang

1、每位员工一天寻找BUG票的任务是10个，超过10个的每个票奖金10元（BUG明码标价：逻辑BUG，功能性BUG每个5 ...
Scott86 发表于 2010-11-12 16:40

当测试部老大压力好大。。。。
另外，明码标价之前请先提供标准（包括工作量和bug的等级分析），仅仅提供数量是简单的

Scott86

1、每位员工一天寻找BUG票的任务是10个，超过10个的每个票奖金10元（BUG明码标价：逻辑BUG，功能性BUG每个500）；
2、3、每天工作量过低的给予警告，一个月超过3次警告给予罚款（罚的钱给大家买糖吃）；
4、每天员工要写工作总结：当天工作数量，工作质量；月底进行评比（月冠军奖励500）（副班长给大家表演节目）；
5、测试组提前完成任务让老大请吃饭，延误工期测试组成员集资请老大吃饭；
     奖惩宗旨：增强团队效率，提高团队质量，榨干老总钱袋；

msnshow

这个比较难，对测试工作的考核本身就非常困难，设及到奖罚就更难了

愚人

不是写一份讨论嘛，难倒只为了发牢骚，难写？

千里

你先写出来，我们再讨论吧。
没看到你抛出任何讨论的元素，整一个光吸收知识的求助，这样还是不太好。

zhong3269

写具体点啊！！！！！ 比如  什么什么！！！！！！ 多好的想法，就没人想呢？你一条我一条 就出来了1！！！