“漏测”的测试人员需要惩罚？（2009-8-4）获奖名单已公布
背景描述：对于“漏测”的测试人员以及“回归测试不通过”的开发人员需要惩罚吗？奖项获奖名单奖励答案连接最佳话题PK手velata价值50元的当当网礼品+最佳PK手勋章3#
如果你也有矛盾的问题想提出来和大家一起讨论，请点击此处>>
说不定下期PK的话题就是由你提出的哦，请快快参与吧
看问题的严重程度与发现的难度
看问题的严重程度与发现的难度 如果不和惩罚机制相挂钩的话，相信很难提高项目的质量，起码应当对漏测的问题进行分类，然后按照严重程度，记录漏测的问题。最基础的作用是让leader们，有一个参考，谁工作做的好与不好。也会影响到与自己息息相关的“绩效”，这样也算是一种惩罚了吧。。。中立态度
惩罚的目的是什么？是为了那点微薄的RMB？还是为了提高项目质量？说说我们这边对两种情况的处理吧
一、漏测
我们漏测的概念是版本发布到客户那，由客户发现的bug。
对于这类bug，先有开发分析这个bug的原因，是测试环境跟客户环境不一致？还是真正的代码引入的bug。
对于这个bug，测试人员在已有的业务理解、测试经验上能否发现？如果这个bug根本原因是需求都没考虑到的情况，或者是本来不在需求、设计文档任何一个地方体现，是开发人员自己加进去的，那测试人员应该是没有责任。
如果这个bug是需要经过复杂的场景设计才能重现，那么测试用例编写者就应该一起坐下来讨论，要如何在以后的测试中发现类似的问题，并对解决方案进行评估，为了发现这个问题而做的一系列测试场景、数据是否值得？
如果是很明显的bug，换其他任意一个人来都能发现，或者测试用例上已经明确有此检查点且测试人员给了通过的结论，那就真是这个测试人员的问题了，根据规章制度 该咋办咋办去吧:(
二、回归测试不通过（昨天打游戏去了，今天补上）
sorry各位开发，我是觉得一个bug没有解决完全、或者是引入了新的问题，真的是你的问题了……
一个bug既然提出来了就应该好好分析，此bug是如何产生的？
是对需求理解不透彻？那就应该再阅读需求文档、仔细推敲，或者是直接问产品组的需求人员；
是对系统架构不熟悉？那应该加强对所实现系统架构的学习；
是看轻了bug？随手改掉没改完全，随便改改引入的新问题，那就完全的责任了。
我们组的一女强人说过一句话（俺不晓得她是自己总结的还是在别的地方看到的）
如果开发有这样的观念：所有的bug都是我一手种下的，我肯定有责任
测试有这样的观念：所有的bug都是从我手下漏的，我肯定有责任
那么系统质量肯定能有保障。
为什么要绩效考核？为什么要罚款？说白了都是为了提高质量，如果不分情况，统一对漏测的惩罚、对bug解决不完全的惩罚，会导致员工积极性严重降低（深圳某大型外包公司一美国项目前一阵子就出现这种情况，公司遭客户投诉，就对测试、开发进行罚款，导致大量员工辞职）。但是如果有绩效制度，对于真正该罚的人没有罚，也会打击其他努力工作的员工积极性。
总之，该不该罚、如何罚 不能一概而定。把漏测的类型分类，按情况处置。
[ 本帖最后由 velata 于 2009-8-6 21:27 编辑 ] 对于发生漏测事件，当然具体看漏测具体问题了，如果漏测的问题是只要执行相关的测试用例就能发现的，这样不用说肯定是相关测试人员的工作没有做好了，如果漏掉的问题是比较冷僻的，是情有可原的，毕竟我们谁都不敢说自己测过的版本就是完美的没有问题的，对于漏测我们抓出来并不是要怪谁，要追究谁的责任，我们应该通过分析漏测的原因从而找到测试工作中的漏洞，进行改进，是个人的问题就解决个人问题，是用例没有覆盖到的就添加用例及注意事项，争取下次不要出现类似的错误，亡羊补牢为时不晚，这样才能改进版本的质量。对于回归测试不通过的开发人员，我就不多说，因为我不是开发，不过按照我们公司的制度，这个有点严重哦，不说别的，起码本月的绩效是不好
应该有惩罚措施
如果问题很严重的话，就要找是测试的问题还是开发的问题，但是也不应该惩罚的过于严重有的公司就没有惩罚措施，最后出问题的时候，谁都有责任，公司根本就惩罚不了
所以我个人觉得就应该有惩罚措施，漏测就是测试责任，回归不过就找开发~，不过也得具体问题具体分析
惩罚--弊大于利
先就测试人员‘漏测’是否处罚讲一下个人观点，1.公司的需求开发测试都不完备，需求文档都只是简单描述模块功能，开发在没有吃透需求的情况下先开发后改动，等到系统都做完了，再扔给测试，且不会给足够的时间测试，所以这类公司对测试用例的要求很一般，主要要求跑完所有的流程和功能，可以用就行了。这种项目或产品的质量要求就不会很高，‘漏测’极有可能了，不过也不可怕，后期都会有维护，发现了问题改过了就好了。需求不精确，测试时间人员都不够，测试人员的压力本来就很大，加班加点，如果还要搞‘漏测处罚’的 话是不公平的，也不能解决根本问题，应当完善。2.公司的需求开发测试都比较完备，对项目/产品的要求也比较高，一般都会有正规的测试小组，但还是不应当提倡‘处罚’，它会带来很多弊端：新员工和初级员工难免会漏测，处罚会带来打击；写用例和执行分开，漏测了，处罚谁；交叉测试的时候发现对方漏测的地方越多就意味就对方的处罚也越多，不利用团结；在分配测试任务的时候，大家都会想要BUG少的模块或者开发水平高的模块，谁都不会想要处罚的，这会造成责任的推诿；员工会规避处罚 ，这也是人之常情，往往会墨守成规，不去主动承担难的，增加的测试任务，把时间都花在不停的找bug上，不热衷去研究新的测试方法等等……总之弊大于利。同理‘回归测试不通过的开发人员需要惩罚’会给开发和测试组成的项目团队造成分裂，团队内出现摩擦，效率就可能会降低等等。
以上或许就是公司不推行惩罚的一小部分原因吧，毕竟公司的管理层大多是明智的。
[ 本帖最后由 wuchunying 于 2009-8-6 16:27 编辑 ] bug是杀不尽的! 发生漏测的原因是什么，是由于测试人员自身的原因就是没有测试，还是在设计TC的时候就没有想到等等
具体的问题需要具体的分析，要把问题尽可能的分析下。这样才好定位这次漏测的性质是什么.......并对应相应的解决办法。。。。。
站在客观的角度看问题
从实际来说，bug是很容易被漏测的。而且，漏测bug 的存在对于测试人员本身也是一种打击，想想自己是否专业？本来，找bug是件很创新的事情，需要测试人员静心分析问题，才能找到。我不排除有些测试 人员是比较不专业导致的，但是成长也是需要时间的。所以，对于漏测的问题，就像是bug的红旗，大家只有在附近不断的寻找，才能保证产品的质量。
惩罚？测试本身是项脑力劳动，惩罚本身就是消极的，还会引起测试人员心情的波动和自信心的建立 只有态度问题才需要惩罚。如果是能力问题，需要的是培训。 我对测试的看法就是，我同意允许发布的产品，如果发现问题，那么就是测试职责。
如果一个测试拿“测试不能做到百分百发现bug”这个观点来作为漏测的理由，那么我只能说，测试人员的态度立场就是不太积极的。
当然惩罚也许没有必要，但是测试人员本身就需要有这种意识，一种对漏测bug负责的意识。经历过我的产品，我也许不能保证百分百完美，但是至少我们需要保证在一定的用户使用时间内，它是没有问题的。当然这个时限可能各个产品不一样。
对于上面的有些观点，我有些不是很同意，漏测就是漏测，没有什么应该发现和冷僻的就情有可原的说法。如果是一个bug，漏测了，测试就需要对缺陷进行负责，测试需要反思，为什么这个bug我没有发现，在那个阶段我可能发现，或者使用什么测试方法我可能发现。
当然更加积极的方式是，我们对缺陷进行后期的分析和以后避免，但是如果没有一定的惩罚，也许一味的使用温和的方式，很多时候因为没有责任也就没有压力和意识/
所以我还是支持一定程度的惩罚，但是万事不能过分，过了就失去了鞭策意义。
最近也在思考这些问题，如果有不同意见的，也欢迎拍砖和私下交流。可能各个公司的情况不一样吧:lol
[ 本帖最后由 jessies 于 2009-8-5 22:44 编辑 ]
产品问题是所有人的责任
原帖由 jessies 于 2009-8-5 22:43 发表 http://bbs.51testing.com/images/common/back.gif我对测试的看法就是，我同意允许发布的产品，如果发现问题，那么就是测试职责。
如果一个测试拿“测试不能做到百分百发现bug”这个观点来作为漏测的理由，那么我只能说，测试人员的态度立场就是不太积极的。
当然惩 ...
产品质量不能仅仅由测试来把关。所有对于产品有Input的人，都对产品质量有责任。
测试有一个“just enough"原则。这个原则是建立在成本/效益的基础上。为了在系统中找到的某些bug如果要多花几倍的成本，那么对于企业来说，可能还不如事后去做hot fix来的核算。
并不是所有客户发现的bug，都属于”漏测“范围。如果是基本的Happy path，被客户发现问题，那的确是研发人员的责任。如果是那些本来就不在测试范围中的，应该不属于漏测。反过来讲，我们应该根据客户反馈（客户发现的bug也是一种客户反馈）来改进和调整测试范围和测试方法。只有工作态度问题才需要惩罚，其他的都应该作为持续改进来处理。整个团队的目的在于做出更好的产品，而不是寻找谁是坏蛋。
具体情况具体分析
首先，测试人员不能保证软件不存在ＢＵＧ。当然，如果是已设计或写了测试用例，却在测试时忽略，测试人员的工作态度是不正确的。需要有一定的惩罚措施。回归测试不通过，也不能一概而论。根据其不通过原因来分析。
为什么没有人提到开发人员 0 0?
大家都在讲测试哈! 我倒是经历了很多回归测试不通过的情况!对于开发人员来讲 偶尔的疏忽或许可以谅解 但是频繁的出现返测不通过的情况 是应该引起重视的! 这样会拖垮进度.
至于漏测的情况 如果是按照用例执行就能够发现的问题 势必要承担责任 当然这就需要一个全面的测试计划. 我发现正方说话的口气多是处于领导层的人士 .. 似乎担了不体察民间疾苦的嫌疑
好的情绪肯定会提高工作效率 提升工作质量 但是这样的好情绪 并不是单纯的惩罚可以做到的 更多需要的是鼓励:handshake 原帖由 velata 于 2009-8-4 23:49 发表 http://bbs.51testing.com/images/common/back.gif
惩罚的目的是什么？是为了那点微薄的RMB？还是为了提高项目质量？
说说我们这边对两种情况的处理吧
一、漏测
我们漏测的概念是版本发布到客户那，由客户发现的bug。
对于这类bug，先有开发分析这个bug的 ...
支持,分析的很全面.. 在大的层面上，应该对漏测和回归测试不通过的行为予以记录并适当惩罚。因为如果不做纪律性的约束，就不会引起测试人员和开发人员的重视。
但同时，这里面涉及到很多问题，众所周知，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不是测试出来的，而是开发出来的。 需要 我觉得漏测和测试不通过在测试过程中是经常会发生的现象，如果经常采取惩罚措施，那估计测试和开发人员的神经会非常紧张，在这么紧张的情绪下，会出现好的工作产品吗？显然，答案是否定的。当然这不等于纵容漏测和允许测试不通过，当出现漏测和测试不通过的情况时，测试和开发人员应该反思，我为什么没有想到这个测试用例？我为什么没有正确的设计某个功能的代码？去寻找问题的根源，在下一轮工作中，尽量考虑全面一点，避免上一轮工作中所发生的错误，人不是完美的，都是需要时间慢慢完善的。希望大家工作越来越好。
