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

velata

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

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

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

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