在 Agile Testing Days 2015大会上，Eddy Bruin和 Ray Oei解释了如何在不编写大型测试计划的情况下，满足干系人对测试用例、测试计划和其它测试工件的需求。

InfoQ就测试计划在敏捷中的应用、如何让干系人意识到他们能够影响质量，以及他们推荐的敏捷测试实践问题对 Bruin和 Oei进行了采访。

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一样会发生变化。例如保持团队敏捷从而允许在回顾中改变文档。

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评审两者之间的对比就是缩短反馈环的案例。另一个案例是不要等到演示的时候才去展示产品。一个可替代的方案是每做完一些测试，就向团队或者产品负责人询问结果。

Ray Oei：我试图围绕一个故事、期望的产品或者任何看上去重要的东西发现尽可能多的问题。创建一个我们正在构建产品的模型，和思维图有助于我组织测试。提出问题。如果可能的话调查研究。我发现当我听到程序员讨论事情的时候，我经常想起一些需要测试的内容。我会遍历代码。当有人告诉我，我不需要因为一些不明原因检查代码时，那么我肯定会看一眼代码。那是一个“计划”吗？如果你认为计划是开始测试前对某个时期的设想，那么它就不是的。但是我又有测试的想法，并且我在努力尝试执行这些想法。而且说实话，事情的发展并不总是跟我预料的一样。有时在我有时间组织它们之前，我的一些想法已经过时了。我认为我的主要指导计划就一个问题：“现在或者未来，这重要吗？”。

InfoQ：有没有一些您想推荐的具体的敏捷测试实践？

Eddy Bruin：有一大堆的敏捷测试实践：结对编程、实例化需求（ATDD/BDD）、TDD、大量的启发式测试等等。对我而言总是非常优秀的一个实践是在所有测试活动中进行沟通。当规划测试、汇报测试和解决bug，甚至是当展示我们实际意图构建的产品和应该给公司带来什么产品时，我总是努力尽可能地透明化。为此我最常用的策略是拥有尽可能多的信息辐射体。墙上的活动挂图、白板和便利贴越多，开始沟通就越容易。

Ray Oei：不是具体的敏捷测试实践。我认为关键是沟通：交谈与倾听。或者更好的是：提出问题，并花时间倾听和理解。了解相关的领域和业务，和使用的技术。了解你共事的成员。同样发现你自己在那的角色和行为。我们倾向着眼于别人，认为他们应该/可以/必须完成的更好——但是你自己呢？

展示你正在做什么，已经做了什么。甚至如果需要，展示你犯错的地方。这有助于建立信任。这方面并不是航天器学，没那么复杂。虽然，作为技术人员，我认为航天器学比人文科学更加容易。

关于受访者

从2008年开始 Eddy Bruin 一直充当测试顾问的角色。他热衷于敏捷、测试、易用性和移动领域。他帮助组织实现反馈环从而交付更好的产品。作为敏捷测试教练，Eddy喜欢提供敏捷测试培训，喝着特制啤酒讨论话题。目前 Eddy是一家国际速递的测试技术总监。

Ray Oei 是一名经验丰富的敏捷教练和有扎实编程技术的测试员。他能够从不断学习新事物中获得能量，包括但不限于软件测试行业。Ray是 DEWT(Dutch Exploratory Workshop on Testing)的创办成员，软件测试协会（AST）成员，AST BBST课程的首席教官，TestNet工作组培训&教练成员。他是 AVG创新实验室的 QA团队主管。

查看英文原文：Agile Approaches in Test Planning