惩罚与奖励并行
所有的管理技巧中，大棒和胡萝卜总是密不可分的，缺一不可。如果按照LZ的意思设立了惩罚机制，相应的就应该设置一些奖励机制，以求与之平衡，比如连续2~3版本无漏测或无回归不过的人员，给予几何几何奖励。（如果惩罚是奖金的话，那么奖励最好设置为奖金；如果惩罚是警告的话，奖励也相应变成口头表扬）最终目的是追去管理机制中的平衡。
但是看看国内的各个企业，不管是大企还是小企，不管是国企还是外企，其实都没有设置针对漏测和回归的奖励机制，惩罚机制倒是不少……
综上，若不愿给萝卜，就不要给大棒！！！
（立场选错了……）支持反方……
[ 本帖最后由 Jackc 于 2009-9-11 10:27 编辑 ]
没什么好说的
需要制度，但也要考虑人性化上手
没意思，谁都不容易啊随机应变
我觉得者的看是一个什么样的公司，一个公司如果没有自己的管理规范，给测试和开发的工资同行相比比较低，就那点钱，谁愿意为产品的质量负责，我估计再罚款就没法做了 漏测分为设计漏测和执行漏测.设计漏测是由于测试人员对测试特性了解不充分导致;
执行漏测是由于对测试特性是否稳定判断错误,未进行覆盖测试;
问题单回归不通过分为问题未修改,修改不全面,引入新问题,回归未按照提单环境回归等;
问题未修改和修改不全面是开发人员主观责任感不强;
引入新问题是在审查修改环节监审粒度不到位;
回归问题单未按照提单环境回归是测试人员对回归操作不规范所导致,虽然问题应该在不同环境中均不得复现,但是环境的不同出发问题的因素不尽相同.
惩罚的对象不公平，另外只有惩罚没有对等的奖励
我认为漏测并非所有责任都在于测试人员，因为引入这个BUG的不是测试人员而是在开发的时候产生了这个BUG，并且这个BUG可能很隐秘，测试的深度和广度并非无限的，有些BUG很难被发现。如果发现漏测的BUG，而这个责任相对较大的，我个人认为是引入这个BUG的开发人员，而非测试人员。当然，不论是开发人员，还是测试人员都需要负一定的责任。作为测试人员，我们的责任是尽量保证软件的质量，帮助开发人员提高软件质量。即使是微软公司或者IBM，他们亦不能保证软件的100%质量。就拿XP系统为例，经过多少的补丁更新，但依然有很多漏洞出现。没有人能使软件质量达到100%，而只能趋近于100%。对于回归测试不通过，就给予开发人员惩罚。定义太模糊了，没有经过分析问题的原因，就给予惩罚，这是完全没有理性处理问题的做法。
另外，漏测和回归测试不通过要给予惩罚的话，我认为不应该只有惩罚，而应该有对等的奖励方式。大多数人都认为做对了是完全应该的，理所当然不用奖励了，做错了就是不应该的，必须惩罚。如果需要对做错这件事惩罚，那么对做对了这一件事是否应该给予相应的奖励呢？惩罚与奖励应该是相对立、不可分割的统一体。
我认为这种方式的效果并不明显，不是提高软件质量的本质因素。只是作为一种推动力，能推动软件质量的提高，亦有可能往相反的方向走。
因此，我的结论是：奖、惩必须同时存在且有对等关系；理性客观的分析问题的原因，关键是定位问题原因和寻找解决方案。 原帖由 velata 于 2009-8-4 23:49 发表 http://bbs.51testing.com/images/common/back.gif
惩罚的目的是什么？是为了那点微薄的RMB？还是为了提高项目质量？
说说我们这边对两种情况的处理吧
一、漏测
我们漏测的概念是版本发布到客户那，由客户发现的bug。
对于这类bug，先有开发分析这个bug的 ...
赞成！！
为什么不先考虑如何避免惩罚?
我很仔细的看了以上每个兄弟的观点.其实很难下结论.可是我们不妨这么思考:
越是高层,责任感就越强,他们在决策时,肯定也会考虑以上种种.
如果一个公司已经制定出了处罚制度,说明什么,说明他已经无能为力,只能靠这种简单粗暴甚至愚蠢的方法了.
那么我们的第一个念头为什么不是:发挥我们测试的才干,怎么避免处罚呢?
我觉得我们首先考虑的应该试图寻找一个办法,达到公司要求的质量标准,避免处罚.
首先考虑我们一己之力,想尽一切办法改进,然后明确的指出我们做不到的,需要开发,乃至售后配合的内容.
这样的话,精力100%全投在了怎么解决当前面临的问题上.而不必浪费时间,唇舌,和感情,争论应不应该被处罚.
如果这之后,真的不行,还是达不到要求,那在考虑其他出路,反应,忍受甚至走人,也不迟. 需看情况定夺，不能一概而论 还漏测，测试尽可能多的覆盖吧
回归不通过，开发没完全修复BUG.
都需要加强，责任肯定是有的了
态度决定一切
发现bug,优先对bug进行分析。需要考虑以下几个方面。1、bug是怎样产生的？
2、是否超出需求？需求是否明确？
3、bug类别。
4、测试或研发人员平时一贯的工作态度。
我有体会。有个测试人员平时工作认真、积极、自尊性很强的人。可有个版本发布后到客户那里由我们的技术支持人员碰到。后经过分析是哪个测试人员的责任，由于疏忽导致。当时我只说了一句话“看来我们测试还需要更加仔细”，也没有进行处罚。后来他工作更认真、仔细。还主动加班。后来我明白了对不同的问题、不同的人、不同的场合采取不同的处理方法。是我们作为管理者应多思考的问题。
技术手段不是全部手段
惩罚的确不是好的手段，可以说是下策。特别是对测试人员。测试人员依靠发掘宝藏（BUG）的激情存活着，所谓漏测，有可能是不认真测，也有可能是没注意到，也可能是测试用例不详细，也有可能是他觉得不是BUG，衡量这些，十分困难，却用惩罚来打击发掘宝藏的积极性？ 哪个出色的探险团队会有发现不了该发现的宝藏就要被惩罚的规定呢？ 如果把测试人员比作用鞭子抽打才出成绩的软件奴隶，还不如让他们做出色的探险团队。让他们觉得找到的BUG，大家重视得像发现宝藏一样，给个GOOD CATCH给他，让他享受发现BUG的喜悦和成就感。在这样的管理之下，相信他们会努力地去做。另外，测试并不能只靠个人力量，虽然大家有分工，但是找出遗漏的问题是一个团队的责任，并且应该更加相信团队而非个人，对应这点，测试模块的轮换等管理的手段，的确能有效避免漏测。哪怕是惩罚，也是一个团队的责任。 我认为这两种情况要分别对待，漏测是应该有所惩罚的，但是回归不通过则不应该惩罚。好比医生和护士，护士做每天的例行检查，但是有一天忘记了，这就造成了漏测，需要承担责任；而医生则不同，他需要治病，但是治病是可能带来副作用甚至造成后遗症的，这个事情有时候不好推测副作用的反应大小，有时候也是不可避免的，所以回归不通过要视情况而定。 我认为当缺陷漏出或者产生degree，首先要做的事情是对原因分析。并且是深层次的分析。
测试者或者开发人员找出原因，然后进行分析，提出对策与再发防止策，
让当事人清晰地认识问题，同时有共通性的可以与全员分享经验。
当然对于一而再，再而三发生的问题，或者影响面特别重大的，而当事人可以避免的问题可以做出适当的惩罚。
但是在惩罚前，需要与当事人进行沟通，并得到当事人认可的情况下，进行惩罚。
同时既然有惩罚就应该有奖励，不可只有大棒，没有胡萝卜。
总结一下，就是对其分析防止再发生是提高质量的主要手段，奖惩措施可以作为辅助手段。 惩罚漏测的测试人员或未通过bug的开发人员都是不可取的，找出出问题的原因，把大家工作态度积极性调动起来才是最重要的。 对于漏测的测试人员，我觉得不应该惩罚，因为当测试人员漏测BUG后，如果那个BUG的确是因为他的个人因素没有考虑到，也许到客户那儿才被发现，他自己都会觉得很自责的，自己会自我反省，所以那就没有必要对其进行惩罚，在这种情况下，一般都是由测试的负责人来承担这个责任，这样一来漏测那个人员工会很感激你，在以后的工作中他会更加努力的为你工作，但是，可以进行批评，可以帮助他总结经验，不要让此类情况再次发生；如果不是自身情况造成的，是由其他外界因素，就比如上面大家说到的很多种情况，那也没有必要进行惩罚，因为责任根本 就不在他身上。
对于“回归测试不通过”的开发人员是否需要进行惩罚，这个更加没有必要了，有过工作经验的人都知道，任何一个公司里面的开发人员能力水平都是参差不齐的，有时候让一个开发人员更改一个问题都有可能引发几个问题出来，这个是很正常的事；我记得在一个公司做了一年以后，公司一个开发人员给我说：“我现在都知道你们要测试些什么了”，也就是他在进来一年以后，经过跟我们测试的磨合，考虑问题都会全面得多了，人都是慢慢成长的，如果因为一件小事，对别人造成了心里上的阴影，那岂不是罪人。其实大家都是一个团队，在一起都是为了把事情做好，出了问题应该首先考虑的怎样去解决，总结经验，以后不要再让此类问题发生。
[ 本帖最后由 tangjhling 于 2009-10-10 10:40 编辑 ] :L 原帖由 dawei1208 于 2009-9-24 16:36 发表 http://bbs.51testing.com/images/common/back.gif
我很仔细的看了以上每个兄弟的观点.其实很难下结论.
可是我们不妨这么思考:
越是高层,责任感就越强,他们在决策时,肯定也会考虑以上种种.
如果一个公司已经制定出了处罚制度,说明什么,说明他已经无能为力,只能靠这 ...
恩呵呵 原帖由 dawei1208 于 2009-9-24 16:36 发表 http://bbs.51testing.com/images/common/back.gif
我很仔细的看了以上每个兄弟的观点.其实很难下结论.
可是我们不妨这么思考:
越是高层,责任感就越强,他们在决策时,肯定也会考虑以上种种.
如果一个公司已经制定出了处罚制度,说明什么,说明他已经无能为力,只能靠这 ...
恩 呵呵 我选择反方:) 不需要
