为什么在流程后期发现缺陷成本更高?

时间:2009-08-26 11:43:31

标签: debugging agile

为什么在此过程的后期发现缺陷成本更高?

我听到了很多,但我很难理解并将上下文/示例放在这里。

12 个答案:

答案 0 :(得分:13)

你正在盖房子。你将污水管道铺设在地基中,但你不知道其中一根管子被一只死的刺猬堵住了。

你想找出:

  • 在您倒入混凝土之前
  • 房子完工后,新主人试图使用厕所?

(这个比喻中有一个“Stack Overflow”的笑话.8 - )

答案 1 :(得分:8)

找到错误所需的时间越长,那么:

  • 错误的行为可能被接受为正确的越多,其他更多东西可能依赖于该行为(Windows因此而臭名昭着)。

  • 系统可能已经变得越紧密,并且提取的bug就越难。

  • 通过复制粘贴或在使用错误代码的客户端中,错误的错误行为在其他地方重复的可能性越高。

  • 自代码最初编写以来所用的时间越长,理解代码的难度就越大。

  • 对于那些了解系统原始部分的人来说修复它的可能性越小。

答案 2 :(得分:3)

越晚发现错误,情况就越糟糕。当您在编码后立即发现错误时,您会记住所有行为,并确切地知道导致它的变化。一旦你知道它所处的位置,你就可以专注于这个问题。

当你花很长时间,开发人员不再记得它是如何工作的,并且还有更多的地方需要调查才能找到bug。也许编写错误的开发人员也不再在公司工作。

此外,随着时间的推移,代码的更多部分可能依赖于错误的代码,您可能也需要修复它们。

最后,涉及用户的问题。如果您在发布后发现错误,更多用户会对此感到沮丧,并且您的产品图片会更糟。用户也可能习惯于解决此错误,在修复错误后可能会开始失败。

总结:当你花很长时间发现错误时

  • 您要调查的范围更大
  • 创建错误的开发人员可能不再存在,其他开发人员将不得不更多地研究代码,找到它,理解它并修复它
  • 您可能还需要修复依赖于错误代码的部件(并且会有更多这样的部件)
  • 用户已经对此错误感到沮丧,并且产品的图像将被损坏

答案 3 :(得分:3)

这可以用一个简单的(如果不是微不足道的)例子来说明。

使用一条消息进行简单对话,只需两个按钮“确定”和“取消”。

假设错误是拼写错误。

如果在产品发布后发现这一点,则必须发布新版本的产品,并附带与之相关的所有费用。手册需要重印。

如果在最终测试中发现,则必须重新打印手册。代码需要重写并重新运行测试。

如果在开发过程中发现这一点,则只需修复代码的成本。

如果在设计过程中发现这种情况,则首次正确编写代码 - 无需花费。

答案 4 :(得分:2)

  1. 在编写代码时,没有人能够理解代码。
  2. 人们可能已经开始依赖那里的虫子了。
  3. 你可能需要修复bug已经存掉的大量不良数据。
  4. 您可能需要推出新版本或软件补丁。
  5. 您的服务台可能需要拨打一大堆电话。
  6. 您可能需要填写一堆文件,解释为什么该错误存在以及它会导致什么问题,以及您要做些什么来确保它永远不会再发生。

答案 5 :(得分:1)

因为更多的人会花时间处理有缺陷的软件。

如果你早点修复了一个错误,也许代码审核人会花一点时间。

如果它被发布给客户并报告为错误,您将对其进行编码,有人可能已对其进行了审核,有人可能已对其进行了测试,有人甚至可能已对其进行了记录等等......

答案 6 :(得分:1)

可能存在其他依赖关系(内部或外部),这将影响缺陷的修复。

例如 - 如果我解决了这个缺陷,我可能需要解决其他问题

答案 7 :(得分:1)

想象一下,你正在撰写一篇文章,说明为什么在这个过程的后期发现缺陷成本更高,你突然意识到你的大部分论文内容所依据的前提之一都是错误的。

如果您还在计划中,那么您只需要改变半页计划。如果你的文章差不多完成了,你突然需要废弃该批并重新开始。如果你已经把它交给了,那么错误会让你失去成绩。

同样的原因。

答案 8 :(得分:1)

对于收缩包装的软件产品: 如果您在产品到达商店后发现错误,则必须通过支持电话帮助用户,建议解决方法甚至召回产品/发布服务包。

对于网站: 网站中断和延误会花费您的钱。 由于网站不良/故障导致的客户流失费用更高。 调试过程本身也很昂贵。

答案 9 :(得分:1)

问题作者可能是一个错误,但实际的问题是,“为什么在流程后期发现缺陷成本更高”在这个问题中是发现错误的成本,我们也希望它也是意味着修复它。大多数答案都很好地描述了修复的成本以及为什么最好早点修复而不是稍后修复。而且,我真的不同意他们中的任何一个。但是,这不是整个问题。

我有一些关于发现成本的一些常规的深奥论点。找到特定的bug需要多少测试(没有后见之明)。在您可能找到测试用例和场景之前,是否需要花费3个人月的自动或手动测试?

在实践中,尽可能多地进行测试,但找到平衡点并不像许多人想象的那么容易。大多数程序太大,无法实现100%的代码覆盖率。并且,100%的代码覆盖率通常只是代码必须处理的所有可能方案的一小部分。

导致错误成本的另一个因素是与错误相关的业务成本。那里有500万箱藏着这个虫子吗?你需要做产品召回吗?是否会向保修服务台发出X电话?是否会触发合同中的某些条款,要求您承担损害赔偿责任。简单来说,这就是为什么在医疗领域编写的软件每LOC的成本高于网站开发的成本。

答案 10 :(得分:0)

由于开发过程以及修复缺陷所涉及的所有工作。

想象一下,您在昨天编写的函数中发现了一个问题,您只需检查,修复,签入,期间。它在你的脑海中仍然是新鲜的,你知道它是什么,你的修复不会有任何副作用。

现在想象一下从现在起六个月内找到同样的错误。你还记得为什么函数是这样编码的吗?你还会在这个项目/公司工作吗?您必须打开缺陷报告,必须发布您的软件的新版本,QA需要验证更正。如果已部署该软件,则必须升级所有实例,客户将致电支持...

现在确实显示成本的曲线是为了说明这一点;它实际上取决于开发过程。

答案 11 :(得分:0)

我会说最昂贵的是找到一个缺陷并让它成为现实。您允许缺陷存活的时间越长,成本就越高。

我曾经在一家公司,他们有政策,一旦他们做出决定,他们坚持下去。我工作的系统因为一个我们被迫使用的愚蠢的公司框架而加载了bug,并且对Web服务的正确使用存在深刻的误解。

到目前为止,我认为该公司获得一个可行的,可用的系统的最便宜方式是放弃整个系统并从头开始重写。

所以我的观点是,我不认为在后期发现缺陷是有问题的。但是,直到后期才忽略缺陷是非常有问题的。