最好把这些想法也打消，我会换一种表达方式。他是对的，有时候是能预先定义出好的测试用例，希望测试员无论在什么情况下都这样做也没有罪。
我说：“对，有时候，那样做是最好的。但在我们现在的情况是，我不知道怎么做好。太多不确定的东西了。我么可以写测试用例，但是它们写出来是很糟糕的。充分预先定义测试是要在有可测产品或者基于稳定的、定义良好的技术文档的基础上，否则，他们就只是敷衍了事而已。我们的挑战在于一旦我们能很好地创建的时候创建指定的测试。”
Adam：“那么你怎么控制测试呢？你有测试计划吗？”
一个普遍的误解是只有计划文档才能控制过程。现在是机会介绍我的不同做法的时候了。
我说：“大部分情况下我们使用探索性测试方法，基于风险的测试方法。如果你指的测试计划是关于测试过程的一系列的想法，那么我们有测试计划，没有写下来但是作为笔记记在我的笔记本上，但是我可以跟你一起分享一下，如果你愿意的话。实际上，我们是通过频繁的报告测试状态并基于产品的风险调整测试策略来控制测试的。换句话说，作为我们测试过程的客户，我希望你能参与到控制我们的测试中来。”
“探索性测试”和“基于风险”是强调词，我希望引起他的注意，问我关于怎样测试的更多问题。但是有点冒险，有可能弄巧成拙。
Adam：“什么是探索性测试方法？”
好，他上钩了，他可能以为我在唬他。但是至少他注意到了。现在是我大加分析解释的时候了。
我说：“就像对产品玩问问题的游戏。我们一轮一轮地测试。我们同时在学习这个产品，设计测试用例，执行测试，报告问题。我们的测试覆盖随着我们对产品模型的理解的改进而改进。我们还会用一系列的测试启发列表。如果你想看的话我可以现在给你看。这是我所知道的测试一个新的、不熟悉的产品的最快的办法。你想不想让测试更快一点？让测试员了解产品是怎样的，它是怎样工作的。我们可以为测试员计划组织一个一小时左右的产品简报会，然后再有一个小时左右的问答讨论。然后我们可以头脑风暴一下，为我们想出更多的具体的测试策略，怎样？”
Adam：“那我们什么时候会知道整个测试过程需要多长时间？”
我说：“我们现在就可以坐下来，仔细看看哪些因素影响：风险、各种测试任务、开发任务。也许我们可以找到方法压缩一下测试过程，但是我们也要想想其它的选择。是否考虑我们项目最初的愿望？改bug和测试过程是否会拖延……”
这是典型的走廊解释。它可能发生在项目会议上，而不是走廊，但是原则是一样的。我们很少有机会解释我们的工作，所以要准备好一些例子（例如bug2642的悲惨故事）或一些理论知识。
实践是少不了的，但是也有一些课程可以帮助你加强你的对话技巧。
文章来源于领测软件测试网 https://www.ltesting.net/
