探索性测试不是终结性测试
探索性测试能够（而且的确可以）发生在开发或测试的任何阶段。
事实上，TDD（测试驱动开发）是探索性开发的一种形式。TDD是循环进行的，在这个过程中，程序员建立了一个检查，继而开发代码，以使这个检查（以及之前的所有检查）通过，然后修复她发现的一些问题，接着会再次循环去实现一些新的特性，并开展新的检查。从每个循环中获得的信息反馈到下个循环；该活动由当时参与的而不是提前设计的人来指导和构建的。检查本身是定制的，而产生和分析结果所需的活动却不是定制的。和代码开发过程中所进行的探索性的、迭代的、复杂的认知活动相比，这些定制的、线性的检查本身不那么重要了。
需求评审也是一项探索性的活动。审查的要求（或规格，或用户或实例），无论它是一个长的或短的周期，往往发生在开发周期的早期。虽然检查列表可能会指导评审的开展，但是做决定的却是那些参与活动并经历了设计，调查，发现问题及学习，这个整个回环过程的人。每个循环的结果往往会紧接着反馈到下一个活动。
代码审查也可以通过照本定制的方式或探索的方式进行。当人们分析代码的时候，是循环发生、非照本宣科的、自我导向的活动；它是探索性的。我们称之为审查，但它收集信息的目的是告知一个决定；因此这是测试。有一种围绕着定制程序应用的代码审查方法，它通过一个人们一般称之为“静态测试工具”的工具。当一台机器解析代码并产生一个报告，根据定义，它是一种形式的检查，而且它是定制的。然而，高效的使用这些工具需要大量的探索活动。分析和解释报告，以及对它做出反应是多形态的，因此，人的这种非照本宣科的、开放式结尾的、迭代的活动是探索性的。
如果你想这样做或促进这个新产品或功能的发展，了解一个新产品或新功能亦是一项探索性的活动。有些人认为，测试脚本提供了一种训练测试人员的有效的手段。对学习的研究表明，当他们的学习是基于互动和反馈的时候他们往往会学得更快更深入；这可能是因为他们是被引导着去学习而不是受控制去学习。如果你真的想了解一个产品，那尝试创建一个思维导图，去证明这个程序行为的某一方面，或者创建出人们在使用或误用这个产品时可能会产生的情况。所有这些活动都促进了你对该产品的了解，所以他们都是探索性活动。在这个过程中，有大量你可以使用、应用及发现的信息，它远远超过了一个脚本所能告诉你的。试想想，那这种活动的的脚本又从何而来呢？
开发测试程序---甚至是开发一个测试脚本，无论是为一台机器还是为一个人的，或开发熟练的测试员称之为示范的那种“测试”，这是一个探索性的活动。没有任何一个脚本会详述如何编写一个为某一目的而开发的新脚本。你是不是听说了一项新功能并思考着你可能会如何测试它？实际上从这时候你已经开始测试了；你正在做测试设计，同时你也很可能在学习。在一定程度上，你使用该产品或与它进行交互，把你的观点反馈给其他人，或批判性的思考你的设计，这个时候你在测试，而且你是用一种随机方式的方式去进行。有些人可能会认为，某些工具创建的脚本可以执行自动检查。然而，这些检查的适当性审查，解释结果，并进行故障排除意外的结果所有这些都是探索性活动。
假设一个程序员，在她快要完成一个新模块时候，想要获得关于她做的这个新模块到目前为止的一些反馈。她递给你一些代码来看。你可以直接通过她提供的测试工具与代码交互，或通过比如Ruby这样的解释器，或者你也可以写一些脚本代码来运行她这个模块中的一些功能。无论是通过这些方式的任何一个，你都会发现它的一些问题。为了调查你所发现的问题，你必须探究。您必须探究你所识别的问题由你自己与这个程序的互动引出的，还是由机械执行的脚本所引出的。你控制着整个活动；围绕着这一问题的每一个新的测试会反馈到你所选择的下一个活动，以及反馈到你要讲的关于这个产品的具体详情。
我上面描述的所有较大的活动都是探索性的，他们发生在你得到一个完整的有关产品的详情或功能之前，或一个程序完成之前。探索性测试不是在你执行完其他测试技术之后你又要展开的一个测试的一个阶段。探索性测试不是另一个“其他”测试技术，因为它根本不是一个技术。探索性测试不是你做的一件事情，而是你工作（思考和行为）一种方法，它的特点是人（或事物）可控制的，而且在一定程度上你的活动是一个循环的一部分，而不是直线进行的。任何测试技术都可以用固定的方法或探索性方法去执行。对于那些宣扬通过可接受性测试之后再做探索性测试的人来说，我给他们的建议是：要仔细审视，并时刻注意你是否做到了探索性测试。
