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实施略有感悟。

Advertisements
此条目发表在Best Practices分类目录。将固定链接加入收藏夹。

发表评论

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