Elizabeth Hendrickson近发表文章，讨论了发生在缺陷评估会议上的浪费。她指出，很多公司花了很多时间和金钱在测试上，但又不真正地利用好测试结果。

　　像她在她的文章中解释得那样，软件工程社区中有一个常见但错误的观点：缺陷是不可避免的，而且不是所有缺陷都需要修复的。这也是为什么“可以根据ROI来决定某个缺陷要修复还是先放一放”。

　　她曾经工作过的两个公司都深受这种观点之害。公司没有被缺陷直接整垮，但是像Hendrickson解释得那样，缺陷成为了“弥漫的传染病”，降低了生产力，也拖死了测试人员和工程师。具体表现为：

　　那个隐性成本侵蚀了我们的生活：在缺陷评估会议上的争吵时间；一次又一次地受已知问题影响的时间；为了一些小的变更不断地修改脆弱而且易错的代码库的时间；不断重新分类、排列待办事项列表的时间。这些花费非常让人沮丧，也是相当昂贵的！

　　Hendrickson根据她的经验，给出了结论。

　　取消所有缺陷评估会议；花时间预防缺陷；尽早测试，多测试，从而能更早发现缺陷；一旦发现缺陷立即修复；尽早修复你的“破窗户” 。

　　很多读者评论了这篇文章，比如，Jim Gay说道：

　　我的经历是某些缺陷其实表明了业务流程有问题。比如一个分析人员告诉你，你应该去做X，于是你开发了X，但用户质疑你为什么不做Y。不管代码上的缺陷抑或流程缺陷都意味着你得去着手修复它们。

　　Gabe Newcomb不同意Hendrickson的所有观点：

　　这暗示所有的缺陷都是值得修复的，而且修复缺陷比实现新的功能更加重要。这跟我的经验不符合。缺陷评估流程很好地回答了诸如什么时候（是否）修复一个缺陷，它和其他工作有什么关联等重要问题。你又准备怎么来回答这些问题呢？

　　Steve Fenton是个程序员，他也认为所有的缺陷都应该被修复，因为：

　　修复缺陷所花的时间几乎总是要比容忍它所带来的无尽的循环要短，也比对客户产生的影响要值得。在会议上讨论一个历史遗留缺陷，或者碰巧一次又一次地被测试人员提出，又被程序员一次又一次地以重复缺陷为由而关闭。缺陷拖得越久，产生的成本也非常可能比直接修复的成本要来得更高。