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

默默巫

背景描述：对于“漏测”的测试人员以及“回归测试不通过”的开发人员需要惩罚吗？

奖项	获奖名单	奖励	答案连接
最佳话题PK手	velata	价值50元的当当网礼品+最佳PK手勋章	3#

如果你也有矛盾的问题想提出来和大家一起讨论，请点击此处>>
说不定下期PK的话题就是由你提出的哦，请快快参与吧

wuchunying

先就测试人员‘漏测’是否处罚讲一下个人观点，1.公司的需求开发测试都不完备，需求文档都只是简单描述模块功能，开发在没有吃透需求的情况下先开发后改动，等到系统都做完了，再扔给测试，且不会给足够的时间测试，所以这类公司对测试用例的要求很一般，主要要求跑完所有的流程和功能，可以用就行了。这种项目或产品的质量要求就不会很高，‘漏测’极有可能了，不过也不可怕，后期都会有维护，发现了问题改过了就好了。需求不精确，测试时间人员都不够，测试人员的压力本来就很大，加班加点，如果还要搞‘漏测处罚’的 话是不公平的，也不能解决根本问题，应当完善。2.公司的需求开发测试都比较完备，对项目/产品的要求也比较高，一般都会有正规的测试小组，但还是不应当提倡‘处罚’，它会带来很多弊端：新员工和初级员工难免会漏测，处罚会带来打击；写用例和执行分开，漏测了，处罚谁；交叉测试的时候发现对方漏测的地方越多就意味就对方的处罚也越多，不利用团结；在分配测试任务的时候，大家都会想要BUG少的模块或者开发水平高的模块，谁都不会想要处罚的，这会造成责任的推诿；员工会规避处罚 ，这也是人之常情，往往会墨守成规，不去主动承担难的，增加的测试任务，把时间都花在不停的找bug上，不热衷去研究新的测试方法等等……总之弊大于利。
    同理‘回归测试不通过的开发人员需要惩罚’会给开发和测试组成的项目团队造成分裂，团队内出现摩擦，效率就可能会降低等等。
    以上或许就是公司不推行惩罚的一小部分原因吧，毕竟公司的管理层大多是明智的。

[ 本帖最后由 wuchunying 于 2009-8-6 16:27 编辑 ]

阿七

bug是杀不尽的!

pulingwang

从实际来说，bug是很容易被漏测的。而且，漏测bug 的存在对于测试人员本身也是一种打击，想想自己是否专业？本来，找bug是件很创新的事情，需要测试人员静心分析问题，才能找到。我不排除有些测试 人员是比较不专业导致的，但是成长也是需要时间的。
所以，对于漏测的问题，就像是bug的红旗，大家只有在附近不断的寻找，才能保证产品的质量。
惩罚？测试本身是项脑力劳动，惩罚本身就是消极的，还会引起测试人员心情的波动和自信心的建立

woza

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

woza

原帖由 jessies 于 2009-8-5 22:43 发表
我对测试的看法就是，我同意允许发布的产品，如果发现问题，那么就是测试职责。
如果一个测试拿“测试不能做到百分百发现bug”这个观点来作为漏测的理由，那么我只能说，测试人员的态度立场就是不太积极的。
当然惩 ...

产品质量不能仅仅由测试来把关。所有对于产品有Input的人，都对产品质量有责任。

测试有一个“just enough"原则。这个原则是建立在成本/效益的基础上。为了在系统中找到的某些bug如果要多花几倍的成本，那么对于企业来说，可能还不如事后去做hot fix来的核算。

并不是所有客户发现的bug，都属于”漏测“范围。如果是基本的Happy path，被客户发现问题，那的确是研发人员的责任。如果是那些本来就不在测试范围中的，应该不属于漏测。反过来讲，我们应该根据客户反馈（客户发现的bug也是一种客户反馈）来改进和调整测试范围和测试方法。只有工作态度问题才需要惩罚，其他的都应该作为持续改进来处理。整个团队的目的在于做出更好的产品，而不是寻找谁是坏蛋。

liujinkui

我认为在好的公司是不需要制定惩罚措施来约束自己的员工
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不是测试出来的，而是开发出来的。

