开发和质量检查之间的延迟时间更长的代价

在我目前的职位上，质量检查已成为瓶颈。不幸的是，当前版本中没有保留功能，因此QA可以完成测试。这意味着开发人员继续进行开发后，可能需要2-3周才能对已完成开发的功能进行测试。随着开发人员加快质量检查的进度，这个时间差距只会越来越大。

我一直翻阅我的Code Complete副本，寻找“ Hard Data”片段，该片段表明修复缺陷的时间越长，其成倍增长。有人能指出我一些支持该概念的研究吗？我试图说服质量保证瓶颈比他们想象的要昂贵得多。

您不需要任何参考，恕我直言。这是您可以（应该做）的事情：

量化延迟成本！假设需要花费1周的时间来测试这些功能。延迟2-3周意味着该功能至少要到第4周才能使用。而且这也假设100％成功。加上另一周的修复时间，这大约要延迟5周。

现在，如果可能，请访问项目/功能的预期期限。客户期望什么时候？会滑吗？如果没有，其他人会因此滑倒吗？那么，“发布”会因此延迟多少呢？

该版本的“公司成本”是多少，即客户期望从该版本中获利多少？如果他们希望从该版本中获得每年$ 5200的利润，那么每周的收入下滑将使他们损失$ 100的收入。那是客户观点。您可能会或可能不会访问此数据，但是值得考虑并说明延迟如何影响关系。

现在，对开发人员造成的损失是什么？一旦开发人员继续使用其他功能，您就可以要求他/她中断工作周期并“修复”以前的功能。什么是时间/精力损失？结果是将每小时浪费的薪水作为倍数，将其转换为公司成本。您可以用它来表示废物“进食”的“利润/收入”的数量。

您偶然发现的内容可以使用“延迟成本”方便地量化-由Don Reinerstein在“产品开发流程原理”中提倡，以及Dean Leffingwell在“敏捷软件需求”中提倡。您应该能够通过经济因素支持所有此类主张，以说服主要语言为$$的“更高权力”-您必须说出他们的语言才能说服他们:)

幸运兽！（双关语意：）

我真的不认为Code Complete在这里适合您。这不是代码问题，而是过程问题，甚至是管理问题。

如果您的过程中的一部分特别薄弱，那么该破除约束理论的时候了：

1. 确定约束。

   这意味着找到整个过程中最慢或最无效率的部分。就您而言，它正在测试。但是测试的哪一部分？是吗：

   • 准备测试环境？
   • 确定要测试什么？
   • 功能（验收）测试？
   • 回归测试？
   • 探索性测试？
   • 报告测试中的错误/缺陷？
   • 确定重现错误的步骤？
   • 从开发人员或项目经理那里得到澄清？
   • 解决在质量检查阶段发现的问题？

   这些都是非常不同的问题，需要不同的解决方案。您需要确定哪个是最昂贵/最重要的。向管理层证明这一点并不难，因为上述所有活动都需要花费时间（又称金钱），并且只有其中一些是增值时间。

2. 利用约束。

   换句话说，围绕约束过程进行优化。永远不要让测试人员闲着。这基本上等于：

   • 如果尚未将测试人员放入开发团队中，则开发人员之间存在持续的反馈循环。
   • 由于有频繁的测试部署，因此总是有新的/固定的东西要测试。
   • 使沟通更快，更频繁。例如，与电子邮件线程相比，更喜欢即时消息。
   • 确保测试人员拥有可用的最佳工具（快速机器，多台监视器，简化的错误跟踪等）

   这个阶段并不是要优化测试过程本身，而是要减少开销。不要浪费测试人员的时间。消除真正浪费的时间对管理人员来说也很容易。

3. 使其他活动服从约束。

   在这一点上，测试人员已经尽可能发挥自己的生产力，因此我们需要从其他领域开始借鉴生产力：

   • 指示开发人员和操作人员将测试人员放在第一位，无论他们在做什么。
   • 如果您没有跨职能的团队，请每天在预设的时间预定一间会议室，这样测试人员就不必浪费时间来预定一间会议室。
   • 将大部分开发人员（以及可能的操作）时间从功能工作中转移出来；例如，专注于错误修复，技术债务/重构，代码审查和单元测试。
   • 持续不断地进行测试-不要发展3周，然后将其踢给测试人员。让开发人员致力于使其代码可立即测试，例如使用脚手架或原型UI。

