解释测试之走廊对话的法则

henry2000888

什么是走廊对话

解释测试是一个很大的问题。在这里，让我们集中精力在这个挑战的一个部分：走廊对话。我是根据解释的时机命名的，时机发生在一个软件项目的自然过程中，例如，在一个工作日的走廊碰面。

我朝着我的座位走，亚当，开发经理，将朝着相反的方向走。他认出了我。

亚当说：“噢，詹姆斯，我们希望把时间缩短三个星期，我知道你的进度表要求在原代码冻结后整整八周的时间进行测试。你能在五周完成吗?我们可能没有时间去按照我们希望的那样去测试了。”

我的第一反应是他不能够认真的对待质量，他是一个混蛋，然后我应该回击他的无知。我离开了，我不需要如此……。这些第一反应不会对我们有所帮助，我让他们走了。几毫秒后，一个好的想法出现了：恐怕亚当认为测试进度表是由完全由我控制的因素决定的，如果这样，恐怕我能够直接的答复他。

詹姆斯说：“我的进度表并不在我的控制之中，亚当。八周时间只是根据产品的复杂度和我们能够想到的我们以前遇到的困难所形成的表格，这可能会需要多于八周的时间去测试和修复，或者至少，更多的取决于当我们拿到产品的时候它的技术状态。”

注意我是如何试图提供一份进度表的影响因素的菜单，那么我们可以有效地尽量合理的缩短测试周期。我希望他可以询问这些因素，在这种情况下，我就可以找出书写板然后给他列一个很长的列表，这些因素并不需要是绝对正确的，仅仅足够正确就好了，这样我们可能就会讨论我们所面对的整个情形，而不是仅仅倾向于给这位经理一个结果。

亚当说：“你不能预见进度表吗?”

再次证明我的第一反应好像是没有用处的：也许我是一个骗子，也许我应该能够预见进度表，也许每个人都可以做到这一点，但是除了我。只要我在中学的时候那天没有生病，我就应该知道进度表?这些不安全感对于我们这些努力做好本职工作的人是非常正常的，我也让这些想法远离我的大脑。

在这种情况下有效的回答应该是什么?在我看来亚当似乎期待两种回答(也许只需要一种回答)，在这种比较复杂或者隐蔽的情况下。正如我的最初的回答一样，我会试图用一种方式将问题的层面扩大以便他和我可以更有效的交流，我将会使用一个强有力的工具：一个举例。

詹姆斯说：“我不知道如何准确的预计进度表。这项工作可以迅速也可以缓慢，这取决于阿拉斯加州的项目，2642 个缺陷?还记得哪个吗?在我们找到可以完全重复使用的案例以前花费了两个星期，结果是该产品和一个受欢迎的防病毒扫描器相结合了。你知道你乐意在我们接手以前做那种结合，但是我们无法预先预见这个事情。”

亚当说：“我了解这个很难估计，但是把工作压缩为五周是可能的吧?”

现在我对于为什么亚当可以将视线转移到这个期限表示惊奇，他好像没有听我的。如果回答了这个问题并做出解释，他将会比较恼火。走廊对话的关键是知道何时讲演以及何时停止。在这种情况下，是时候听从和领会了。

詹姆斯说：“我了解缩短进度表对于你的重要性，帮助我了解五周的重要性。那里有什么协议?”

亚当说：“嗯，在早期计划中，一些高级经理人综合考虑了他们的时间。我们所考虑的所有的时间一直认为是‘发布到生产’的日期是6 月30 日，现在的结果是那个日期是税收时间，发布给生产厂商至少需要提前三周的时间以便产品能够完成。”

詹姆斯说：“如果产品在那个时间没有为生产厂商准备好那将如何?”

亚当说：“必须准备好。”

詹姆斯说：“如果没有完成将会怎样?”

我提出这些问题的目的是清晰的判断形势，从而我们能够将现实和期望区别开来。然后我可以指出在这种情况下并不是只有一种选择，而是很多。我做这些并不仅仅是为了有帮助，发现和辨认清楚可能性同样也是测试技术的基本原理，而且每一次的交谈是验证测试者想法的机会。

亚当说：“副总裁不会允许这样的”。

詹姆斯说：“嗯，有可能。但是作为一个测试人员，我的工作是提供信息，帮助组织者做出更好的决定。我觉得在这里不只一种选择。把它归结为一点，副总裁可能觉得一个推迟的产品比一个劣质的产品要好很多，或者他宁愿我们削减一些功能。”

亚当说：“为什么我们不能修改我们的策略而得到我们想要的呢?你说过你的测试可能需要不到八周的时间。我在为加紧整个进程寻找途径，和我们一起工作吧。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

詹姆斯说：“这就好像在玩产品的‘二十个问题’。我们经过一系列的测试，

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

亚当说：“什么时候我们才能知道整个测试过程需要多长时间?”

