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

默默巫

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

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

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

abbybeach

看问题的严重程度与发现的难度

velata

惩罚的目的是什么？是为了那点微薄的RMB？还是为了提高项目质量？
说说我们这边对两种情况的处理吧
一、漏测
    我们漏测的概念是版本发布到客户那，由客户发现的bug。
    对于这类bug，先有开发分析这个bug的原因，是测试环境跟客户环境不一致？还是真正的代码引入的bug。
    对于这个bug，测试人员在已有的业务理解、测试经验上能否发现？如果这个bug根本原因是需求都没考虑到的情况，或者是本来不在需求、设计文档任何一个地方体现，是开发人员自己加进去的，那测试人员应该是没有责任。
    如果这个bug是需要经过复杂的场景设计才能重现，那么测试用例编写者就应该一起坐下来讨论，要如何在以后的测试中发现类似的问题，并对解决方案进行评估，为了发现这个问题而做的一系列测试场景、数据是否值得？
    如果是很明显的bug，换其他任意一个人来都能发现，或者测试用例上已经明确有此检查点且测试人员给了通过的结论，那就真是这个测试人员的问题了，根据规章制度 该咋办咋办去吧
二、回归测试不通过（昨天打游戏去了，今天补上）
    sorry各位开发，我是觉得一个bug没有解决完全、或者是引入了新的问题，真的是你的问题了……
    一个bug既然提出来了就应该好好分析，此bug是如何产生的？
    是对需求理解不透彻？那就应该再阅读需求文档、仔细推敲，或者是直接问产品组的需求人员；
    是对系统架构不熟悉？那应该加强对所实现系统架构的学习；
    是看轻了bug？随手改掉没改完全，随便改改引入的新问题，那就完全的责任了。

我们组的一女强人说过一句话（俺不晓得她是自己总结的还是在别的地方看到的）
如果开发有这样的观念：所有的bug都是我一手种下的，我肯定有责任
    测试有这样的观念：所有的bug都是从我手下漏的，我肯定有责任
那么系统质量肯定能有保障。

    为什么要绩效考核？为什么要罚款？说白了都是为了提高质量，如果不分情况，统一对漏测的惩罚、对bug解决不完全的惩罚，会导致员工积极性严重降低（深圳某大型外包公司一美国项目前一阵子就出现这种情况，公司遭客户投诉，就对测试、开发进行罚款，导致大量员工辞职）。但是如果有绩效制度，对于真正该罚的人没有罚，也会打击其他努力工作的员工积极性。
    总之，该不该罚、如何罚 不能一概而定。把漏测的类型分类，按情况处置。

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

rainbow2009

对于发生漏测事件，当然具体看漏测具体问题了，如果漏测的问题是只要执行相关的测试用例就能发现的，这样不用说肯定是相关测试人员的工作没有做好了，如果漏掉的问题是比较冷僻的，是情有可原的，毕竟我们谁都不敢说自己测过的版本就是完美的没有问题的，对于漏测我们抓出来并不是要怪谁，要追究谁的责任，我们应该通过分析漏测的原因从而找到测试工作中的漏洞，进行改进，是个人的问题就解决个人问题，是用例没有覆盖到的就添加用例及注意事项，争取下次不要出现类似的错误，亡羊补牢为时不晚，这样才能改进版本的质量。对于回归测试不通过的开发人员，我就不多说，因为我不是开发，不过按照我们公司的制度，这个有点严重哦，不说别的，起码本月的绩效是不好

drwei123

发生漏测的原因是什么，是由于测试人员自身的原因就是没有测试，还是在设计TC的时候就没有想到等等
具体的问题需要具体的分析，要把问题尽可能的分析下。这样才好定位这次漏测的性质是什么.......并对应相应的解决办法。。。。。

橙子

首先，测试人员不能保证软件不存在ＢＵＧ。当然，如果是已设计或写了测试用例，却在测试时忽略，测试人员的工作态度是不正确的。需要有一定的惩罚措施。

回归测试不通过，也不能一概而论。根据其不通过原因来分析。

Gaolihuan

大家都在讲测试哈! 我倒是经历了很多回归测试不通过的情况!
对于开发人员来讲 偶尔的疏忽或许可以谅解 但是频繁的出现返测不通过的情况 是应该引起重视的! 这样会拖垮进度.

至于漏测的情况 如果是按照用例执行就能够发现的问题 势必要承担责任 当然这就需要一个全面的测试计划. 我发现正方说话的口气多是处于领导层的人士 .. 似乎担了不体察民间疾苦的嫌疑

好的情绪肯定会提高工作效率 提升工作质量 但是这样的好情绪 并不是单纯的惩罚可以做到的 更多需要的是鼓励

fangzhijuan

原帖由 velata 于 2009-8-4 23:49 发表
惩罚的目的是什么？是为了那点微薄的RMB？还是为了提高项目质量？
说说我们这边对两种情况的处理吧
一、漏测
    我们漏测的概念是版本发布到客户那，由客户发现的bug。
    对于这类bug，先有开发分析这个bug的 ...

