“漏测”的测试人员需要惩罚？（2009-8-4）获奖名单已公布
[size=3][i]背景描述：[/i][color=red]对于“漏测”的测试人员以及“回归测试不通过”的开发人员需要惩罚吗？[/color][/size]
[table=400][tr][td][b]奖项[/b][/td][td][b]获奖名单[/b][/td][td][b]奖励[/b][/td][td][b]答案连接[/b][/td][/tr][tr][td]最佳话题PK手[/td][td]velata[/td][td][align=center]价值50元的当当网礼品+最佳PK手勋章[/align][/td][td][url=http://bbs.51testing.com/viewthread.php?tid=162520&page=1#pid1297603]3#[/url][/td][/tr][/table]
[size=2]如果你也有矛盾的问题想提出来和大家一起讨论，[/size][url=http://bbs.51testing.com/thread-131215-1-1.html][size=2][color=red]请点击此处>>[/color][/size][/url]
[size=3][size=2]说不定下期PK的话题就是由你提出的哦，请快快参与吧[/size][/size]
看问题的严重程度与发现的难度
看问题的严重程度与发现的难度 如果不和惩罚机制相挂钩的话，相信很难提高项目的质量，起码应当对漏测的问题进行分类，然后按照严重程度，记录漏测的问题。最基础的作用是让leader们，有一个参考，谁工作做的好与不好。也会影响到与自己息息相关的“绩效”，这样也算是一种惩罚了吧。。。中立态度
惩罚的目的是什么？是为了那点微薄的RMB？还是为了提高项目质量？说说我们这边对两种情况的处理吧
一、漏测
我们漏测的概念是版本发布到客户那，由客户发现的bug。
对于这类bug，先有开发分析这个bug的原因，是测试环境跟客户环境不一致？还是真正的代码引入的bug。
对于这个bug，测试人员在已有的业务理解、测试经验上能否发现？如果这个bug根本原因是需求都没考虑到的情况，或者是本来不在需求、设计文档任何一个地方体现，是开发人员自己加进去的，那测试人员应该是没有责任。
如果这个bug是需要经过复杂的场景设计才能重现，那么测试用例编写者就应该一起坐下来讨论，要如何在以后的测试中发现类似的问题，并对解决方案进行评估，为了发现这个问题而做的一系列测试场景、数据是否值得？
如果是很明显的bug，换其他任意一个人来都能发现，或者测试用例上已经明确有此检查点且测试人员给了通过的结论，那就真是这个测试人员的问题了，根据规章制度 该咋办咋办去吧:(
二、回归测试不通过（昨天打游戏去了，今天补上）
sorry各位开发，我是觉得一个bug没有解决完全、或者是引入了新的问题，真的是你的问题了……
一个bug既然提出来了就应该好好分析，此bug是如何产生的？
是对需求理解不透彻？那就应该再阅读需求文档、仔细推敲，或者是直接问产品组的需求人员；
是对系统架构不熟悉？那应该加强对所实现系统架构的学习；
是看轻了bug？随手改掉没改完全，随便改改引入的新问题，那就完全的责任了。
我们组的一女强人说过一句话（俺不晓得她是自己总结的还是在别的地方看到的）
如果开发有这样的观念：所有的bug都是我一手种下的，我肯定有责任
测试有这样的观念：所有的bug都是从我手下漏的，我肯定有责任
那么系统质量肯定能有保障。
为什么要绩效考核？为什么要罚款？说白了都是为了提高质量，如果不分情况，统一对漏测的惩罚、对bug解决不完全的惩罚，会导致员工积极性严重降低（深圳某大型外包公司一美国项目前一阵子就出现这种情况，公司遭客户投诉，就对测试、开发进行罚款，导致大量员工辞职）。但是如果有绩效制度，对于真正该罚的人没有罚，也会打击其他努力工作的员工积极性。
总之，该不该罚、如何罚 不能一概而定。把漏测的类型分类，按情况处置。
[[i] 本帖最后由 velata 于 2009-8-6 21:27 编辑 [/i]] 从管理学角度讲，惩罚是最消极的手段。漏测问题我们要分析漏测的根因，回归测试不通过我们要分析回归不通过的根因，目的不是为了找出是谁的责任，问题已经发生了再来谈责任是愚蠢的做法，因为我们在同一个公司，目的是一致的——都是为了让项目成功。寻找根因的目的是预防同类问题再发生，这是对项目成功有正面推动作用的事。所谓对事不对人嘛，这样的团队才健康。 对于发生漏测事件，当然具体看漏测具体问题了，如果漏测的问题是只要执行相关的测试用例就能发现的，这样不用说肯定是相关测试人员的工作没有做好了，如果漏掉的问题是比较冷僻的，是情有可原的，毕竟我们谁都不敢说自己测过的版本就是完美的没有问题的，对于漏测我们抓出来并不是要怪谁，要追究谁的责任，我们应该通过分析漏测的原因从而找到测试工作中的漏洞，进行改进，是个人的问题就解决个人问题，是用例没有覆盖到的就添加用例及注意事项，争取下次不要出现类似的错误，亡羊补牢为时不晚，这样才能改进版本的质量。对于回归测试不通过的开发人员，我就不多说，因为我不是开发，不过按照我们公司的制度，这个有点严重哦，不说别的，起码本月的绩效是不好
应该有惩罚措施
如果问题很严重的话，就要找是测试的问题还是开发的问题，但是也不应该惩罚的过于严重有的公司就没有惩罚措施，最后出问题的时候，谁都有责任，公司根本就惩罚不了
所以我个人觉得就应该有惩罚措施，漏测就是测试责任，回归不过就找开发~，不过也得具体问题具体分析
惩罚--弊大于利
先就测试人员‘漏测’是否处罚讲一下个人观点，1.公司的需求开发测试都不完备，需求文档都只是简单描述模块功能，开发在没有吃透需求的情况下先开发后改动，等到系统都做完了，再扔给测试，且不会给足够的时间测试，所以这类公司对测试用例的要求很一般，主要要求跑完所有的流程和功能，可以用就行了。这种项目或产品的质量要求就不会很高，‘漏测’极有可能了，不过也不可怕，后期都会有维护，发现了问题改过了就好了。需求不精确，测试时间人员都不够，测试人员的压力本来就很大，加班加点，如果还要搞‘漏测处罚’的 话是不公平的，也不能解决根本问题，应当完善。2.公司的需求开发测试都比较完备，对项目/产品的要求也比较高，一般都会有正规的测试小组，但还是不应当提倡‘处罚’，它会带来很多弊端：新员工和初级员工难免会漏测，处罚会带来打击；写用例和执行分开，漏测了，处罚谁；交叉测试的时候发现对方漏测的地方越多就意味就对方的处罚也越多，不利用团结；在分配测试任务的时候，大家都会想要BUG少的模块或者开发水平高的模块，谁都不会想要处罚的，这会造成责任的推诿；员工会规避处罚 ，这也是人之常情，往往会墨守成规，不去主动承担难的，增加的测试任务，把时间都花在不停的找bug上，不热衷去研究新的测试方法等等……总之弊大于利。同理‘回归测试不通过的开发人员需要惩罚’会给开发和测试组成的项目团队造成分裂，团队内出现摩擦，效率就可能会降低等等。
以上或许就是公司不推行惩罚的一小部分原因吧，毕竟公司的管理层大多是明智的。
[[i] 本帖最后由 wuchunying 于 2009-8-6 16:27 编辑 [/i]] bug是杀不尽的! 发生漏测的原因是什么，是由于测试人员自身的原因就是没有测试，还是在设计TC的时候就没有想到等等
具体的问题需要具体的分析，要把问题尽可能的分析下。这样才好定位这次漏测的性质是什么.......并对应相应的解决办法。。。。。
站在客观的角度看问题
从实际来说，bug是很容易被漏测的。而且，漏测bug 的存在对于测试人员本身也是一种打击，想想自己是否专业？本来，找bug是件很创新的事情，需要测试人员静心分析问题，才能找到。我不排除有些测试 人员是比较不专业导致的，但是成长也是需要时间的。所以，对于漏测的问题，就像是bug的红旗，大家只有在附近不断的寻找，才能保证产品的质量。
惩罚？测试本身是项脑力劳动，惩罚本身就是消极的，还会引起测试人员心情的波动和自信心的建立 只有态度问题才需要惩罚。如果是能力问题，需要的是培训。 我对测试的看法就是，我同意允许发布的产品，如果发现问题，那么就是测试职责。
如果一个测试拿“测试不能做到百分百发现bug”这个观点来作为漏测的理由，那么我只能说，测试人员的态度立场就是不太积极的。
当然惩罚也许没有必要，但是测试人员本身就需要有这种意识，一种对漏测bug负责的意识。经历过我的产品，我也许不能保证百分百完美，但是至少我们需要保证在一定的用户使用时间内，它是没有问题的。当然这个时限可能各个产品不一样。
对于上面的有些观点，我有些不是很同意，漏测就是漏测，没有什么应该发现和冷僻的就情有可原的说法。如果是一个bug，漏测了，测试就需要对缺陷进行负责，测试需要反思，为什么这个bug我没有发现，在那个阶段我可能发现，或者使用什么测试方法我可能发现。
当然更加积极的方式是，我们对缺陷进行后期的分析和以后避免，但是如果没有一定的惩罚，也许一味的使用温和的方式，很多时候因为没有责任也就没有压力和意识/
所以我还是支持一定程度的惩罚，但是万事不能过分，过了就失去了鞭策意义。
最近也在思考这些问题，如果有不同意见的，也欢迎拍砖和私下交流。可能各个公司的情况不一样吧:lol
[[i] 本帖最后由 jessies 于 2009-8-5 22:44 编辑 [/i]]
产品问题是所有人的责任
[quote]原帖由 [i]jessies[/i] 于 2009-8-5 22:43 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=1298508&ptid=162520][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]我对测试的看法就是，我同意允许发布的产品，如果发现问题，那么就是测试职责。
如果一个测试拿“测试不能做到百分百发现bug”这个观点来作为漏测的理由，那么我只能说，测试人员的态度立场就是不太积极的。
当然惩 ... [/quote]
产品质量不能仅仅由测试来把关。所有对于产品有Input的人，都对产品质量有责任。
测试有一个“just enough"原则。这个原则是建立在成本/效益的基础上。为了在系统中找到的某些bug如果要多花几倍的成本，那么对于企业来说，可能还不如事后去做hot fix来的核算。
并不是所有客户发现的bug，都属于”漏测“范围。如果是基本的Happy path，被客户发现问题，那的确是研发人员的责任。如果是那些本来就不在测试范围中的，应该不属于漏测。反过来讲，我们应该根据客户反馈（客户发现的bug也是一种客户反馈）来改进和调整测试范围和测试方法。只有工作态度问题才需要惩罚，其他的都应该作为持续改进来处理。整个团队的目的在于做出更好的产品，而不是寻找谁是坏蛋。
具体情况具体分析
首先，测试人员不能保证软件不存在ＢＵＧ。当然，如果是已设计或写了测试用例，却在测试时忽略，测试人员的工作态度是不正确的。需要有一定的惩罚措施。回归测试不通过，也不能一概而论。根据其不通过原因来分析。
为什么没有人提到开发人员 0 0?
大家都在讲测试哈! 我倒是经历了很多回归测试不通过的情况!对于开发人员来讲 偶尔的疏忽或许可以谅解 但是频繁的出现返测不通过的情况 是应该引起重视的! 这样会拖垮进度.
至于漏测的情况 如果是按照用例执行就能够发现的问题 势必要承担责任 当然这就需要一个全面的测试计划. 我发现正方说话的口气多是处于领导层的人士 .. 似乎担了不体察民间疾苦的嫌疑
好的情绪肯定会提高工作效率 提升工作质量 但是这样的好情绪 并不是单纯的惩罚可以做到的 更多需要的是鼓励:handshake [quote]原帖由 [i]velata[/i] 于 2009-8-4 23:49 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=1297603&ptid=162520][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
惩罚的目的是什么？是为了那点微薄的RMB？还是为了提高项目质量？
说说我们这边对两种情况的处理吧
一、漏测
我们漏测的概念是版本发布到客户那，由客户发现的bug。
对于这类bug，先有开发分析这个bug的 ... [/quote]
支持,分析的很全面.. 在大的层面上，应该对漏测和回归测试不通过的行为予以记录并适当惩罚。因为如果不做纪律性的约束，就不会引起测试人员和开发人员的重视。
但同时，这里面涉及到很多问题，众所周知，bug是不可能被完全测试出来的，何谓漏测，就得有一些判断和规定了。如果对漏测等处罚过于严厉，也会挫伤测试人员的积极性。
总之，对漏测和回归测不通过，应该予以记录，并在项目总结中予以体现，至于惩罚，可量力而行。 我认为在好的公司是不需要制定惩罚措施来约束自己的员工
1.漏测
漏测可能直观是测试人员没有把工作做完整，测试是辅助开发团队完成高质量的产品或项目。测试人员谁敢说自己负责的产品或项目能保证质量，没有。从中外的书籍中也可以看到。
(1)如果测试人员是按照测试用例而测试用例中偏没有这样或那样的过程测试,而在用户那里发现了，这算不算漏测哪？
(2)如果连着四轮测试某个小功能都没有问题，而第五轮测试人员就有可能一代而过没有覆盖全,而开发人员也没说对那里进行了调整，这种情况也是有的
(3)还有bug已经提交到Bug库中,在新的一个版本中已经确认解决，又经过几番修改代码，产品或项目发布了，用户发现了bug，而在Bug库中能找到相近的提交bug,这种情况算不算漏测哪？
2.对于回归测试不通过的Bug
对于回归测试不通过的问题，那就看产品或项目是否已经发布。
(1)在发布之前
原因可能多种：bug解决了而忘记了上传代码；代码上传了而开发经理进行的局部编译遗漏了；当在团队内开发员A修改了功能A的代码，而导致开发员B的功能B的接用功能A接口出现了问题，这种导到这的问题产生也是常有的。
(2)发布
当产品或项目急于发布，而回归测试仍有问题，但发布的日期越来越短，负责这个功能的开发人的手上还有比在回归测试上发现的bug更严重的多个bug，这种情况也是有的；而开发经理也认为这是个小bug，先不理它，发布后，小bug积累成大bug或严重的bug，这种情况也是有的；如果这是一个严重的bug又面临将要发布，测试人员只是把bug提交到Bug库上，而没有去推动bug的解决，这种情况也是有的。
还有就是Bug不是测试出来的，而是开发出来的。 需要 我觉得漏测和测试不通过在测试过程中是经常会发生的现象，如果经常采取惩罚措施，那估计测试和开发人员的神经会非常紧张，在这么紧张的情绪下，会出现好的工作产品吗？显然，答案是否定的。当然这不等于纵容漏测和允许测试不通过，当出现漏测和测试不通过的情况时，测试和开发人员应该反思，我为什么没有想到这个测试用例？我为什么没有正确的设计某个功能的代码？去寻找问题的根源，在下一轮工作中，尽量考虑全面一点，避免上一轮工作中所发生的错误，人不是完美的，都是需要时间慢慢完善的。希望大家工作越来越好。 BUG是杀不尽的，可是对于一群正常使用软件的客户来说他们发现了，而我们却没有发现这是一个很严重的问题(项目时间充足的条件下)。所以我觉得对漏测的测试人员应该惩罚。
我认为企业应该做到有赏有罚 责任分明
对于测试遗漏 我觉得应该视具体遗漏的BUG情况来决定惩罚的轻重，人性化管理不适合在这种情况下考虑作为测试人员，如果用测试不可避免遗漏作为借口的话，我想这个员工企业也是没有必要雇用，起码在此员工的心态上就是不端正，对自己的工作没有警觉性和应有的责任心。如果对此不做惩罚，那企业将无法对员工进行约束。惩罚也是作为对其他员工的警示。没有人愿意“漏测”，让“回归测试”不通过
1.“漏测”的主要原因是什么？测试用例不完善，测试时间不充分，测试资源不充分，测试人员所用的测试环境远远少于用户的应用环境等等，这些都是可能造成“漏测”的原因，没有一个测试人员不希望自己能把所有的BUG都找出来（敷衍了事者除外）。在中国90%的以上的公司中，测试人员的薪资都是很微薄的，那么当他出现“漏测”BUG的时候，公司进行惩罚，怎么惩罚？难道要漏掉1个BUG罚款100RMB么，开玩笑。如果多漏几个岂不是可能是负的了。这个月扣掉几百，那么下个月公司又凭什么让员工去努力呢？长此以往，谁又能经得住这样的考验呢？2.“回归测试”不通过的原因也可能是多种多样的，如果员工写的代码出现了Bug（即使是经过多次修改）就要惩罚，那么员工所想的尽可能少出Bug,那么这样下去员工又怎么能有进步呢？
3.人无完人，比尔盖茨领导下的微软，微软操作系统天天都在打补丁，那么多N人做出来的东西都有这么多的Bug，我们写出来的代码存在Bug又有什么不可原谅的呢？
4.当出现问题时，用惩罚的措施来迫使员工少出问题，这是最滥的手法。员工最需要的鼓励和理解，一句“你做的很少，要是没有这些问题会更好。下次，你不会再出现这样的问题了吧？”会比罚钱更加有用。
5.以上献给想把工作做好的兄弟姐妹们。 我是觉得漏测和回归不通过的情况常常存在，需要考虑的是在开发回归一次不通过的情况下且测试人员将BUG已描述清楚和详细，但开发人员在修改后，再次被测试人员打回。这时可以说下是这个开发人员的问题了。多次回归不通过时，可以考虑必要的处罚，但处罚不一定是$.
漏测的情况很多，但比如需求上有明确的说明，用例也有设计在内，而测试人员漏测的情况，是否是考虑不够全面还是没有参考相关文档引起？可以考虑处罚。
但正常情况下，不赞成处罚！:victory:
因为没人愿意一个问题修改三四遍还不通过，也不会有人愿意将明显的bug说测试通过。
[[i] 本帖最后由 zlpxm 于 2009-8-20 11:33 编辑 [/i]]
为什么有漏侧或总是漏测？为什么有通不过或经常通不过！
1. 我想请对方辩友你能给惩罚下个定义么？ OK ，您能不能在告诉我在新华字典中惩罚的意思么？2.没人愿意“漏测”和“回归测试”不通过，那为什么还有这种情况发生呢？请您不要打断我，漏测就是在你测试的范围内没有测试的内容，我们有个系统上面有这样一个功能Create 和 ADD 两个button， 我们有79个测试人员，其实Create和ADD实现的功能是一样的，您告诉我我们公司这些人您能保证没个都会把两个button都测试么？ 您说能！ 我告诉你我们就有惩罚机制，这就是效果， 应为以前80%的人都点一个，而问题就在这。 您说不能 为什么不能 点击个Button会累死人，并且这是你的工作。
3.千万不要让测试人员养成“我以为”的毛病， 这次“我以为”是这样的，Ok，没事下次注意！ （我们公司不那么严随便测测就好了） 下次“我以为”是那样的，您能保证在没有下次了么？ “惩罚”不单单是物质和金钱上的，我相信适当的“惩罚”会减少下一次。
4.我们对“惩罚”不是体罚，不是罚款，请您回去查下字典好么，回来告诉我惩罚的解释是什么，罚1000算是惩罚么？罚50算是惩罚么？给她一巴掌算是惩罚么？在会上温和的告诉她你错了这又算是惩罚么？ 谢谢！！
惩罚 没有词典，百度搜的
惩罚的中文解释以下结果由汉典提供词典解释
基本解释
1. [punish]∶惩戒;责罚;处罚
惩罚坏人
2. [discipline]∶施加鞭鞑或体罚使之服贴、受辱或以苦行赎罪
看到许多可怜的奴隶正在鞭打惩罚自己
详细解释
处罚。
《魏书·西域传·于阗》：“其刑法，杀人者死，餘罪各随轻重惩罚。” 杨朔 《渔笛》：“坏人都得到应有的惩罚，好人也踏上幸福的道路。” 艾芜 《漫谈三十年代的“左联”（一）》：“这是用经济上的惩罚，来补充**上的虐待。” 扯淡，测试人员测过就能没BUG，开发人员一改BUG就没了，那就不会有这么多公司被质量拖死了 不是说测试人员侧过就一定没有Bug，所谓的“惩罚”不是鞭打测试员告诉他们一定要没有Bug，而是提高测试人员的精神状态的一种方式，为什么我们定个目标后你就会感觉工作很激情很动力， 没个人每天都有心情不好或者干劲不足的时候，“惩罚”是提高我们测试人员的一种精神状态。 举个极端的例子：如果测试人员承担责任，那么一是测试人员会认真测试，这毫无疑问。二是测试人员会在有限的项目时间内，争取更多的测试时间，对产品的进行更严格的测试 我认为不应该进行惩罚！
惩罚谁都知道意味着什么，扣工资，扣奖金，通报批评。
惩罚就能保证以后回归测试都能通过吗？
我认为应该对好的进行奖励，对有点差距的进行鼓励。一个好的宽松的环境，一个良好的团队，比什么都重要。
惩罚只会导致不团结，导致出现问题相互推诿。
正方观点
我认为应该进行适当的惩罚首先，惩罚的目的是为了更好的保证软件的质量。通常情况下，在一个大型的公司，软件测试人员的工作是很多的，项目和好几个日常可能在同时进行，测试人员应当具备迅速把握需求、挖掘需求的能力，熟练的列出测试功能点，在测试执行时根据checklist检查容易被忽略的点。当然，这其中，会有老项目的优化，对老的需求不了解，会有测试时间不充分，许多日常挤在一个时间发布，但这些都是借口。测试人员的职责就是发现bug，公司会对每个测试人员一个等级称谓，p4\p5\p6...（技术路线），测试时间也会根据他们的经验去分配，测试人员即要保证zero bug的上线，严格的把握质量，那么遗漏到线上的bug将会很少。反之，匆匆测完就交差，线上出现了bug就推说自己测试时间不充分，了解需求不够，这样的态度对软件的质量将是极大的危害。
适当的惩罚，比如可以记录作为年度奖的一个考核项（个人见解）
[[i] 本帖最后由 chop123 于 2009-8-26 09:40 编辑 [/i]] 一个公司如果没有奖惩制度，那如何做到有章可依呢？显示中不是所有人都具备高度自觉性的，所以对于犯错的人必须要有惩罚 这完全是 各人 工作态度和职责问题 如果尽职态度端正 不可能BUG全测试好，但是最起码BUG的数量和严重的显而易见的BUG都基本没问题了，既然漏测了 说明这个BUG很明显，这么明显的BUG 都没测出来，说名什么，工作态度不端正，不尽职，应该惩罚！！！引用楼上：“所谓的“惩罚”不是鞭打测试员告诉他们一定要没有Bug，而是提高测试人员的精神状态的一种方式” 对于“漏测”的测试人员以及“回归测试不通过”的开发人员需要惩罚吗?我个人比较支持反方意见！
出现了上述情况我们就需要分析是什么情况出现上述情况？是因为测试时间不足还是因为个人原因疏忽，通过出现错误到改正错误在到以后避免类似的错误，我想问下正方的同志们，所谓的经验从什么地方来的？中国革命的成功经验是从什么地方来了？认识错误改正错误以后避免类似的错误才是硬道理，而不是靠惩罚，人无完人没有不犯错的人！犯错就要惩罚？？？？？？
[[i] 本帖最后由 jarrey 于 2009-8-28 19:14 编辑 [/i]] 这个还是要分情况，具体问题具体分析，很赞成23#的 产品中出现了bug，不管是否漏测，不应该由测试人员一个人承担，这应该是开发人员和测试人员共同的责任 BUG是不可能没有的！
我觉得不应该惩罚吧！一般情况下，漏测都基本比较偏的功能，或者非关键性所在的功能，应该比较不影响软件的使用的。能不处罚最好不要，免得影响不好！ 我认为要看问题，
如果产生的遗漏是测试条件不满足或测试整体的测试经验不足造成的遗漏，则不应处罚；
如果是有相关的规范或用例，在执行上未按照要求进行，或因为责任心的问题造成的遗漏，则需要处罚； 本质不在于惩罚而在于度量。
0漏测未必就好，相对地，有漏测未必就不好。就像足球场上不丢球的守门员未必是最优秀的守门员一样。