“漏测”的测试人员需要惩罚？（2009-8-4）获奖名单已公布

wolf-tree

惩罚漏测的测试人员或未通过bug的开发人员都是不可取的，找出出问题的原因，把大家工作态度积极性调动起来才是最重要的。

tangjhling

对于漏测的测试人员，我觉得不应该惩罚，因为当测试人员漏测BUG后，如果那个BUG的确是因为他的个人因素没有考虑到，也许到客户那儿才被发现，他自己都会觉得很自责的，自己会自我反省，所以那就没有必要对其进行惩罚，在这种情况下，一般都是由测试的负责人来承担这个责任，这样一来漏测那个人员工会很感激你，在以后的工作中他会更加努力的为你工作，但是，可以进行批评，可以帮助他总结经验，不要让此类情况再次发生；如果不是自身情况造成的，是由其他外界因素，就比如上面大家说到的很多种情况，那也没有必要进行惩罚，因为责任根本 就不在他身上。

对于“回归测试不通过”的开发人员是否需要进行惩罚，这个更加没有必要了，有过工作经验的人都知道，任何一个公司里面的开发人员能力水平都是参差不齐的，有时候让一个开发人员更改一个问题都有可能引发几个问题出来，这个是很正常的事；我记得在一个公司做了一年以后，公司一个开发人员给我说：“我现在都知道你们要测试些什么了”，也就是他在进来一年以后，经过跟我们测试的磨合，考虑问题都会全面得多了，人都是慢慢成长的，如果因为一件小事，对别人造成了心里上的阴影，那岂不是罪人。其实大家都是一个团队，在一起都是为了把事情做好，出了问题应该首先考虑的怎样去解决，总结经验，以后不要再让此类问题发生。

[ 本帖最后由 tangjhling 于 2009-10-10 10:40 编辑 ]

heyunyou

kukumaru

我选择反方 不需要

kukumaru

只有态度问题才需要惩罚。如果是能力问题，需要的是培训。

ml3684881

我们的最终目的不是追究责任
而是解决问题，让该现象不再发生或降低发生的概率
所以因该只是告诉整个团队“我们出现问题了，我们需要解决改问题”

测试新新手

在目前国内测试还不规范的大环境下,我个人觉得漏测就惩罚是不妥的,毕竟"人无完人"啊.

非常赞同61楼的观点!

luwenjie1990

谁敢说一个回归开发一定能修复好
谁敢说一个软件BUG一定全被发现

wang2171

漏测
漏测并不是测试人员希望遇到的，只是在测试过程中没有发现bug的路径，在漏测出现以后测试人员更加注意这种环境下的测试，希望不要犯同样的错误。

[ 本帖最后由 wang2171 于 2009-11-12 19:59 编辑 ]

trange

对一项有风险的活动由测试人员来负责不好的后果，不合理。
但是可以根据“漏测”问题进行测试人员自身或者组织级的改进。因为也有可能是设计的用例不够完善，或者测试策略放弃了这部分的测试了...

liangshi

测试的目的是什么？终极目的应该是更好的测试者，而更好的软件只是这一过程的副产品。

每一个漏测都是学习的机会。
1. 为什么会漏测？
2. 在软件的其他地方，还存在相似的问题么？
3. 有没有办法增强测试用例，使得相关问题被及时地捕获？
4. 测试团队从中可以学习到什么？增强的测试策略、改善的测试计划？
5. 这个问题的根本什么？可以在开发阶段（甚至更早的阶段）就解决么？可以不通过测试就发现并解决么？
6. 整个开发团队可以学到什么？

要想更好地学习，就必须坦诚地承认错误，进行“无情”地分析。但是，“惩罚”会在客观上促使人人自保、文过饰非。推卸责任是很容易的，只要将所有问题推给他人就好了：项目的需求就搞错了；用户的环境与测试环境有区别（他的机器有4核CPU，我只有单核，这难道这是我一个搞测试的可以解决的？）；我口头提醒过开发，但是他强调这是一个很酷的功能……

“惩罚”的思路是“回避失败”，而不是“最求卓越”。卓越的文化不惩罚失败。但是培养卓越的文化非常困难，因此惩罚也是工具箱中的一员。应该先鼓励员工从错误中学校，然后组织团队有规划地学习，并尽可能地促进团队间的相互交流。惩罚只是最后的手段，是对无意学习者的提醒。

投缘

测试是无穷尽的，不可能每种情况都被想到、被测试到。特别是刚接触公司产品的测试人员，随着对产品的了解越来越深，才会逐渐拥有良好的、开放的测试思维，测试的覆盖率才会越来越广。如果由于他的不了解就惩罚他，那么不但不会让他更加好的工作，反而会缩手缩脚起来。如果真的出现漏测情况时，我觉得不只是这个测试人员的过错，整个测试组的评审工作就是有疏漏的。测试组一定要将这个问题进行记录和总结，以备以后的项目提供借鉴。

joycena

首先必须理清'漏测'及测试的概念. 测试是为了保证产品的质量,尽早尽可能的发现可能存在的错误(包括需求\设计\软件系统\环境等),而不是必须找出所有的问题,从这个意义上讲,遗漏是可能存在的., 当然,根据实际情况而言, 对漏测 公司可以建立一些规则,什么样的范围允许,什么样的范围不允许. 对于一个低级错误, 一般则不允许，而对于一个复杂的或业务需求不明晰或后期代码随意调整而产生的错误,则可以归为允许范围;
对于'回归不通过'的问题,也该具体问题具体对待, 一个单一的问题则必须单次完成,若其他潜在类问题,测试人员并未及时发现而产生的,则应该规避开发人员的责任;  而若因某一BUG引发 其他 较严重问题(即回归时测试人员发现新BUG由上一版本的BUG调整而产生,则也应做以规范.

另, 无论是漏测还是修改不通过, 都不能作为单一的评判标准, 而对于 漏测数较少 或 修改质量较高的,应加以表扬奖励, 这样才能调动 成员的积极性,  一个团队 应该是积极向上充满活力的,而不是 在恐惧中生存

enter333

今年因为漏测被罚款上千元的人路过。
人的问题吧。太菜了，么办法。

这里有没有开发人员过来参加辩论呢。

JulianHuang

作为一个测试人员和测试管理者，我个人觉得漏测不是测试人员一个人的责任，你们的管理流程上肯定也是有问题！首先如果你的测试用例是规范化管理的话，比如用TD或BUGZILLA管理的，漏测得情况几乎不可能发生；其次，一个系统在测试过程中，不要让同一个人始终负责同一个模块，要有轮换制，这样才能更多的发现问题。

关于回归不通过的问题，我只能说有可能是开发人员的问题，也有可能是添加新功能对原有的功能有影响，这不能一概而论！