Unit testing 一个不需要'；不强调自动化单元测试在Scrum中会变得更糟吗？

我在一个大约有120名开发人员的开发团队中工作，团队中有更小的部门。我们的流程介于瀑布式和敏捷式之间，更倾向于前者。我们没有让我们的构建执行单元测试，只是在不同的团队中偶尔使用它们。这里没有发生类似TDD的事情

我们一直在接受Scrum培训，并试图在一些项目中使用敏捷方法，并在未来将其他项目推向敏捷

我一直担心我们不再强调自动化单元测试已经有一段时间了。在这个Scrum/Agile培训过程中，我试图指出，在我们的构建中缺乏自动化的单元测试可能是一个问题，尤其是在敏捷过程中，尤其是在使用短迭代的情况下。“推动者”对此的回应是，这是一个XP主题，我们正在实施Scrum

---

假设您同意我的担忧，我可以向付账人提出哪些论点，即开发良好的自动化单元测试基础架构（和理解）需要更高的优先级？

我所看到的最好的论点是尽早修复bug更便宜

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

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

编写代码后，适当的测试覆盖率允许您获取代码并更改它，因为您知道它仍然可以按照定义工作。特别是与回归测试相关的工作大大减少了

我看到管理层试图通过建议测试在核心开发功能之外进行，而不是在sprint周期之外，以这种方式“抄近路”。根据我的经验，这一切都以眼泪告终，因为软件交付的时间比及早发现并修复缺陷的时间要晚

也许这是一个文化问题，但在英国，我所看到的Scrum等的最佳实践是不要太在意流程中的某个特定部分是XP、敏捷、Scrum还是其他什么。相反，检查和调整策略意味着团队可以自己决定通过采用特定策略来改进代码；然后，如果在价格飙升后，这一政策似乎奏效，那么它就会被更广泛地采用。或者不是

---

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

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

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

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

在Scrum中，测试周期将加快，因为每个用户故事在被产品所有者接受之前都应该满足一致同意的“完成”定义。在任何给定的sprint中，许多用户故事都应该由每个Scrum团队完成。如果每个故事都需要手动测试（国防部应该这么做），而且缺乏自动化，那么就浪费了很多时间

一个合理的测试策略将着眼于代码发生变化的地方，以避免处理低风险的静态区域。对于Scrum，鼓励代码重构，因为每个故事都是功能的一小部分，客户反馈会立即以新的/修改过的用户故事的形式包含在待办事项中。因此，好的Scrum程序的“代码冻结”将比瀑布式程序更接近其“发布日期”。这使得一次测试和使用它变得很困难。你最终要支付多次技术债务利息

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

另一种方法是在程序工件中寻找障碍的证据。障碍被定义为使团队减速的任何东西。你有