我在一个开发小组工作，可能有120名开发人员，其中有较小的部门。我们的过程介于瀑布和敏捷之间，而不是前者。我们没有我们的构建执行单元测试，并且在各个团队中只是偶然使用它们。这里没有类似TDD的东西。
我们一直在进行Scrum培训，并尝试在某些项目中使用敏捷方法，并在未来将其他项目转向敏捷。
我一直担心自己不再强调自动化单元测试。在这个Scrum / Agile培训过程中，我试图指出在我们的构建中缺乏自动化单元测试可能是一个问题，尤其是敏捷过程，特别是使用短迭代时更是如此。 “动摇者”对此的回应是，这是一个XP主题，我们正在实施Scrum。
假设您同意我的疑虑，我可以向支付账单的人员提出什么样的论据，即开发良好的自动化单元测试基础设施（和理解）需要具有更高的优先级？
答案 0 :(得分：3)
我见过的最好的论据是 早期修复错误 会更便宜。
特别是，正如您所说，通过短迭代，未经测试的代码在部署时几乎肯定会失败。让团队停止执行手动测试，然后修复， 将不确定性引入计划 ，理想情况下，Scrum的最佳实践是频繁高质量发布的定义明确的节奏是需要的。
将未经测试的代码集成到更大的团队中也很困难：即使是最好的书面规范也可能不明确，而且往往更糟糕。拥有一个强大的强大测试套件 是代码实际执行的一个很好的规范 。
编写完代码后，体面的测试覆盖率可让您获取代码并 更改代码，因为它仍然可以按照定义 运行。特别是与回归测试相关的努力大大减少。
我看到管理层试图以这种方式“偷工减料”，建议测试是在核心开发功能之外完成的，并且远离sprint周期。根据我的经验，最终会流泪，软件交付的时间晚于如果尽早找到并修复错误。
也许这是一个文化问题，但在英国，我见过Scrum等的最佳做法是不要太关心这个过程的某个特定部分是XP，敏捷，Scrum还是什么让你。相反，检查和调整的策略表明团队可以自己决定通过采用特定策略来改进他们的代码;然后，如果在高峰期之后它似乎有效，那么该政策就会得到更广泛的采用。或不。
因此，您可能会发现最好等待时间，然后建议在下次回顾时提高测试覆盖率。或者，也许只是自己实施它们......并观察你的速度提升！
答案 1 :(得分：2)
我认为转向Scrum不会让事情变得更好或更糟。核心问题不在于您使用的是什么过程：如果没有自动化测试，则无论过程如何都没有测试。 Scrum可能有助于使问题更加明显：如果您使用常规的节奏未经测试的代码进行部署，则可能会更早发现错误，并且您的待办事项将填写必须修复的缺陷。此时，您的团队可以像往常一样继续营业，或者决定通过在流程中加入测试来提前破坏错误并提供更高质量的功能更好。
答案 2 :(得分：1)
Jeremy提供了一个非常可靠的答案，但让我尝试通过将主题放在从瀑布到敏捷的迁移环境中来扩充它。我们已成功使用敏捷两年了，但并非没有明显的成长痛苦。
Scrum敏捷的一个关键成功因素是最大化未完成的工作量。任何类型的手动测试（单元，功能，负载，可扩展性，负面）都是未充分利用的工程能力。它实际上比这更糟糕，因为每增加一个新功能，维持一定质量水平所需的手动测试量会因特征交互引起的测试矩阵扩展导致的特征数量呈非线性（几何？）。 。这就是为什么我公司将手动测试称为“技术债务”。
在Scrum中，测试周期将加速，因为每个用户故事应该在被产品负责人接受之前满足商定的“完成定义”。在任何给定的sprint中，每个Scrum团队都应该完成许多用户故事。如果每个故事都需要手动测试，那么它应该按照国防部的要求进行测试，并且缺乏自动化，浪费了很多时间。
合理的测试策略将考虑代码正在发生变化的其他方面，以便不处理低风险的静态区域。使用Scrum，鼓励代码重构，因为每个故事都是一小部分功能，客户反馈会立即以新的/修改过的用户故事的形式整合到积压中。因此，优秀的Scrum程序将使其“代码冻结”比瀑布程序更接近其“发布日期”。这使得难以进行一次测试并完成测试。你最终多次支付技术债务利息。
Jeremy最后的想法是关于如何出售你的想法或影响改变。我发现这非常重要，所以请允许我添加一些我自己的想法。如果您的管理层认真对待敏捷，他们会认真对待Scrum团队的反馈。在回顾期间，您可以询问您的队友他们对修改没有单元测试覆盖率的代码的感受。这应该引起一些反馈。
另一种方法是在程序工件中寻找障碍物的证据。障碍被定义为减慢球队速度的任何事情。您是否有识别“回归”缺陷的错误跟踪系统？您的团队是否跟踪给定测试用例的运行频率？您的软件中是否有任何可能具有良好单元测试覆盖率的组件？如果是这样，那么研究它的团队会遇到比其他团队更少的问题吗？管理层关注美元/英镑/欧元。计算出由于缺乏自动化单元测试并转换成资金而浪费了多少人的时间。经理可以告诉您一名工程师的满载费用是多少。并提醒他们，这种浪费是永久性的，直到面临技术债务为止。