为什么探索性测试不适合敏捷项目？

编译整理｜TesterHome社区

作者｜Vitaly Prus

探索性测试可以看作是步行而不是乘坐公共汽车，可以自由地偏离特定路线。由于敏捷环境具有有效的原则，可以快速响应变化并具有处理不确定性的能力，因此探索性测试似乎非常适合此类项目。然而，这只是部分正确。

实际上，各种原因阻碍了它在敏捷项目中的使用，团队在设计 QA 策略之前应该考虑到这些原因。在本文中，作者将重点介绍这些因素，并分享对最适合应用探索性测试的案例的见解。

探索性测试的来龙去脉

在传统测试中，QA 团队采用结构化的分步方法。这意味着他们必须提前汇编用户旅程（User Journey），为测试用例奠定基础，定期使用适当的指标跟踪覆盖率，并能够轻松重现捕获的缺陷。脚本的偏差不受欢迎，软件质量的反馈并不那么快，需求的变更会进一步减慢流程。

而探索性测试是一种基于测试人员的知识、经验和直觉，在测试过程中同时进行学习、设计测试用例、执行测试并对测试结果进行分析评估的测试方式。与传统的脚本化测试（按照预先编写好的详细测试用例进行测试）不同，探索性测试更注重在测试执行过程中即时发现问题、深入探索软件系统的行为和特性。

可以说，探索性测试是一种即时发现应用程序以识别和记录软件问题的活动。产品学习、测试设计和执行同时进行，强调测试的非结构化性质。它提供快速反馈，因为它有助于快速检测缺陷，并且在需求发生变化或 QA 团队时间紧迫时效果很好。需要注意的是，探索性测试不能确保完整的测试覆盖范围。

探索性测试有以下特点：

• 灵活性：测试人员不需要严格遵循预先设定好的测试脚本，可以根据软件实际运行情况、自己的观察和思考随时调整测试策略、改变测试路径，更灵活地发现软件可能存在的各种问题。 

• 强调人的因素：高度依赖测试人员的专业知识、业务理解、以往经验以及对软件系统的直观感受。一个经验丰富、思维敏锐的测试人员能够在探索性测试中更好地挖掘出深层次的软件缺陷。 

• 快速反馈：能够在较短时间内对软件的整体质量状况给出初步反馈。因为测试人员可以迅速针对软件的新功能、新特性或者可疑区域展开测试，不必等待详细测试用例的编写和审核等流程。 

• 学习与测试同步：在测试过程中，测试人员不断学习软件的功能、架构、业务逻辑等方面的知识，同时利用这些新学到的知识进一步优化测试过程，发现更多潜在问题。

比较适用的场景：

• 项目时间紧迫：当没有足够的时间来编写详细的脚本化测试用例时，探索性测试可以快速开展，在短时间内对软件进行较为全面的检查，发现一些关键问题。

• 需求不明确：如果软件项目的需求文档不够完善、清晰，或者在开发过程中需求不断变化，探索性测试能够让测试人员依据自己对业务的理解和软件实际呈现的功能进行测试，而不拘泥于固定的需求描述。

• 发现深层次缺陷：对于一些复杂的软件系统，尤其是那些具有复杂业务逻辑、多个子系统交互的软件，探索通过测试人员灵活的探索和深入挖掘，更容易发现一些隐藏较深、不易通过常规测试用例发现的缺陷。

它的优势在于：

• 高效发现缺陷：能够快速适应软件的实际情况，通过灵活多变的测试方式发现多种类型的缺陷，包括一些在脚本化测试中容易被遗漏的问题。

• 更好地理解软件：测试人员在探索过程中不断深入了解软件的功能、业务逻辑等，这对于后续的测试工作以及与开发团队的沟通都非常有帮助。

• 适应变化：可以很好地适应软件项目中需求、环境等方面的变化，随时调整测试策略以应对新情况。

局限性：

• 对测试人员要求高：需要测试人员具备丰富的知识、经验和较强的分析判断能力，否则可能无法充分发挥探索性测试的优势，甚至可能错过一些重要问题。

• 测试结果难以重现：由于测试过程的灵活性和随机性，有时候发现的问题可能难以精确重现，给开发人员定位和解决问题带来一定困难。

• 缺乏系统性：相对脚本化测试，探索性测试在整体规划上可能显得不够系统，可能存在某些功能区域测试不够全面等情况。

敏捷中最佳探索性测试用例

敏捷软件开发需要协作、高灵活性、快速响应变化和短冲刺（最多2周）。QA 团队可以在6种情况下应用探索性测试：

1. 了解被测系统。假设 QA 团队在完成几个冲刺后加入了该项目。探索性测试有助于快速获得足够的产品操作知识，获得第一个记录的结果，并为进一步基于脚本的验证建立测试模型奠定基础。

2. 临近高压期限。用探索性检查补充验收测试是一种双赢的方法，因为它可以增加测试覆盖率并快速评估系统质量。

