Elizabeth Hendrickson 最近发表文章,讨论了发生在缺陷评估会议上的浪费。在她的博客 testobsessed.com ,她指出,很多公司花了很多时间和金钱在测试上,但又不真正地利用好测试结果。
就像她在她的文章中解释得那样,软件工程社区中有一个常见但错误的观点:缺陷是不可避免的,而且不是所有缺陷都需要修复的。这也就是为什么“可以根据 ROI 来决定某个缺陷要修复还是先放一放”。
她曾经工作过的两个公司都深受这种观点之害。公司没有被缺陷直接整垮,但是就像 Hendrickson 解释得那样,缺陷成为了“弥漫的传染病”,降低了生产力,也拖死了测试人员和工程师。具体表现为:
那个隐性成本侵蚀了我们的生活:在缺陷评估会议上的争吵时间;一次又一次地受已知问题影响的时间;为了一些小的变更不断地修改脆弱而且易错的代码库的时间;不断重新分类、排列待办事项列表的时间。这些花费非常让人沮丧,也是相当昂贵的!
Hendrickson 根据她的经验,给出了结论。
取消所有缺陷评估会议;花时间预防缺陷;尽早测试,多测试,从而能更早发现缺陷;一旦发现缺陷立即修复;尽早修复你的“破窗户”
很多读者评论了这篇文章,比如,Jim Gay 说道:
我的经历是某些缺陷其实表明了业务流程有问题。比如一个分析人员告诉你,你应该去做 X,于是你开发了 X,但用户质疑你为什么不做 Y。不管代码上的缺陷抑或流程缺陷都意味着你得去着手修复它们。
Gabe Newcomb 不同意 Hendrickson 的所有观点:
这暗示所有的缺陷都是值得修复的,而且修复缺陷比实现新的功能更加重要。这跟我的经验不符合。缺陷评估流程很好地回答了诸如什么时候(是否)修复一个缺陷,它和其他工作有什么关联等重要问题。你又准备怎么来回答这些问题呢?
Steve Fenton 是个程序员,他也认为所有的缺陷都应该被修复,因为:
修复缺陷所花的时间几乎总是要比容忍它所带来的无尽的循环要短,也比对客户产生的影响要值得。在会议上讨论一个历史遗留缺陷,或者碰巧一次又一次地被测试人员提出,又被程序员一次又一次地以重复缺陷为由而关闭。缺陷拖得越久,产生的成本也就非常可能比直接修复的成本要来得更高。
评论