Elizabeth Hendrickson谈“缺陷传染症”

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

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

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

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

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

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

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

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

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

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

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

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

查看英文原文: Elizabeth Hendrickson On The Bugs Spread Disease

译者 金毅 多年来服务于欧美软件外包行业从事管理工作,对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。

This entry was posted in Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s