由于迭代周期是2-4周，敏捷团队几乎没有足够的时间来执行复杂的测试策略、计划、设计、脚本编制和执行，超出了他们在测试自动化过程中所实现的(正如我们在前一节中看到的)。为了弥补这一点，他们结合使用自动化测试和探索性测试。探索性测试是一种方法，在这种方法中，测试人员同时执行最小的测试计划和最大的测试执行，同时他们也不断地学习领域和演进的产品特征。而不是遵循一个严格的和预定义的测试计划或测试脚本，探索性测试人员利用他们默认的知识、想象力和自由来关注高风险的领域，新的和现有的特性来发现潜在的可能对产品产生不利影响的问题。
    探索性测试人员从一个敏捷测试章程开始，这个章程包含了一个简短的范围声明，这个范围将被测试一个小时左右，以及在此期间要使用的方法。尽管探索性测试可以在开发生命周期的任何时候进行，但这里的假设是，系统在测试环境中运行正常且稳定，测试将在此环境中进行。否则，团队可能会花费太多的时间来测试应用程序(使用最新版本的代码)。回到我们的图书馆管理系统示例，探索性测试人员可以通过一组引导问题来探测系统行为。这些可能不是作为功能需求或用户描述明确地声明的，而是某种隐式的、未声明的用户期望。一些示例问题是:

    • 如果借书人在预定书时不小心按了退格键，会发生什么?
    • 如果在浏览器上按下刷新按钮，显示书籍列表的搜索结果会消失吗?
    • 如果借阅者同时通过电脑和手持设备登录，会发生什么?
    • 如果与服务接口的(非关键)组件返回最畅销的书籍(由出版商广告)不工作，门户将如何表现?
    • 图书管理员如何报告丢失和损坏的图书?

    在执行这些测试时，将记录并报告结果(至少是失败)。通常，失败的场景实际上会促使探索性测试人员进一步探索，并通过调整输入数据、输入条件、场景和测试步骤来运行先前执行的测试的一些变化。这是实时发生的，进而可能导致非常迅速地发现相关问题。
    如上所述，探索性测试并不能真正取代“脚本化”测试，这是有价值的。探索性测试的真正应用是在复杂的情况下，在这种情况下需要黑盒方法，或者它针对的是一个相对未知的产品，并且预先识别和记录整个测试用例套件是相当困难的。由于事前准备很少，结果可能确实相当值得。