开发与QA之间较长时间延迟的成本

Question

在我目前的职位上，QA已经成为瓶颈。我们在当前的构建中出现了一些不幸的特性，以便QA能够完成测试。这意味着正在开发的特性在开发人员已经继续开发后2-3周内可能不会进行测试。随着开发速度更快，质量保证，这一时间差距只会越来越大。

我不断翻阅我的代码完成副本，寻找一个“硬数据”片段，显示修复缺陷的成本指数增长，它存在的时间越长。有人能告诉我一些支持这个概念的研究吗？我试图说服那些力量，说QA瓶颈比他们想象的要昂贵得多。

Answer 1

第29页和第30页可能有您正在寻找的数据，虽然可能需要后续行动。

我想看看第30页这句话中提到的研究：

数十家公司已经发现，仅仅是在项目的早期而不是后期纠正缺陷，就可以降低开发成本和进度，降低两个或两个以上的因素(McConnell，2004年)。

顺便说一句，是你的问题让我再次拿起这本书来刷新它:-)

Answer 2

您所描述的是过程中的一个瓶颈。精益理论指出，在一个过程中总会有一个瓶颈，但是它的严重程度可能会有很大的差异。如果QA额外雇用一个，那么开发可能成为瓶颈。

若要了解成本，请设想以下情况。你选了一个开发者。他的工作质量永远得不到保证，但总是无限期地排队。想象一下，这意味着QA能够以及时的方式保证其他开发人员的工作质量，并且不会有延迟的成本。

在这种情况下，延迟的成本是开发人员工资的成本，因为他的工作将被浪费。

我之所以争论成本而不是过程创造的价值，仅仅是因为很难记录一个过程的价值，尽管它要好得多。

Answer 3

我不断翻阅我的代码完成副本，寻找一个“硬数据”片段，显示修复缺陷的成本指数增长，它存在的时间越长。有人能告诉我一些支持这个概念的研究吗？

查找bug的指数成本似乎是基于NIST研究的。这项研究是一项调查，假设有不同的瀑布阶段：

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

(从这里到这里的桌子)

敏捷软件开发方法的目标之一是删除这些不同的阶段并降低这些成本。这些数字在使用其他方法处理瀑布时不适用。