BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Elizabeth Hendrickson谈“缺陷传染症”

| 作者 Michael Stal 关注 0 他的粉丝 ,译者 金毅 关注 0 他的粉丝 发布于 2012年8月20日. 估计阅读时间: 2 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

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

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

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

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

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

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

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

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

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

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

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

深度内容

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT