我在一个大约有120名开发人员的开发小组工作，其中有更小的部门。我们的流程介于瀑布式和敏捷式之间，更倾向于前者。我们的构建没有执行单元测试，只是在不同的团队中偶尔使用它们。这里没有发生类似TDD的事情。
我们一直在接受Scrum培训，并尝试在一些项目中使用敏捷方法，并在未来将其他项目推向敏捷。
很长一段时间以来，我一直在关注我们对自动化单元测试的不重视。在这个Scrum/Agile培训过程中，我试图指出，在我们的构建中缺乏自动化单元测试可能是一个问题，对于敏捷过程来说更是如此，特别是使用短迭代。"推动者和震动者"对此的回应是，这是一个XP主题，我们正在实施Scrum。
假设您同意我的观点，我可以向那些为开发一个好的自动化单元测试基础设施(和理解)买单的人提出什么论点呢?
我见过的最好的论点是早期修复bug更便宜
特别是，正如您所说的，对于短迭代，未经测试的代码在部署时几乎肯定会失败。让团队停止执行手动测试，然后进行修复，将不确定性引入进度，而理想的Scrum最佳实践是需要频繁的高质量发布的良好定义的节奏。
在一个更大的团队中集成未经测试的代码也很困难:即使写得最好的规范也可能含糊不清，而且往往更糟。拥有一个良好的健壮的测试套件对于代码的实际功能是一个很好的规范。
一旦代码写好了，适当的测试覆盖率可以让您获取代码并更改它，并且知道它仍然像定义的那样工作。特别是与回归测试相关的工作大大减少了。我看到管理层试图以这种方式"走捷径"，建议测试在核心开发功能之外完成，远离sprint周期。在我的经验中，如果做出适当的努力，及早发现并修复错误，那么软件交付的时间就会晚。
也许这是一个文化问题，但在英国，我所见过的关于Scrum等的最佳实践是不要太在意过程的某个特定部分是XP、敏捷、Scrum还是其他什么。相反，检查和适应的策略表明，团队可以自己决定通过采用特定的策略来改进代码;然后，如果在经历了一个高峰后，该政策似乎起了作用，就会被更广泛地采用。与否。
因此，您可能会发现最好等待时机，然后建议在下次回顾中改进测试覆盖率。或者，也许只是自己实现它们……看着你的速度提高!
我不认为转向Scrum会使事情变得更好或更糟。核心问题不在于您是否使用了什么过程:如果没有自动化测试，就没有测试，不管使用什么过程。然而，Scrum可能会让问题变得更加明显:如果你以常规的节奏部署未经测试的代码，那么bug可能会更早被发现，而你的积压工作将被必须修复的缺陷填满。这时，您的团队可以像往常一样继续工作，或者决定更早地消除bug，并通过在过程中包含测试来发布更高质量的功能。
Jeremy给出了一个非常可靠的答案，但是让我试着把这个话题放在您从瀑布开发向敏捷开发迁移的背景中来补充一下。到目前为止，我们已经成功地使用敏捷两年了，尽管并非没有明显的成长烦恼。
Scrum敏捷的一个关键成功因素是最大化未完成的工作量。任何类型的手工测试(单元测试、功能测试、负载测试、可伸缩性测试、负面测试)都是未充分利用的工程能力。实际上情况要糟糕得多，因为随着每一个新特性的增加，维持一定质量水平所需的手动测试量随着特性数量的增加呈非线性(几何几何?)增长，这是由于特性交互导致的测试矩阵的扩展。这就是为什么在我的公司我们把手工测试称为"技术债务"。
在Scrum中，测试周期将会加快，因为每个用户故事在被产品负责人接受之前都应该符合商定的"完成定义"。在任何给定的sprint中，每个Scrum团队都应该完成许多用户故事。如果每个故事都需要手动测试，这应该符合DoD并且缺乏自动化，那么就会浪费很多时间。
一个合理的测试策略将着眼于，在其他事情中，代码在哪里发生了变化，从而不去处理低风险的静态区域。Scrum鼓励代码重构，因为每个故事都是一个非常薄的功能片段，客户反馈会立即以新的/修改的用户故事的形式合并到待办事项列表中。因此，优秀的Scrum程序的"代码冻结"将比瀑布程序更接近"发布日期"。这使得测试一次就完成它变得很困难。你最终要支付很多倍的技术债务利息。
杰瑞米的最后一个想法是关于你如何推销你的想法或影响改变。我发现这一点非常重要，所以请允许我补充一些我自己的想法。如果你的管理层认真对待敏捷，他们就会认真对待Scrum团队的反馈。在回顾期间，您可以询问您的团队成员，他们对修改没有单元测试覆盖的代码有何感想。这应该会引起一些反馈。
另一种方法是在您的程序工件中寻找障碍的证据。障碍被定义为任何阻碍团队发展的因素。你是否有一个可以识别"回归"缺陷的bug跟踪系统?您的团队是否跟踪给定测试用例的运行频率?您的软件中是否有任何组件可能具有良好的单元测试覆盖率?如果是这样的话，从事它的团队是否比其他团队遇到更少的问题?管理层关心的是美元/英镑/欧元。计算出由于缺乏自动化单元测试，有多少人浪费了多少时间，并将其转换为金钱。经理可以告诉你，你的一个工程师的满载成本是多少。并提醒他们，这种浪费是永久的，直到面对技术债务。