4. 提升约束。

   如果测试人员正在全力工作-就生产力和最小的开销而言-仍然不够快，那么您需要开始在测试上投入更多的资金。

   • 如果您依赖手动测试部署，请通过使用持续集成和配置管理脚本来使其自动化。
   • 如果测试计划需要花费很长时间来创建，请努力获得更好的验收标准（即INVEST）。最初，大多数组织对此都很不好。
   • 如果验收测试花费的时间太长，请开始使其自动化。使用Cucumber或FitNesse之类的工具，或者根据需要编写xUnit类型的测试。如果UI测试需要很长时间，则还有Selenium，W​​atij和其他浏览器自动化工具。
   • 如果回归测试花费的时间太长，也可以使其自动化。如果无法实现自动化，则应着重提高质量，即更加侧重于代码审查，单元测试，静态分析工具等。开发人员应相当有信心，在通过之前，几乎没有实际的错误。进行质量检查（产品缺陷则完全不同）。
   • 如果探索性测试是瓶颈，则可以将其中的一些推迟到发行后，或者外包给测试公司以进行高度可并行化的工作，例如在多个浏览器中测试相同的工作流程。
   • 如果测试人员无法修复很多错误，请考虑构建一个容量测试环境，以便能够开始再现间歇性错误。或者，尝试整天并行且连续地运行自动验收测试，并保留详细的日志。
   • 如果修复错误的时间太长，请开始对项目进行分区和/或认真考虑重新配置解决方案。或者，不修复其中的一些。并非每个错误都是至关重要的，您应该能够将它们与功能工作一起排定优先级。
   • 如果其他所有方法均失败，请雇用更多测试人员。

5. 返回步骤1。

我想说的是所有常识，但不幸的是，至少在大多数组织中不是这样。如果您受到管理层的很大阻力，那么价值流映射（一种精益生产的技术）是一种非常宝贵的技术，您可以使用它来显示多少时间，因此实际上每天释放发布候选者无法浪费金钱进入下一个阶段。机会成本很难理解，但这是我发现的可视化和演示方法之一。

如果这些都不起作用...那么也许您是一家功能失调的公司，那就为时已晚！

但是您不会仅仅通过在经理的桌子上放几张纸并要求他们把钱扔给这个问题来解决这个问题，因为他们会（正确地）认为向他扔钱可能并不能真正解决问题，甚至可能更糟 您需要提供解决方案，这就是这个答案的目的。如果将问题介绍为“这里是我们以成本/收益降序开始解决此问题的方法的清单”，而不是“我们需要更多的测试人员”，那么您将获得更多的成功。

尽管可能需要跟进，但第29页和第30页可能包含您要查找的数据。

我将调查第30页此句子中提到的研究：

数十家公司已经发现，仅在项目中早于而不是晚于缺陷纠正就可以将开发成本和进度表减少两个或更多的因素（McConnell 2004）。

顺便说一句，正是您的问题让我再次拿起书来刷新它：-)

您所描述的是流程中的瓶颈。精益理论指出，在一个过程中总会有瓶颈，但是它的严重性可能有很大的不同。如果质量检查人员多雇用了一名，那么开发可能会成为瓶颈。

要了解成本，请想象以下情况。您选择了一名开发人员。他的工作永远不会保证质量，但总是会无限期排队。想象一下，这意味着质量保证可以及时质量保证其余开发人员的工作，并且不会有延迟的成本。

在这种情况下，延迟的成本就是开发人员的薪水成本，因为这会浪费他的工作。

我之所以要讨论成本而不是过程所创造的价值，是因为尽管要好得多，但要记录一个过程的价值却比较困难。

我一直翻阅我的Code Complete副本，寻找“ Hard Data”片段，该片段表明修复缺陷的时间越长，其成倍增长。有人能指出我一些支持该概念的研究吗？

发现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

（这里的桌子）

敏捷软件开发方法论的目标之一是消除这些不同的阶段并降低这些成本。使用其他方法进行瀑布分析时，这些数字不适用。

您的问题与质量检查无关，实际上，如果您的质量检查正在进行“测试”，则延迟几乎是您所担心的最少。请让我解释一下（再次，这是编程行业中常见的误解）... QA通过从需求（可能更早）到开发，验证，发布和支持，监督整个SDLC，从而确保产品的质量。测试可确保代​​码中不存在明显的缺陷。有很大的重要区别。如果您有真正的QA，他们将遍历整个Test / V＆V部门，询问他们为什么要花费业务时间（以及金钱）来延迟发布，或者遍及整个项目管理，以确保他们正确地管理项目计划，或者遍及整个管理确保有足够的测试人员来生成代码等...

因此，假设您是质量检查人员，则实际上是指测试，回到原始的问题。Code Complete正确无误-缺陷的成本是从插入到纠正所需的时间。早期检测仅在您也及早纠正的情况下才有用，但是大多数人的解释是错误的。

（注意：我在这里扮演Devils的拥护者，不要直视其中的任何一个，因为我对您的情况一无所知）测试部门的延迟原因绝对是代价，但是，我必须问您是否等待他们发​​现缺陷，您在做什么-您是否不应该发现自己的缺陷？也许，如果他们的工作量较少（通过高质量的输入而带来的缺陷较少），那么延迟就不会那么重要，成本也不会那么低-作为经理，我会问您如何计划减少交付给您的代码中的缺陷测试，因为（根据您的论点）如果通过测试发现的缺陷比您自己发现的缺陷花费更多。

另外，作为您的经理，我可能会说不是Tests工作发现您的缺陷，他们的工作是发现没有缺陷-如果您期望他们发现缺陷，也许您做得还不够好。

请谨慎处理。如果您没有解决问题的方法，那么您很有可能排名第二。