什么是走廊对话

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文转自：http://www.ltesting.net