支持,分析的很全面..

zlpxm

我是觉得漏测和回归不通过的情况常常存在，需要考虑的是在开发回归一次不通过的情况下且测试人员将BUG已描述清楚和详细，但开发人员在修改后，再次被测试人员打回。这时可以说下是这个开发人员的问题了。多次回归不通过时，可以考虑必要的处罚，但处罚不一定是$.
漏测的情况很多，但比如需求上有明确的说明，用例也有设计在内，而测试人员漏测的情况，是否是考虑不够全面还是没有参考相关文档引起？可以考虑处罚。
但正常情况下，不赞成处罚！
因为没人愿意一个问题修改三四遍还不通过，也不会有人愿意将明显的bug说测试通过。

[ 本帖最后由 zlpxm 于 2009-8-20 11:33 编辑 ]

liuxz

扯淡，测试人员测过就能没BUG，开发人员一改BUG就没了，那就不会有这么多公司被质量拖死了

郁闷的芝麻

一个公司如果没有奖惩制度，那如何做到有章可依呢？显示中不是所有人都具备高度自觉性的，所以对于犯错的人必须要有惩罚

546249663

这完全是 各人 工作态度和职责问题 如果尽职态度端正 不可能BUG全测试好，但是最起码BUG的数量和严重的显而易见的BUG都基本没问题了，既然漏测了 说明这个BUG很明显，这么明显的BUG 都没测出来，说名什么，工作态度不端正，不尽职，应该惩罚！！！引用楼上：“所谓的“惩罚”不是鞭打测试员告诉他们一定要没有Bug，而是提高测试人员的精神状态的一种方式”

applejuzi

这个还是要分情况，具体问题具体分析，很赞成23#的

reshma

产品中出现了bug，不管是否漏测，不应该由测试人员一个人承担，这应该是开发人员和测试人员共同的责任

飞流直下

我认为要看问题，
如果产生的遗漏是测试条件不满足或测试整体的测试经验不足造成的遗漏，则不应处罚；
如果是有相关的规范或用例，在执行上未按照要求进行，或因为责任心的问题造成的遗漏，则需要处罚；

huipeng

没意思，谁都不容易啊

zhangchuangfu

我觉得者的看是一个什么样的公司，一个公司如果没有自己的管理规范，给测试和开发的工资同行相比比较低，就那点钱，谁愿意为产品的质量负责，我估计再罚款就没法做了

找茬

漏测分为设计漏测和执行漏测.
设计漏测是由于测试人员对测试特性了解不充分导致;
执行漏测是由于对测试特性是否稳定判断错误,未进行覆盖测试;

问题单回归不通过分为问题未修改,修改不全面,引入新问题,回归未按照提单环境回归等;
问题未修改和修改不全面是开发人员主观责任感不强;
引入新问题是在审查修改环节监审粒度不到位;
回归问题单未按照提单环境回归是测试人员对回归操作不规范所导致,虽然问题应该在不同环境中均不得复现,但是环境的不同出发问题的因素不尽相同.

lcldhlg

我认为漏测并非所有责任都在于测试人员，因为引入这个BUG的不是测试人员而是在开发的时候产生了这个BUG，并且这个BUG可能很隐秘，测试的深度和广度并非无限的，有些BUG很难被发现。如果发现漏测的BUG，而这个责任相对较大的，我个人认为是引入这个BUG的开发人员，而非测试人员。当然，不论是开发人员，还是测试人员都需要负一定的责任。作为测试人员，我们的责任是尽量保证软件的质量，帮助开发人员提高软件质量。即使是微软公司或者IBM，他们亦不能保证软件的100%质量。就拿XP系统为例，经过多少的补丁更新，但依然有很多漏洞出现。没有人能使软件质量达到100%，而只能趋近于100%。
对于回归测试不通过，就给予开发人员惩罚。定义太模糊了，没有经过分析问题的原因，就给予惩罚，这是完全没有理性处理问题的做法。
另外，漏测和回归测试不通过要给予惩罚的话，我认为不应该只有惩罚，而应该有对等的奖励方式。大多数人都认为做对了是完全应该的，理所当然不用奖励了，做错了就是不应该的，必须惩罚。如果需要对做错这件事惩罚，那么对做对了这一件事是否应该给予相应的奖励呢？惩罚与奖励应该是相对立、不可分割的统一体。
我认为这种方式的效果并不明显，不是提高软件质量的本质因素。只是作为一种推动力，能推动软件质量的提高，亦有可能往相反的方向走。
因此，我的结论是：奖、惩必须同时存在且有对等关系；理性客观的分析问题的原因，关键是定位问题原因和寻找解决方案。

丫崽儿

原帖由 velata 于 2009-8-4 23:49 发表
惩罚的目的是什么？是为了那点微薄的RMB？还是为了提高项目质量？
说说我们这边对两种情况的处理吧
一、漏测
    我们漏测的概念是版本发布到客户那，由客户发现的bug。
    对于这类bug，先有开发分析这个bug的 ...

赞成！！