本节用对话的形式讨论探索式测试的概念与实践。提问者是本书的一位虚拟读者，回答者是本书的作者们。
问：探索式测试中的“探索”该如何理解？
答：所谓探索是指有目的的漫游，即带着使命在某个空间中漫游，但没有预先确定的路线。探索包括对产品与技术的深入研究和基于研究成果的实践应用。
问：如何实施探索式测试？
答：本书第3部分将专门讨论该问题。这里先介绍一种可行的探索式测试实施方法，其灵感来源是基于测程的测试管理（Session-Based Test Management）。
探索式测试鼓励测试人员依据当前语境选择合适的测试流程与技术。在测试过程中，SMART原则 为测试者提供了很好的指导。
Specific（具体的）：测试需要一个具体的目标。
Measurable（可度量的）：有明确的指标可以评估目标是否达成。
Achievable（可实现的）：目标应该是可实现的。这潜在地要求将一个大目标分解为多个小目标，且每个小目标也是具体的、可度量的、可实现的。而且，追踪小目标的完成情况提供了整体进度的可度量性。
Relevant（相关的）：目标要切合当前语境，符合团队利益，且不忘企业愿景。
Time-boxed（有时间限制的）：为每个目标设定一个合理的最后期限。这可以帮助测试人员在固定的时间窗口（Time Window）中排除不相关干扰，专注地工作。
依据SMART原则，测试人员可按如下描述展开探索式测试。
（1）测试人员制订测试计划。分析被测试应用，确立若干个具体的测试使命（Mission），每个使命针对一个可能的产品风险。
（2）测试人员将测试使命分解为一系列测试任务（Charter），每个任务都有明确的退出条件和时间限制。
（3）在短暂的测试计划之后，测试人员根据优先级选择一个任务，在一个固定的时间窗口中执行探索式测试（窗口的长度是60~120分钟，以90分钟为宜）。这样一个时间窗口被称为一个测程（Session）。在该测程中，测试人员设计测试、执行测试、评估测试结果。他会根据获得的知识和发现的疑问再设计测试用例，以拓展测试的广度和深度。
（4）在测程结束后，测试人员适当休息，放松思维。
（5）随后，他会反思当前的测试进展，并优化测试计划。也许他会为当前任务追加一个测程；也许他会再增加一个新的任务以弥补先前测试计划的不足；也许他会删除一些任务以反映他对测试对象的最新认知。
（6）这时，他会更有自信地开始新一轮探索式测试。
以上只是一种可能的探索式测试实施方法。负责任的测试人员一定会选择他自己的方式展开测试，因为只有作为领域专家的他，才能做出最符合语境的决策。此外，集合整个团队的力量，进行同行评审、头脑风暴、结对测试等活动，有助于产生更好的测试结果。
问：探索式测试与即兴测试（Ad-hoc Testing）有何区别？
答：探索式测试与即兴测试都强调“即兴发挥”，即利用直觉和经验，快速地测试软件，并不停地调整测试策略。软件专家Andrew Hunt指出，直觉是非显性知识的代名词，是大脑富（Rich）模式的杰出能力。如果人类只使用大脑的线性模式（包括语言可表达的显性知识、抽象能力、逻辑能力等），而漠视富模式的能量，我们将浪费自身的巨大潜力。
然而人是不完美的，某些直觉可能是认知偏见或错误。这就引出了探索式测试与即兴测试的关键不同：探索式测试是带着“反思”的测试。在探索式测试中，测试人员不断地提出假设，用测试去检验假设，并分析测试结果来证实或推翻假设。在此过程中，测试人员持续完善头脑中的产品模型和测试模型，然后利用模型、技能、经验去驱动进一步的测试。通过将测试学习、设计、执行和结果分析作为相互支持的活动并行展开，探索式测试总是在不停地优化测试模型、测试设计和测试价值。因为测试设计和测试执行的切换速度很快，许多人误以为探索式测试没有计划和设计。实际上，这些活动被划分到细微的时间片中，被反复执行。
即兴测试往往利用错误猜测、典型风险和常见攻击来快速地试探软件，可以在短时间内发现许多软件错误。但是即兴测试不强调测试的系统性和完整性，测试遗漏的风险很高，也难以发现一些需要深入研究才能发现缺陷。探索性测试通过测试来透彻地理解被测试产品，从而拓展测试的广度与深度，以持续优化测试的价值。
问：如果探索式测试是硬币的正面，那么硬币的反面是什么？
答：探索式测试的对立面是脚本测试（Scripted Testing）。脚本测试要求预先编写好测试脚本（Script），脚本规定了如何配置被测试软件、如何输入、如何判断软件输出了正确的结果。编写详细的脚本往往需要大量的测试资源。
如果运用得当，脚本测试可能有如下收益：
测试人员可以仔细地思考被测试软件。
测试脚本可以被项目关系人（Stakeholder）评审。
测试脚本可以被复用。
测试团队可以评估测试脚本集的完备性。
测试团队可以度量测试脚本的执行情况，以评估测试进度。
问：本书为什么反对脚本测试？
答：笔者不反对任何测试思想或方法，但是反对不分语境地滥用某一种测试思想或方法。例如，苛刻地要求编写详细的测试脚本可能会导致如下测试风险。
在测试执行前，大量的测试资源被用于测试设计。但是，产品的发展往往难以预料，早期的预先设计不能有效地处理动态变化的情况。有可能花费了大量的时间，却获得了一批充满缺点的测试脚本。
过于详细的测试脚本压抑了测试执行的灵活性，使得测试执行变成单调的过程。这可能导致测试人员对一些明显的错误视而不见，因为它们不在测试脚本的检查范围之内。此外，运行测试是观察软件行为、获得测试灵感、设计新测试用例的极佳时刻，这要求测试人员在测试执行时全神贯注、头脑灵活、反应敏捷。但是，枯燥的测试执行将使这些目标难以实现。
大量的详细测试脚本导致了沉重的维护代价。在进度压力下，测试人员可能没有时间更新测试脚本，这使得测试脚本不能随需求和产品一同演化。随着时间的推移，大量的测试脚本成为过时的、无人问津的“摆设”，原先投入大量资源所获得的测试资产几乎消耗殆尽。
要求测试人员编写求全责备的测试脚本，很可能带来不良的心理暗示：测试人员在不知不觉中将编写脚本看做测试的目的，而不是辅助测试的工具。他们会盲目追求脚本的数量，而很少关注产品和项目的风险，用看似“完备”的脚本集提供虚假的安全感。更糟糕的是，醉心于脚本数量的测试领导很可能会鼓励这种以“文案工作”为核心的测试流程，使测试的价值进一步流失。
相比“硬币”的比喻，笔者更喜欢Cem Kaner的观点：“纯粹的探索式测试和纯粹的脚本测试好似区间的两个端点。在实践中，大多数测试者位于这两者之间。然而，大多数好的测试非常接近探索式测试的一端。”
此外，根据语境驱动测试的基本原则，测试人员需要经常反思：根据当前语境，测试策略是应该偏向探索式测试，还是脚本测试？如何综合它们的优势，以获得更好的测试结果？
问：探索式测试编写测试文档吗？
答：探索式测试者创建任何有助于实现其目标的文档，他会撰写并维护符合语境的测试文档。这里提出一种可能的测试计划编写方法，供读者参考。
在不同的开发组织，测试计划有不同的名称：测试计划、测试规格说明和测试设计文档等。但是，大多数测试计划会涵盖产品概述、测试范围、测试风险、测试策略、部分详细测试用例、资源分配和日程安排。
与脚本测试在测试执行前编写大量文档不同，探索式测试在整个测试过程中持续编写、修改、优化测试计划。测试计划的内容、格式、详略是由项目语境决定的。
在项目计划阶段，测试计划可以包含产品概述、测试范围、测试风险、测试策略、资源分配和进度安排。编写文档的目的是建立对产品的整体认知，根据风险提出相应的测试策略，并安排测试任务和日程。测试计划不必面面俱到，用精简的格式记录必要的内容即可。此时项目的不确定性较大，未知因素较多，很可能不适合做出详细的测试决策。
在项目计划阶段，应该邀请项目关系人对测试计划进行评审。评审的形式可以多种多样，会议评审、桌面走查、邮件评审、在线文档批注、头脑风暴皆可。评审的目的是发现“大图景”上的缺陷，并丰富测试策略。眼界开阔的项目经理、负责任的开发人员、经验丰富的测试同事能够提供很好的建议。
在测试阶段，测试人员需要根据测试进展持续更新测试计划，内容可能包括产品模型、检查列表、测试策略、覆盖大纲和风险列表等。测试计划应该是“活”的文档，能够反映测试人员对产品和项目的最新认识。对测试范围、测试风险、测试策略和进度安排的重大变化应该写入测试计划，重要的测试用例（如发现严重缺陷的测试用例）也应该及时融入测试策略。测试计划应该尽可能地精简，这有助于文档的持续更新，而冗长的文档将不利于阅读、增删和修订。
当测试人员认为测试计划相对完整之后，他还应该邀请项目关系人对测试计划进行评审。评审的目的是发现测试遗漏，补充测试策略，提高测试覆盖率。
以上方法有三个重要的特点。
测试计划的编写与改进贯穿整个测试过程。在测试执行之前，对测试计划不必求全责备。在测试执行中，测试人员根据测试反馈，动态地调整测试范围、项目风险和测试策略，生成新的测试用例，并对测试计划做必要的更新。
测试人员持续地收集对测试计划的意见，并将改进意见纳入测试实践。正式和非正式的测试计划评审可以识别潜在风险，丰富测试策略。在一些测试流程中，测试计划评审只发生在测试开始之前。但是，笔者建议在测试流程的中期再次评审测试计划，目的是进一步丰富测试策略的多样性，并发掘可能的测试遗漏。这时，测试团队对产品与风险拥有更深刻的理解，能够提出更具针对性和多样性的测试策略，也可以帮助测试人员发现测试盲点，从而提高测试覆盖率。
测试计划侧重测试规划（一组指导测试过程的想法）和测试策略（一组指导测试设计的想法）[Kaner01]，而不是脚本化（Scripted）的测试用例，即测试计划用精简的格式表达测试人员的测试想法，而不必详细记录测试用例的设置、步骤和预期结果。测试人员可以用文字、列表、表格、思维导图等任何合适的方式表达想法，目的是激发测试灵感，并促进测试思想的交流。此外，他会利用发现缺陷的测试用例来完善测试策略，而不是让过去的测试用例控制未来的测试。
关于其他形式和内容的测试文档，测试专家Michael Bolton的文章What Exploratory Testing Is Not：Undocumented Testing提出了很好的建议。
问：探索式测试的核心优势是什么？
答：探索式测试的核心优势是有助于“学习”。此处的学习是指学（获取知识）与习（应用知识）的持续过程。
对于测试人员，软件测试是一个持续学习并实践的过程。他的学习范围如下。
行业知识：为什么需要这个软件？软件如何帮助使用它的人和团体去获得成功？
用户角色：目标用户是谁？他们有什么特点，有什么期望？软件如何帮助他们去获得个人成就？
软件产品：产品是一种解决方案，它解决了行业和用户所面临的问题吗？
计算平台：只有深刻理解软件所依赖的计算平台（如操作系统、中间件和网络协议等），才能更好地进行测试。
开发技能：理解项目所使用的具体技术，知晓典型的技术缺陷，具备测试开发的能力。
测试技术：针对当前项目，选择合适的测试技术，并能够熟练地应用。
程序缺陷：研究已知的软件缺陷，提炼错误模式，制订缓解或预防方案。
开发团队：语境决定策略和实践。在一起工作的人，是所有项目语境中最重要的组成部分。
测试人员不需要在项目之初就掌握所有知识，他可以通过每天的工作去逐步理解用户、项目、技术和团队。更重要的是，他需要在每天的工作中实践所学的内容：规划测试方案、创建并执行测试用例、分析测试结果和编写测试报告。实践是练习，是“学”的自然延伸。知行合一才构成“学习”的完整内核。
学习的一个重要成果是成为更优秀的测试人员。他们可以根据项目语境，选择合适的流程、技术和工具来高效地测试，以推动软件质量的提高。