InfoQ：在瀑布或者敏捷项目中您觉得测试计划有什么问题?这些问题相似或者不同吗?
　　Eddy Bruin：我记得我对我编写的第一个主测试计划非常满意。我觉得一切都一目了然。编写这份测试计划花费了我一个月的时间，但我发现没有人详细阅读这份计划，我仍然需要为计划中的许多内容点争论。如果当时我花费一个月的时间跟大家交流，边测试边解释，那么我会更加的成功。是那个时候我意识到编写如此一个计划非常的浪费时间。
　　从那时以来，我收到过数份测试计划并阅读了它们。我的结论是大多数计划包含的信息都是不相关和过时的，对产品质量或者测试流程没有帮助。它们太不灵活且费时费力。
　　我发现敏捷中的测试计划有个不同，他们会再一次解释 Scrum的规则，然后尝试以瀑布的方式在测试中进行压缩。在我看来，它们都是的计划，但是用在了错误的敏捷过程中。
　　Ray Oei：在我的定义里，测试计划是一份冗长的文档，遵循一些标准或模板。这些测试计划的通病是花费太长的时间编写，并且在大部分情况下，几乎没人阅读。它更多的是一个过程工件而不是测试工件。许多我遇到的测试人员在尝试遵循计划时总是会遇到问题，并受到“为了测试我需要做什么?”的困扰。并且某些时候你可能发现所有计划的内容或多或少相同，并不能真正帮助需要测试的内容。因此，你试图忽略它们。
　　当所谓的敏捷项目需要测试计划时，并且它已经在我身上发生过，这种情况有个明确的迹象是它不是敏捷环境。在这些案例中我曾遇到的一个问题是有些人将工作方式强加给测试人员，首先因为测试阶段的描述，所以他们将测试人员与团队隔离;其次与团队的努力建设没有一点联系。这不利于团队精神。
　　InfoQ：在 Agile Testing Days大会上，您把您的演讲叫做“Placebo Test Management”。您能解释一下它的含义吗?
　　Ray Oei：它描述的是由于我们交付的内容与预期提供的解决方案相比，或多或少具有欺骗性(fake)所造成的影响。像在医学方面，通常很有效果。它能造成控制错觉(illusion of control)，这种错觉满足了很多人。当然，它也会引发一些反应。我们不想欺骗或者仅仅让管理者满意。通常，在我们能够以他们想要的方式交付价值之前，我们需要先建立一个共同的基础，使得看上去似乎在做预期的事情。展示有价值的结果才是关键，这样有助于说服人们相信事情能够以与他们预期不同的方式完成。然而，这在流程-饥饿(process-hungry)环境中是一个很大的挑战。
　　Eddy Bruin：一年前当 Ray和我讨论测试计划的时候，我们得出结论，我们倾向于拥有解释为什么、如何测试和测试什么的替代方案。然而，在某些情况下我们被告知需要基于公司模板交付一份测试计划或者测试报告，“因为流程强迫我们这么做”。
　　因为我们认为这是一个错误的观点，所以我和其他测试人员开始敷衍测试计划。我们寄出无意义的测试计划，仅仅交付无意义的模板，或者提交复活节彩蛋，目的是为了表明测试计划不能用来提高测试或者测试未被合理解释。然而这些行为确实能够取悦负责监护流程的管理者：项目经理或者质量流程管理者(很高兴)看到流程被遵守。
　　流程规定必须编写测试计划。如果管理者看到带有“测试计划”附件的邮件，他们会选中复选框。即使文档中没有内容，流程遵循者也高兴。很不幸在某些情况下会发生这种情况。我们意识到这些具有欺骗性的测试计划触发了安慰剂效应。我们是这么杜撰“安慰剂测试管理(placebo test management)”短语的。
　　InfoQ：您觉得在敏捷中还需要测试计划吗?它们能起到什么作用?
　　Eddy Bruin：计划对测试而言其本身是一个有用的工件。它能够塑造上下文，能够对我们自己和其他人解释我们将如何实施测试。我的问题是编写的计划所包含的信息已经可以获取并且不断变化，因此编写这么一份计划是低效率的。像在哪种测试环境下测试和覆盖哪种风险这种实用性值得拥有和沟通。同样协议中的测试范围(比如我们对哪种浏览器进行测试)很容易写下来。
　　然而，Scrum框架已经为此提供了一个有用的工件：完成的定义(DoD)。这份文档会发生变化，更重要的是它是沟通的象征(token of conversation)。“沟通的象征”的意思是 DoD仅仅是伴随故事的一种结果，一种陈述。只有在沟通中我们才能描述故事，而不仅仅是给每个人发送一份 DoD副本。也是说，我确实喜欢拥有合适的测试远景文档。它可以是一份 PPT或者思维图。测试文档跟 DoD一样会发生变化。例如保持团队敏捷从而允许在回顾中改变文档。