我说：“我不知道怎样精确地预测计划。工作可能很快也可能很慢，要看情况。在Alaska项目，bug2642，记得吗？它耗费了我们2周的时间把它找出来并重现。结果是与某个著名的防病毒工具有关系。你也很高兴能在发布之前把它fix掉，但是我们不能预先知道这样的事情。”
Adam：“我也知道很难评估，但是能否压缩一下工作，在5周内搞定呢？”
我不明白为什么Adam专注在这个时间范围。他好像没有听我说。如果我回答并解析这个问题，他可能会生气。走廊解释的秘诀在于知道什么时候“说教”什么时候“闭嘴”。在现在这种情况下，应该倾听。
我说：“我知道进度对你来说很重要。但是5周的重要性是什么？”
Adam：“是这样的，在我们早期计划的时候，几个高级经理把时间搞混了。我们都认为发布时间是6月30号，结果是收入时间，发布时间要至少提前3周，以便及时发货。”
我说：“如果产品到那个时间就是还没准备好怎么办？”
Adam：“必须要。”
我说：“如果不是呢？”
我的问题的目的是把情况说清楚，以便我们能把现实和愿望分开看待。然后我可以向他说明不是只有一个选择，而是有很多选择。
Adam：“副总不会喜欢这样的。”
我说：“可能是。但是作为一名测试员，我的工作是提供信息以帮助组织做出更好的决定。我在这里看到多个选择。最后副总可能会愿意推迟产品发布而不愿意看到一个很糟糕的产品。或者他会希望我们把一些功能特性去掉。”
Adam：“为什么我们不能修改一下策略，获得我们想要的效果？你自己也说了测试可能不需要8周。我想整个过程能更紧凑点。”
现在他看起来接受了不止一个选择的观点，他在建议他的选择。现在他不得不考虑影响决定的因素，这是我想他需要明白的关于测试的东西。
我说：“好吧，我们来看看，首先，我希望你明白测试计划不是仅仅取决于我，当我们的质量要求很高时，我们需要做更多仔细的测试。如果开发递交的产品是很不稳定的，我们的某些测试可能会阻塞。如果开发递交的产品很难让我们理解和诊断，很难控制，那么测试进度会很缓慢。如果我们找到的bug很多是难以捉摸的、间歇出现的，那么我们的测试和报告会需要更多的时间。如果产品的变更控制没有管理好的话，我们可能需要做广泛的测试。如果程序员花很长的时间去修改bug，他们可能不能按时提交测试，不管还遗留多少测试需要进行。你知道我的意思吗, Adam？如果你想调整计划，我们就要看是什么影响计划的。”
Adam：“我知道你的意思。那么我可以帮什么忙呢？如果我让程序员帮你测试怎样？我们帮你执行部分测试用例怎样？”
我说：“我们没有定义测试用例。”
Adam：“真的？但是如果你预先组织好测试用例不是更好吗？这样不是更快吗？”
好了，现在我要对付一个不了解测试的人了，我想说：你的需求规格说明书一团糟，但是你期望我们写出高质量的测试用例文档？你饶了我吧！
文章来源于领测软件测试网 https://www.ltesting.net/
