看到一个测试同行发表了一篇文字，题目叫《淘宝质量组三轮测试的感想》。作者在文中提倡“当天发现的bug，开发人员尽量在当天解决，而测试人员尽可能的验证完毕”的做法。我也想谈谈自己的看法。
这种工作模式不一定适合所有的软件开发项目。关键在于：开发组提交修复版本的紧迫程度。有的开发项目的进度非常紧迫，项目经理要求开发人员在测试人员开始测试的当天就提交修复版本，测试人员也在当天验证完所有修复的BUG。但这种情况实属特殊，实际上对项目进度掌控力好的项目经理是不会让这样的状况发生。毕竟这样高效的工作模式可能会让开发人员和测试人员过于焦虑及劳累，开发人员的修复速度远远赶不上测试人员提BUG的速度，在要求尽快修复的压力下，开发人员会很紧张，重现BUG现象到准确定位原因然后修复，这都需要一定的时间，特别是一些棘手的深层次BUG，显然这样的工作强度很高。如果修复花费很长时间，那测试人员也要陪同等待，然后验证修复。长此以往恐怕双方都会吃不消。我就经历过全体组员封闭开发的软件项目，老板为了拉单给客户许下早早交付的承诺，实际上也很难为项目经理，但这样的现象在国内的软件企业比比皆是。我们当时的做法是：开发组按计划在某日下晚班前提交修复版本，测试人员做冒烟测试验证修复版本的可测试性，然后加班做回归测试或在第2日上班时先过滤出状态=fixed的BUG优先做处理，处理完后再进行新的测试。
但我后来换了一个项目组，情况就完全相反，进度不那么紧迫，大家都是不紧不慢的。一般是测试人员提交BUG后几天才修复，测试人员的回归测试也留足时间。当天测试当天提交修复当天验证的情况仅是偶尔几次。
说了那么多，就想总结一句：当天测试当天提交修复当天验证的高强度工作模式只适合特定情况的项目，即特别紧迫那种，但不适合推广到所有的开发项目中去。
相关阅读：
版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。本文出自yantong的51Testing软件测试博客：http://www.51testing.com/?36807
