现在他听起来似乎像是他自己要做，暗含接受了有多于一种选择的想法以及使用这种方式去将他自己的计划作为一种选择方式。这听起来是他经过选择的论点，但事实上他已经选择了自己。通过接受有很多的选择，他不得不考虑影响我们选择的因素，这些因素是我需要他做的，如果他要理解测试。

　　詹姆斯说：“好吧，让我们一起工作。首先，我希望你能够理解测试进度表我没有的控制权。当我们的质量标准很高，我们需要更仔细的测试，如果开发提交的产品是很不稳定的，我们的一些测试将会被封锁；如果开发提交的产品对于我们来讲太难以了解，或者难以控制，那么测试将会进行得非常缓慢；如果我们发现的缺陷是难懂的和间歇的，我们的调查和报告将会花费更多的时间；

　　如果产品的变更没有得到足够的控制，我们可能不得不进行广泛的重复测试；以及如果程序员需要花费很长的时间修改缺陷，那么它们将没有办法按时完成，不论测试还有什么工作没有完成。你能理解我所说的吗，亚当？如果你想要缩短计划表，那么我们不得不查看什么能够驱动进度表？”

　　亚当说：“我理解你所说的，我能够做些什么帮助你们呢？如果程序员帮助你们测试这样有帮助吗？如果我们能够运行你们的一些测试用例呢？”

　　詹姆斯说：“我们没有定义测试用例。”

　　亚当说：“真的吗？但是如果你预先设计测试用例测试不是更容易组织测试吗？如果按照哪种方式那么事情将会进行得更快吗？”

　　现在我必须说明一个信念，那是测试本身来自非测试。这触发了一套无助防御思考：你的规格书是混乱的，但是你能够期望我们写出高质量的测试用例吗？给我休息一下？除非我真的累了或者我听到了我成为税务检查的对象，我通常让这些想法离开。取而代之的是，我尝试赞成他的说法：他是对的；有时预先定义一些好的测试用例是可能的；并且希望测试一直那样做是可以的，不论环境是什么。

　　詹姆斯说：“是的，你这样想有时可以准确的选择正确的事情去做。可是，我们目前的情况是，我不知道怎样开展这样的工作，有太多的不确定。我们能够创建测试用例，但是他们可能是很糟糕的测试用例。那些能够充分的在产品生产以前定义测试用例的人，或者是基于很稳定的、定义明确的技术上有能力的人，或者是没有能力的在欺骗你的人。我们面临的挑战是要尽快地尽力定义具体的测试。”

　　亚当说：“那么你如何控制测试呢？你有没有一个测试计划呢？”

　　这是一个普遍存在的误解，是一个过程仅仅是由有文档的计划控制的。这是我引入另一种思维方式的机会。詹姆斯说：“在大多数情况下，我们使用一种探索的，基于风险的检验方法。

　　如果是基于你所说的引导测试过程的‘测试计划’，是的，我了解它了。除非它值得记录否则我不会写在我的记事本上，但是如果你想听的话我可以和你分享。

　　事实上，我希望你能够告诉我，我们的计划是否是在正确的轨道上，我们通过经常报告我们的测试状况，然后调整我们的测试策略，这些都是基于管理者对于产品风险的节点控制的。换句话说，作为我们测试过程中的一个客户，我希望你能参与到我们是如何控制测试的事情中。”

　　类似“探索的”和“基于风险的”这样的词语是强意词也是诱饵，我希望能够挑起他询问更多的关于我们如何测试的问题，但是这也是一个危险的动机，如果我的语气过分的强硬，给人放烟雾弹的印象。

　　亚当说：“什么是探索性测试方法？”

　　他受到诱惑了！他可能会怀疑我在欺骗他。但是对他是有益的，引起了他的注意。现在我想总结的解释和结束于一个强有力的建议，那是他这样做了可以得到他想要的东西。

　　詹姆斯说：“这好像在玩产品的‘二十个问题’。我们经过一系列的测试，我们同时学习产品、设计测试，执行并报告缺陷，我们的测试覆盖是基于一个产品模型，该模型和我们以前的相比是有所改进的。我们也会使用启发式的测试列表，并且我可以现在将它们展现给你如果你想了解，这是我所了解的测试一种新的不熟悉的产品的快方法。你希望再将它们加快吗？那么让我们开始让测试者快速的了解该产品是什么和如何工作吧，让我们用一个小时时间让测试人员简要了解产品，然后再花费一小时用在质量保证。然后当你在两周内将讲代码提交给我们后我们会开始集思广益的讨论，产生更多的明确的测试策略。这样如何？”