candy_83

我觉得漏测和测试不通过在测试过程中是经常会发生的现象，如果经常采取惩罚措施，那估计测试和开发人员的神经会非常紧张，在这么紧张的情绪下，会出现好的工作产品吗？显然，答案是否定的。当然这不等于纵容漏测和允许测试不通过，当出现漏测和测试不通过的情况时，测试和开发人员应该反思，我为什么没有想到这个测试用例？我为什么没有正确的设计某个功能的代码？去寻找问题的根源，在下一轮工作中，尽量考虑全面一点，避免上一轮工作中所发生的错误，人不是完美的，都是需要时间慢慢完善的。希望大家工作越来越好。

箭在行动

1.“漏测”的主要原因是什么？测试用例不完善，测试时间不充分，测试资源不充分，测试人员所用的测试环境远远少于用户的应用环境等等，这些都是可能造成“漏测”的原因，没有一个测试人员不希望自己能把所有的BUG都找出来（敷衍了事者除外）。在中国90%的以上的公司中，测试人员的薪资都是很微薄的，那么当他出现“漏测”BUG的时候，公司进行惩罚，怎么惩罚？难道要漏掉1个BUG罚款100RMB么，开玩笑。如果多漏几个岂不是可能是负的了。这个月扣掉几百，那么下个月公司又凭什么让员工去努力呢？长此以往，谁又能经得住这样的考验呢？
2.“回归测试”不通过的原因也可能是多种多样的，如果员工写的代码出现了Bug（即使是经过多次修改）就要惩罚，那么员工所想的尽可能少出Bug,那么这样下去员工又怎么能有进步呢？
3.人无完人，比尔盖茨领导下的微软，微软操作系统天天都在打补丁，那么多N人做出来的东西都有这么多的Bug，我们写出来的代码存在Bug又有什么不可原谅的呢？
4.当出现问题时，用惩罚的措施来迫使员工少出问题，这是最滥的手法。员工最需要的鼓励和理解，一句“你做的很少，要是没有这些问题会更好。下次，你不会再出现这样的问题了吧？”会比罚钱更加有用。
5.以上献给想把工作做好的兄弟姐妹们。

箭在行动

惩罚的中文解释
以下结果由汉典提供词典解释
基本解释

1. [punish]∶惩戒;责罚;处罚
惩罚坏人
2. [discipline]∶施加鞭鞑或体罚使之服贴、受辱或以苦行赎罪
看到许多可怜的奴隶正在鞭打惩罚自己
详细解释
处罚。
《魏书·西域传·于阗》：“其刑法，杀人者死，餘罪各随轻重惩罚。” 杨朔 《渔笛》：“坏人都得到应有的惩罚，好人也踏上幸福的道路。” 艾芜 《漫谈三十年代的“左联”（一）》：“这是用经济上的惩罚，来补充**上的虐待。”

whoisangle

举个极端的例子：如果测试人员承担责任，那么一是测试人员会认真测试，这毫无疑问。二是测试人员会在有限的项目时间内，争取更多的测试时间，对产品的进行更严格的测试

狩猎者

我认为不应该进行惩罚！
惩罚谁都知道意味着什么，扣工资，扣奖金，通报批评。
惩罚就能保证以后回归测试都能通过吗？
我认为应该对好的进行奖励，对有点差距的进行鼓励。一个好的宽松的环境，一个良好的团队，比什么都重要。
惩罚只会导致不团结，导致出现问题相互推诿。

chop123

我认为应该进行适当的惩罚
首先，惩罚的目的是为了更好的保证软件的质量。通常情况下，在一个大型的公司，软件测试人员的工作是很多的，项目和好几个日常可能在同时进行，测试人员应当具备迅速把握需求、挖掘需求的能力，熟练的列出测试功能点，在测试执行时根据checklist检查容易被忽略的点。当然，这其中，会有老项目的优化，对老的需求不了解，会有测试时间不充分，许多日常挤在一个时间发布，但这些都是借口。测试人员的职责就是发现bug，公司会对每个测试人员一个等级称谓，p4\p5\p6...（技术路线），测试时间也会根据他们的经验去分配，测试人员即要保证zero bug的上线，严格的把握质量，那么遗漏到线上的bug将会很少。反之，匆匆测完就交差，线上出现了bug就推说自己测试时间不充分，了解需求不够，这样的态度对软件的质量将是极大的危害。
     适当的惩罚，比如可以记录作为年度奖的一个考核项（个人见解）