3. 缺乏新视角。有时需要在不遵循已开发的文档的情况下验证软件的健全性，并跳出思维定式来发现新颖的、不太明显的用例。例如，如果你有空闲时间，可以要求项目新手进行探索性测试评估。在使用非常规思维的同时，他们可能会就软件细节提出其他问题并检测未发现的问题，从而提高测试覆盖率。

4. 预算有限。即使在资金紧张的情况下，组织也可以通过聘请探索性测试专家来关注软件质量，该专家将从最终用户的角度调查应用程序，而不是花时间创建测试文档、报告和其他活动。

5. 一个复杂的系统，具有多个逻辑分支和无穷无尽的数据集。在为此类解决方案构建测试模型时，需要不同的测试设计技术，而探索性测试可以更快更好地应对这一任务。

6. 最低要求。通常，为了快速增加功能，在详细处理需求上花费的时间会更少，这会导致用户故事过于复杂甚至模糊。在这种情况下，分析新旧软件功能之间的交互就落在了 QA 团队的肩上。经验丰富的团队成员执行的探索性测试有助于快速深入研究这些细节，为开发人员提供快速反馈，并编写有意义的测试用例，以供经验不足的 QA 专家进一步使用。

探索性测试非常适合这些场景，它为 QA 团队提供了一种确保质量的多功能方法。

敏捷中探索性测试的另一面

尽管它具有优势，但在某些情况下，敏捷软件开发中的探索性测试可能不是最佳选择。请考虑以下关键点：

原因1. 缺乏经验的 QA 团队

成功的探索性测试需要富有创造力且经验丰富的 QA 工程师，他们熟悉类似的软件解决方案、业务逻辑和技术。这些知识有助于他们识别容易出现缺陷的区域，并根据所取得的进展有效地决定要测试哪些功能。

原因2.缺乏探索性测试专业知识

QA 工程师应具备扎实的探索性测试背景、其技术和最佳实践，并了解何时应用自由式和基于会话的方法来最大程度地提高 QA 效率。缺乏知识可能会导致测试结果不佳。

原因3.系统关键性

当我们谈论复杂的 IT 产品（例如银行解决方案或 ERP 软件）时，首要任务是深入研究其复杂的业务逻辑和要求的各个方面。了解软件架构对于检测问题并确保关键任务功能的持续、完美运行也至关重要。

因此，仅靠探索性测试不足以测试复杂软件的细微差别。相反，应该利用多种测试设计技术来确保最大程度的测试覆盖率。

原因4.引入测试自动化的基础不牢固

如果需要通过引入测试自动化来加快测试时间并扩大测试覆盖范围，任何类型的探索性测试都不适合。要设置自动化工作流程并获得高投资回报率，需要编写具有结构化测试步骤、先决条件以及预期和实际结果的测试用例。

原因5.从错误中学习的能力有限

想象一下：团队已经进行了探索性测试，产品也已上线，突然生产环境中出现严重缺陷，对软件的稳定运行产生了负面影响，更糟的是，影响了利润。

解决问题后，需要做的第一件事就是在回顾中分析根本原因。通过分析，可以调整测试策略，避免此类事件再次发生。然而，如果坚持传统的自由式探索性测试方法，测试运行结果可能无法完全记录，从而使从错误中吸取教训的过程变得复杂，并导致业务风险增加。

如果你仍然选择探索性测试，请确保使用基于会话的方法。这包括编写包含测试目标的测试章程来指导流程，以及编写测试会话表来记录步骤和发现，从而使 QA 更加结构化。

原因6. 重叠测试

在自由式探索性测试中，缺乏正式的测试文档可能会导致 QA 团队多次检查相同场景时出现重复工作。这会对产品上市时间和整体项目效率产生不利影响。部分功能甚至可能未经测试。因此，如果你仍然认为探索性测试是一种适合用途的解决方案，请选择其基于会话的变体。它需要提前确定每个团队成员的测试范围，以避免重复工作。

原因 7. 基于合规性的测试

如果需要确保软件符合 WCAG 2.2 或 OWASP 等国际标准，QA 团队必须严格遵循一套检查表。FDA、HIPAA 和其他医疗保健法规需要更加关注，因为每个步骤都应记录在案，以确保 IT 产品提供敏感 ePHI 的安全存储和共享，并且不会对患者的生命构成威胁。探索性测试与这些活动不一致。

总结

一般来说，QA 和测试活动的主要目标是确保软件运行良好、高性能，帮助企业实现既定目标，并让最终用户获得直观、用户友好的 IT 产品。

反过来，探索性测试有助于从用户的角度审查产品的质量，跳出固有的思维模式，找到意想不到的方法来发现隐藏的问题。毫无疑问，它是测试策略的有效补充，但不是首要的必需品——尤其是对于敏捷项目而言。因此，请明智地规划并选择最适合业务的方法。

你是怎么认为的，欢迎聊聊！

（原文链接：https://www.stickyminds.com/article/exploratory-testing-why-it-not-ideal-agile-projects）