有时候，在Scrum中对用户故事进行测试的时候需要在最后进行一些瀑布式的步骤。在这里我所阐述的情景是基于这样一种情况：在Scrum流程中，需要在Scrum流程的最后阶段进行一些顺序性的步骤来对所开发的功能进行测试。这些步骤在我们的组织中是必须的，而且这些步骤是为了产品发布的瀑布式流程，因此，我们不得不处理在Scrum中进行瀑布式流程的情况。然而，据我所知，遇到这种情况并不只有我们。我们把这种情景叫做“Scrum和瀑布式的交互”（详见Michele Sliger的《Bridging the gap： Agile projects in the Waterfall enterprise》）。我认为这种情形应该是很常见的，因为在一个组织中Scrum的实施一般是循序渐进的，也就是说会存在Scrum和瀑布式同时存在的时期。

　　下面的图是对这种情形的一种表述：

　　首先我会在本文中讨论我们是如何在我们的流程中进行测试的，然后会分析有时会在测试的选择上遇到的反对意见。我希望可以帮助那些遇到同样问题的人，然后我们可以进一步对如何在这种情况下的最好的测试方式进行讨论。

　　情景

　　我们所开发的新功能是又很多用户故事组成的。在每个用户故事开始的时候，团队里的所有成员都会聚到一起讨论我们所谓的“测试策略”。这些测试策略可以被认为是用户故事的测试验收标准。总的来说，每个测试策略都被转换为手工测试，要完成一个测试场景需要经过不同的测试步骤。我们会为每一个用户故事编写手工测试用例。

　　相对于完全的Scrum化的流程而言，这种在交付之前进行瀑布式的流程，让我们不得不在把产品交付使用之前对所有的功能进行一次完整的测试。

　　反对

　　下面是几个对这种情景的反对意见，它们之间是互有联系的：

　　只为每个用户故事编写和运行测试是不够的，因为我们要对整个功能重新运行所有测试。最好是在Scrum流程的最后进行整个功能的测试。

　　我们花费了大量时间来为每个用户故事创建测试用例，然而，我们却可以为一组用户故事创建一组测试用例。

　　我们在相同的测试上花费了太多的时间：我们先在Scrum流程中对每个用户故事进行测试，然后又在瀑布式流程中对整个功能进行一次整体测试，最后又在瀑布式流程的QA阶段对这些功能再测试一次。