[ 本帖最后由 chop123 于 2009-8-26 09:40 编辑 ]

jarrey

对于“漏测”的测试人员以及“回归测试不通过”的开发人员需要惩罚吗?我个人比较支持反方意见！
出现了上述情况我们就需要分析是什么情况出现上述情况？是因为测试时间不足还是因为个人原因疏忽，通过出现错误到改正错误在到以后避免类似的错误，我想问下正方的同志们，所谓的经验从什么地方来的？中国革命的成功经验是从什么地方来了？认识错误改正错误以后避免类似的错误才是硬道理，而不是靠惩罚，人无完人没有不犯错的人！犯错就要惩罚？？？？？？

[ 本帖最后由 jarrey 于 2009-8-28 19:14 编辑 ]

鹭岛

BUG是不可能没有的！
我觉得不应该惩罚吧！一般情况下，漏测都基本比较偏的功能，或者非关键性所在的功能，应该比较不影响软件的使用的。能不处罚最好不要，免得影响不好！

gracech

本质不在于惩罚而在于度量。
0漏测未必就好，相对地，有漏测未必就不好。就像足球场上不丢球的守门员未必是最优秀的守门员一样。

yixiangke

漏测和回归不通过是必然会发生的事情，除非开发和测试什么都不做。
惩罚不能解决问题，只会影响员工的工作积极性与热情，使大家都成了惊弓之鸟，使开发和测试之间产生矛盾。
但是，漏测与回归测试不通过是必须引起重视的，测试人员和开发人员要认真分析原因，积极想对策避免下次再出现同样的错误。
我想大家本质上都是想把工作做好，如果频繁漏测，回归不通过，项目的进度因为自己受影响，即使别人不说什么，自己已经很难过了。所以把问题展示出来就是一种“惩罚”了。
惩罚不该做，但是奖励是一定要有的。如果测试和开发很少漏测很少回归不通过，一定要给予奖励，并让团队内的所有人都知道。这是正确的导向！

gongx2008

需要制度，但也要考虑人性化

qzp_peng

发现bug,优先对bug进行分析。需要考虑以下几个方面。
1、bug是怎样产生的？
2、是否超出需求？需求是否明确？
3、bug类别。
4、测试或研发人员平时一贯的工作态度。
   我有体会。有个测试人员平时工作认真、积极、自尊性很强的人。可有个版本发布后到客户那里由我们的技术支持人员碰到。后经过分析是哪个测试人员的责任，由于疏忽导致。当时我只说了一句话“看来我们测试还需要更加仔细”，也没有进行处罚。后来他工作更认真、仔细。还主动加班。后来我明白了对不同的问题、不同的人、不同的场合采取不同的处理方法。是我们作为管理者应多思考的问题。

hhwwxx

惩罚的确不是好的手段，可以说是下策。特别是对测试人员。测试人员依靠发掘宝藏（BUG）的激情存活着，所谓漏测，有可能是不认真测，也有可能是没注意到，也可能是测试用例不详细，也有可能是他觉得不是BUG，衡量这些，十分困难，却用惩罚来打击发掘宝藏的积极性？ 哪个出色的探险团队会有发现不了该发现的宝藏就要被惩罚的规定呢？ 如果把测试人员比作用鞭子抽打才出成绩的软件奴隶，还不如让他们做出色的探险团队。让他们觉得找到的BUG，大家重视得像发现宝藏一样，给个GOOD CATCH给他，让他享受发现BUG的喜悦和成就感。在这样的管理之下，相信他们会努力地去做。另外，测试并不能只靠个人力量，虽然大家有分工，但是找出遗漏的问题是一个团队的责任，并且应该更加相信团队而非个人，对应这点，测试模块的轮换等管理的手段，的确能有效避免漏测。哪怕是惩罚，也是一个团队的责任。