詹姆斯说：“告诉你吧，亚当。让我们现在就坐下来，然后仔细的检查所有的因素：风险、各种测试任务、开发任务?这是全部吧。我们可能会找到简化测试过程的方法，但是我们应该也要开发一些其他可供选择的案例，尽管我们不希望测试和修复过程拖延。”

在这种情况下，他说什么其实都无关紧要。这是我最后和最好的提议，我想让他得到他想要的，而且它的代价通过分析变得艰难前行，如果他拒绝了我的建议，我所解释的所有事情仍然都是真实的。最后，如果组织决定将测试压缩为“整整”五周时间，我将会做我能做的事并且真实的报告我的处境。我们或者是到那时之前都是完整无损，或者是在我们对于产品了解不多的时候将它推出。

这是一个典型的走廊会话，在自然环境中的解释说明。它可能发生在一个项目会议中而不是走廊，但是原理是一样的。注意这与你是否同意我的规则或者使用我的任何关于测试的想法是没有关系的，加入你自己的想法。在这里我所阐述的是在这样的解释说明中如何交换意见和形成它的力量因素是什么。关键点是，我们很少会用超过几句话解释我们的工作，这就是为什么有一些例子说明(比如

缺陷的不好的例子)或者一个比喻(如“二十个问题”的游戏)是非常重要的。这就是为什么这有助于实践得出影响的因素，这些因素将会使得你的测试失常。

没有什么能够替代实践，但是这些知识可以帮助你建立自己的对话技巧。两个帮助我成为一个更为有效的解释者的是Gerald Weinberg 的“解决问题探讨会”和“转变”，这些涵盖了整个做技术的小组。

一个好的走廊对话有九个法则：

1、从实践中发言。保持真实，拥有自己的方式。如果你没有完全明白其他人的言谈避免使用它，因为持怀疑态度的听众将会反复询问你，使它成为正在进行的项目以改善你对于测试技术的理解，通过将它们用于实践观察你是如何改变自己得想法的，并且使得你的想法影响其他人的实践。

2、和他们联系起来。比你的听众在某方面先进，将自己的身份放低。一个执行副总裁关心什么?一个技术支撑管理人员的一天是什么?一个项目经理的首要担心的三个问题是什么?将你的企图、知识和感兴趣的方面调整到你听众的一边。

3、查看你的条款。很多次我的解释说明已经挫败了意想不到的分歧术语。条款如测试、测试用例、测试计划、回归测试和缺陷，这些我称之为危险术语，因为对于这些条款有很多不同的定义。如果你辩证的看待自己，考虑像以前一样简要定义这些条款。

4、展示出尊重。对待每个人好像他们都是非常聪明的人，并且他们和你一样的关心质量。尊重异议和问题，我发现我有时候可以将处于敌对状态的听众通过善意的，有洞察力的解释转变过来，这和他们是否真的有企图和有洞察力是没有关系的。我用这种方式对待他们，因为不这样做肯定会失败。

5、引出有趣的话题。你不可能向一个不感兴趣的人有成果的解释事情。引起你的听众一点的兴趣他就会提出问题。如何这样做的方法之一就是抛出一些显而易见的不清楚的地方、行话或者和你的解释说明矛盾的地方，如果你的听众询问他们，你就回答说“好眼光，我非常乐意听到你这样询问，这是个非常重要的问题。”如果他们不询问，他们说“你或许没有注意到这里有一个矛盾的地方，你将有权提出质疑?”不论是那种方式，继续将该问题更好的解释。

6、解释问题发生后的事情。按照你的想法做了执行的差异是什么?你希望发生什么?如果我们接受了你的测试观点我们行为有何不同?将注意力集中在你解释后面的任务上。

7、迅速一点，找到关键。使用简短的语句，那么也许你可以完成你的解释，而不是在妙语连珠以前就被阻止。

8、展示出人人如何参与。我尽自己最大努力将项目的情况真实的描述：我们都在一起，我们都有贡献，如果事情出错了我们共同承担。如果你发现解释每个人所扮演的角色比较困难，那么停下来思考你是否能够成功的解释这个项目。如果只是牵扯你一个人，那么你将会使你的听众厌烦，如果只是牵扯进他们，那么你听起来像是插足了不是你的业务范围的领域。

9、准备充分。开发多种解释的标准、预先的比喻以及不明白的时候要记录。解释测试的想法经常是在我真正在测试时，所以我准备了一个记事本用来捕获这些想法，现在我有一大堆的记事本，上面写满了解释的片段。

http://developer.51cto.com/art/200907/140591.htm
推荐：

本文通过描述一个常见的走廊对话情景，说明一个程序员应如何解释测试的概念。没有什么能够替代实践，但是这些知识可以帮助你建立自己的对话技巧。两个帮助我成为一个更为有效的解释者的是Gerald Weinberg 的“解决问题探讨会”和“转变”，这些涵盖了整个做技术的小组。