测试：这样显然将来如果发生业务需求变动就会很麻烦，如果所支持的业务类型越来越多，那你这筛选不就渐渐失效了么，到时候效率还是得重新优化的，而且到时候优化难度和测试难度就更大了……你们有没有考虑过把需要处理的数据定期抓出来放到一张表里再去处理，避免放到一个过程里运行呢？

　　编码：……想法倒是可以考虑，不过将来的事情还是将来提需求优化的时候再说吧，这样改造太大了点，风险也大。

　　测试：不行，我们目前这种方法有点饮鸩止渴的意思，将来虽然不一定是我测试这个系统，但是到时候肯定又要从头分析，难度又大，再说将来可能就不是需求而是生产故障了，很浪费大家时间；再说了，你仔细分析一下之后再看看，或许改动没你想象的那么大。

　　编码：你真霸道，好吧，我们回去考虑一下吧，下午下班前给你邮件答复。你测试用例准备得如何了？

　　测试：准备好了，我准备测试XX、XXX、XXXX这几种情况的数据，测试用例清单在早上给你的邮件附件里有，显然我们得把几种常见的数据类型都测试一遍啊……

　　编码：不好意思，打断一下，我觉得你这种类划分好像有点问题吧，XX和XXXX是一种才对，XXX、YY、YYXX这几种又分别是几种不同的分支，无论是改入口条件还是其他方式，我觉得你应该至少把这4种情况都要测试到吧。

　　测试：只是测试性能而已，又不是业务规则变更，有必要么？

　　编码：有必要，你不能轻易相信任何一个编码人员，也不能相信你所测试的只是性能优化，性能优化有时候也会设计逻辑变更，所以还是测试一下吧，呵呵。

　　测试：擦，刚才谁说我霸道来着？好吧，我一会回去补充一下测试用例，唉～

　　编码：嘿嘿，彼此，这个需求先到这，没什么问题我们继续下一个吧……

　　这种简单的沟通可能大家应该会经常遇到，其实就是测试用例评审过程中的一个真实场景的再现，感觉好像大家在相互“找茬“，而实际上我觉得这正是责任意识的体现。如果双方都不假思索，默认对方所采用的工作方法，那么也许真的会出现生产环境故障，带来经济损失。不过正是因为双方都不想背负故障的责任，所以采用”严以待人“的态度工作，合作中出现冲突很正常，但是假如时过境迁，大家肯定还是会想起当时经常吵架但是合作又很成功的那群人。

　　话虽说的简单，但是要大家改变“自扫门前雪”的传统观念，把手伸到协作方的事物里面去，却是一件很难的事情；另外一方面，“严以律己，严以待人”会不会被执行成“宽以律己，严以待人”也是个未知数，所以要全责驱动，还需要管理者制定一些有效可行的激励措施和罚则。我个人觉得可以这么考虑：

　　A、鼓励在静态评审行为中的互动交流和缺陷产出，同时要避免对静态评审缺陷数量或者相关比例性的数字进行讨论甚至考核，以避免因此而挫伤评审活动的积极性；

　　B、定期检视测试缺陷和软件开发过程缺陷，如果这些问题能够被提前发现而没有被发现，那么要对静态评审活动的有效性做出合理解释并且给出改进措施；

　　C、程序问题导致的生产故障和测试遗留缺陷不必区分责任，测试人员与开发人员都要从自身行为中找出不足，并且给出有可行性、可检视的改进措施，定期给出跟踪报告；

　　D、对于同一种类型的问题，如果重复发生，考虑对相关责任人进行通报批评甚至重新评判其绩效；

　　E、对于由问题改进而衍生的可推广的，并且能明显改善开发、测试过程质量的措施，要给出表彰和奖励，用以鼓励能够分析问题本质，总结经验教训的人和行为；

　　F、…… ……

　　结束语

　　笔者的意思很简单，那就是软件开发过程中的所有人都要树立自己为软件质量买单的主人翁意识，而并不是单靠技术非常牛逼的编码或者测试人员来进行软件质量的保证。既然是这么个简单的意思，也就没有必要长篇大论了，希望大家也能踊跃发表自己的意见，既然都是砖家，砖头丢过来不用我接也会有人接的，嘎嘎～～～

　　顺便再罗嗦一句，全责驱动可不是裙带责任哦，希望大家不要弄混了。尤其是在操作过程中，千万不要逮住一个问题就往别的系统或者项目头上扣帽子，要求如何如何，须知每个系统和项目的特征都是不同的，所以弱弱的提醒一下，不要搞无谓的运动哦。

版权声明：本文出自 lyscser 的51Testing软件测试博客：http://www.51testing.com/?68857

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。