问不强调自动化单元测试的开发过程会因为Scrum而变得更糟吗？

EN

我所见过的最好的论据是，在早期修复bug更便宜。

特别是，正如您所说的，使用较短的迭代，未测试的代码在部署时几乎肯定会失败。让团队停下来执行手动测试，然后修复，在schedule中引入了不确定性，而理想情况下，Scrum的最佳实践是需要一个定义良好的频繁高质量发布节奏。

在一个更大的团队中集成未经测试的代码也可能很困难:即使是最好的编写规范也可能是模棱两可的，而且往往是更糟糕的。拥有一个健壮的测试套件是代码实际执行的一个很好的规范。

一旦编写了代码，良好的测试覆盖率就可以让您在知道代码仍然按照定义的工作的情况下，对代码进行更改。特别是，与回归测试相关的工作量大大减少了。

我见过管理层试图以这种方式“偷工减料”，建议测试在核心开发功能之外完成，远离sprint周期。在我的经验中，这以泪水告终，软件交付的时间比如果做出适当的努力来及早发现和修复错误的时间更晚。

也许这是一个文化问题，但在英国，我所见过的Scrum等的最佳实践是，不要太关心流程的某个特定部分是XP、敏捷、Scrum还是什么。相反，检查和适应策略表明，团队可以自己决定通过采用特定的策略来改进他们的代码；然后，如果在峰值之后它似乎有效，则该策略被更广泛地采用。或者不是。

因此，您可能会发现最好等待时机，然后在您的下一次回顾中建议提高测试覆盖率。或者，也许你可以自己实现它们。看着你的速度提高！

我不认为迁移到Scrum会让事情变得更好或更糟。核心问题不是您是否使用什么过程:如果没有自动化测试，那么无论过程如何，都不会有测试。Scrum可能会让问题变得更加明显:如果你部署在常规的cadence未经测试的代码上，bug很可能会被更早地发现，你的积压工作将会用必须修复的缺陷来填充。在这一点上，您的团队可以像往常一样继续工作，或者决定更早地消除bug，并通过在流程中包含测试来交付更高质量的功能。

Jeremy提供了一个非常可靠的答案，但让我试着把这个主题放在您从瀑布迁移到敏捷的上下文中来补充一下。我们已经成功地使用敏捷两年了，尽管并不是没有显著的成长痛苦。

在Scrum敏捷中，一个关键的成功因素是最大化未完成的工作量。任何类型的手动测试(单元、功能、负载、可伸缩性、负面)都是未充分利用的工程能力。这实际上比这糟糕得多，因为每增加一个新功能，保持一定质量水平所需的手动测试量就会非线性地增加(几何关系？)以及由于特征交互引起的测试矩阵的扩展而导致的特征的数量。这就是为什么我们公司把手工测试称为“技术债务”的原因。

在Scrum中，测试周期将会加快，因为在被产品负责人接受之前，每个用户故事都应该满足Done的一致定义。在任何给定的sprint中，每个Scrum团队都应该完成许多用户故事。如果每个故事都需要手动测试，并且缺乏自动化，那么就会浪费大量的时间。

一个合理的测试策略将在其他方面查看代码正在更改的地方，以便不处理低风险、静态的区域。使用Scrum，鼓励代码重构，因为每个故事都是非常薄的功能切片，并且客户反馈立即以新的/修改的用户故事的形式合并到待办事项中。因此，好的Scrum程序的“代码冻结”比瀑布程序的“发布日期”要近得多。这使得测试一次就完成变得很困难。你最终支付的技术债务利息要高出很多倍。

Jeremy的最后一个想法是关于如何推销你的想法或实现改变。我发现这一点非常重要，所以请允许我补充一些我自己的想法。如果你的管理层对敏捷很认真，他们会认真对待Scrum团队的反馈。在回顾期间，您可以询问您的队友，他们对修改没有单元测试覆盖率的代码有何感想。这应该会引起一些反馈。

另一种方法是在你的程序工件中寻找障碍的证据。障碍被定义为任何拖慢团队的东西。你有一个缺陷跟踪系统来识别“回归”缺陷吗？您的团队是否跟踪给定测试用例的运行频率？您的软件中是否有任何组件可能具有适当的单元测试覆盖率？如果是这样的话，从事这项工作的团队比其他团队遇到的问题更少吗？管理层关心的是美元/英镑/欧元。计算出有多少人由于缺乏自动化单元测试而浪费了多少时间，并将其转化为金钱。经理可以告诉你，你的一个工程师的全负荷成本是多少。并提醒他们，这种浪费是永久性的，直到面临技术债务。