Ray Oei：这取决于你对测试计划的定义。在传统形式下，我会说不需要。
　　在我看来，完成的定义包含了一部分计划。在一定程度上用户故事本身由业务所描述：为用户故事定义的验收标准，可能存在的整体约束，产品需要的工作环境，终端用户等等。我们可以找到许多方式在团队内，与PO和干系人进行沟通。例如，我自己喜欢思维图，但是 BDD也非常的有用。后，这取决于具体环境。没有明确的针对所有事情的解决方案。在这方面，与我们不同的“医学(medicines)”概念始终是正确的：你必须寻找能够在具体环境下起作用的东西。反复试验，检查并调整。这不是敏捷吗?
　　InfoQ：您能详细说明如何和敏捷一起使用测试管理方法(TMap)类型的测试计划?
　　Ray Oei：正如我在我的演讲中解释的，它更多的是一种木马病毒而不是安慰剂。在我的案例中，外部项目组织坚持需要文档。但是文档内容经过定制以支持开发团队正在探索的敏捷倡议。因此，我描述了启发式测试策略模型(来自 James Bach)，用来解释我们将生成测试用例的方法和基于会话的测试管理(来自 Joh Bach)——管理者尤其“钟爱”“管理(management)”一词，此外还用此来描述我们将组织测试的方法。当然，整个过程是的 Scrum循环图。它被大众接受。并且当我被问到什么时候测试用例可以准备妥当的时候，我可以指着商定的方案并解释说所有的事情都在按部班的前进。
　　InfoQ：您有哪些案例可以说明您是如何让干系人意识到他们能够影响质量的?
　　Eddy Bruin：在这方面关键在于参与。几年前，一个业务经理告诉我“我们需要更多的测试用例!请您把它们写进测试计划。”我回复到，请问您需要更多测试用例的原因是什么。“否则我们如何了解系统的质量?另外我需要维护软件。我想知道它的反应。”
　　很明显，业务经理和他的团队需要两件事：1)对产品质量的自信和 2)了解产品是如何运作的。从那时起，我邀请他的团队参加 Sprint评审，评审后用一个小时的时间和他们一起测试。事实证明他们都是非常的测试人员，自从我引导他们学习系统后，我再也没有收到编写测试用例的请求。除此之外，在 Sprint评审期间他们提供了更多的反馈，这些反馈着实提高了质量。在我目前的工作中，我们非常重视 Sprint评审，我们认真准备评审，这样人们可以自己操作产品，在迭代中针对固定领域提供反馈。
　　Sprint评审的几点思路：
　　创建活动挂图，参与者可以在上面留下自己的反馈。也可以是积极的反馈!(在演讲中你可以看到一个类似的活动挂图的案例。)
　　准备测试数据，并打印出来。
　　有多个可用的设备和工作站，这样人们可以检查你的产品
　　邀请人们自己操作应用(不要仅仅展示)
　　Ray Oei：与干系人交流，要有耐心不要害怕重复。不是每个干系人都希望或者觉得有参与的必要，他们仅仅想要一个可工作的产品。通常有帮助的是演示，更多的是演示之后的讨论。让干系人体验到他们的投入得到了使用和欣赏非常的重要。给他们机会分享他们的假设、期望和需求。如果可能给他们全天候的产品访问权限。让他们测试。当然这也是有风险的。如果产品过分不稳定，你可能不会获得干系人的信任;结果可能与预期相反。不幸的是，在干系人参与都成问题的情况下，通常终结果也会让他们失望。
　　InfoQ：您有案例说明如何在敏捷中计划测试吗?
　　Eddy Bruin：如果你的工作环境是 Scrum，所有测试好在开发软件的迭代过程中完成。我发现现实往往相反。向敏捷过渡的企业其很多的测试阶段并没有简单的消失。端到端测试和性能测试通常在 Sprint之后实施。我所追求的是不断地让测试负责人参与进来，并向他们展示如何可以更早地执行这些测试。归根结底都是为了尽可能快地缩短反馈环。如果我们的软件在市场上有助于实现业务目标，那么软件应该视为一个解决方案，因此我们越早有可工作的软件，越早可以测试。
　　业务经理要求在测试计划中体现更多测试用例(后期反馈)的故事与业务经理参与每两周一次的 Sprint评审两者之间的对比是缩短反馈环的案例。另一个案例是不要等到演示的时候才去展示产品。一个可替代的方案是每做完一些测试，向团队或者产品负责人询问结果。