测试的宣传

测试的宣传

陈能技

2007-8-23

 

原文：Explaining Testing to Them - Helping non-testers understand and support your work （James Bach）

 

当程序员或经理对测试做出一些无知的解释时，你会有什么感觉？你不喜欢？但是我喜欢，因为至少他们说出来了。我的经验是：我的大部分非测试员同事，无论他们在自己的工作方面有多优秀，他们对我的工作的认识都比较模糊。但是如果他们什么也不说，我也对此束手无策。所以，在某种程度上，我会感觉好些，在我听到他们说一些类似这样的话：“你就是操作每个功能看它是否工作而已，对吧？这有什么难的？”

 

因为如果他们说出来，或许他们会听一下。如果他们倾听，或许我能给他们提供一个更有用的测试观。也许你认为你的同事们都已经明白测试是怎样工作的，其实不然。你才是测试专家。你喜欢测试，你热爱测试。因为你很在行，项目组中的其他角色的同事在他们专注的区域也非常在行。他们对测试的混淆概念恰好证明他们需要你。

 

在测试上，往往喜欢区分“我们”和“他们”。对测试进行好的解释会把整个项目组拉到一起。这很重要，因为其他项目组成员，包括经理，他们不会完全支持你的工作，除非他们理解你正在做的事情。

 

It Starts with Intent and Attitude

出发点和态度决定一切

 

我建议你在做每次解释的时候都抱着这样的相同的目的：使你的同事更加强大和成功，帮助他们做出更有效的决定，并且帮助他们知道如何从你的工作中获取到最多的东西。

 

如果你解释测试过程的自动化给他们听，那么项目组会使用这些自动化过程的信息来“改进系统”并且从你这里获取更多的信息。如果程序员理解可测试性的好处，他们会设计好产品的可测试性，以便你能压缩测试计划，减轻你的测试复杂度。

 

注意沟通的技巧，保持做一个学生的心态很重要，“如果我会写程序，能让它自动化地测试这个产品就好了，但是我不知道怎么去做。”听起来会舒服一点。

 

The Hallway Dialogue

走廊对话

 

一天，我在走廊上遇到开发经理Adam。

 

Adam说：“我们需要把计划延迟3周。我知道你的计划是在代码冻结后需要8周的时间测试。你能否在5周内完成？我们可能没有那么多的时间测试了。”

 

我首先想到的是这个家伙对质量不够严肃。但是我很快知道这个想法无益，应该抛弃。另外一个有益的想法浮现在我脑海：也许Adam认为我能控制测试计划的各项因素。

 

我说：“测试计划不是我控制的，Adam，8个星期是基于产品的复杂度和我们能想到的困难而估算出来的。也许需要8周也许不需要8周，这取决于代码冻结后我们拿到的测试版本的技术状态”。

 

注意我尝试说明影响测试计划的因素，我希望他会问那些因素是什么，那么我就可以找个白板列个表给他说明。

 

Adam说：“你不能预测这个计划？”

 

又一次，我的无益的想法出来了：也许是我错了，也许谁都可以预测计划，就是我不行？但是最后我也让这些消极的想法过去。

 

有效的回答是什么呢？也许Adam想要一个直接的答案，但是我想尝试把它展开来说，以便把问题的方方面面搞清楚，这样我们的交流才更加富有成功。我还想举些例子来说明问题。

 

我说：“我不知道怎样精确地预测计划。工作可能很快也可能很慢，要看情况。在Alaska项目，bug2642，记得吗？它耗费了我们2周的时间把它找出来并重现。结果是与某个著名的防病毒工具有关系。你也很高兴能在发布之前把它fix掉，但是我们不能预先知道这样的事情。”

 

Adam：“我也知道很难评估，但是能否压缩一下工作，在5周内搞定呢？”

 

我不明白为什么Adam专注在这个时间范围。他好像没有听我说。如果我回答并解析这个问题，他可能会生气。走廊解释的秘诀在于知道什么时候“说教”什么时候“闭嘴”。在现在这种情况下，应该倾听。

 

我说：“我知道进度对你来说很重要。但是5周的重要性是什么？”

 

Adam：“是这样的，在我们早期计划的时候，几个高级经理把时间搞混了。我们都认为发布时间是6月30号，结果是收入时间，发布时间要至少提前3周，以便及时发货。”

 

我说：“如果产品到那个时间就是还没准备好怎么办？”

 

Adam：“必须要。”

 

我说：“如果不是呢？”

 

我的问题的目的是把情况说清楚，以便我们能把现实和愿望分开看待。然后我可以向他说明不是只有一个选择，而是有很多选择。

 

Adam：“副总不会喜欢这样的。”

 

我说：“可能是。但是作为一名测试员，我的工作是提供信息以帮助组织做出更好的决定。我在这里看到多个选择。最后副总可能会愿意推迟产品发布而不愿意看到一个很糟糕的产品。或者他会希望我们把一些功能特性去掉。”

 

Adam：“为什么我们不能修改一下策略，获得我们想要的效果？你自己也说了测试可能不需要8周。我想整个过程能更紧凑点。”

 

现在他看起来接受了不止一个选择的观点，他在建议他的选择。现在他不得不考虑影响决定的因素，这是我想他需要明白的关于测试的东西。

 

我说：“好吧，我们来看看，首先，我希望你明白测试计划不是仅仅取决于我，当我们的质量要求很高时，我们需要做更多仔细的测试。如果开发递交的产品是很不稳定的，我们的某些测试可能会阻塞。如果开发递交的产品很难让我们理解和诊断，很难控制，那么测试进度会很缓慢。如果我们找到的bug很多是难以捉摸的、间歇出现的，那么我们的测试和报告会需要更多的时间。如果产品的变更控制没有管理好的话，我们可能需要做广泛的测试。如果程序员花很长的时间去修改bug，他们可能不能按时提交测试，不管还遗留多少测试需要进行。你知道我的意思吗, Adam？如果你想调整计划，我们就要看是什么影响计划的。”

 

Adam：“我知道你的意思。那么我可以帮什么忙呢？如果我让程序员帮你测试怎样？我们帮你执行部分测试用例怎样？”

 

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

 

Adam：“真的？但是如果你预先组织好测试用例不是更好吗？这样不是更快吗？”

 

好了，现在我要对付一个不了解测试的人了，我想说：你的需求规格说明书一团糟，但是你期望我们写出高质量的测试用例文档？你饶了我吧！

 

最好把这些想法也打消，我会换一种表达方式。他是对的，有时候是能预先定义出好的测试用例，希望测试员无论在什么情况下都这样做也没有罪。

 

我说：“对，有时候，那样做是最好的。但在我们现在的情况是，我不知道怎么做好。太多不确定的东西了。我么可以写测试用例，但是它们写出来是很糟糕的。充分预先定义测试是要在有可测产品或者基于稳定的、定义良好的技术文档的基础上，否则，他们就只是敷衍了事而已。我们的挑战在于一旦我们能很好地创建的时候创建指定的测试。”

 

Adam：“那么你怎么控制测试呢？你有测试计划吗？”

 

一个普遍的误解是只有计划文档才能控制过程。现在是机会介绍我的不同做法的时候了。

 

我说：“大部分情况下我们使用探索性测试方法，基于风险的测试方法。如果你指的测试计划是关于测试过程的一系列的想法，那么我们有测试计划，没有写下来但是作为笔记记在我的笔记本上，但是我可以跟你一起分享一下，如果你愿意的话。实际上，我们是通过频繁的报告测试状态并基于产品的风险调整测试策略来控制测试的。换句话说，作为我们测试过程的客户，我希望你能参与到控制我们的测试中来。”

 

“探索性测试”和“基于风险”是强调词，我希望引起他的注意，问我关于怎样测试的更多问题。但是有点冒险，有可能弄巧成拙。

 

Adam：“什么是探索性测试方法？”

 

好，他上钩了，他可能以为我在唬他。但是至少他注意到了。现在是我大加分析解释的时候了。

 

我说：“就像对产品玩问问题的游戏。我们一轮一轮地测试。我们同时在学习这个产品，设计测试用例，执行测试，报告问题。我们的测试覆盖随着我们对产品模型的理解的改进而改进。我们还会用一系列的测试启发列表。如果你想看的话我可以现在给你看。这是我所知道的测试一个新的、不熟悉的产品的最快的办法。你想不想让测试更快一点？让测试员了解产品是怎样的，它是怎样工作的。我们可以为测试员计划组织一个一小时左右的产品简报会，然后再有一个小时左右的问答讨论。然后我们可以头脑风暴一下，为我们想出更多的具体的测试策略，怎样？”

 

Adam：“那我们什么时候会知道整个测试过程需要多长时间？”

 

我说：“我们现在就可以坐下来，仔细看看哪些因素影响：风险、各种测试任务、开发任务。也许我们可以找到方法压缩一下测试过程，但是我们也要想想其它的选择。是否考虑我们项目最初的愿望？改bug和测试过程是否会拖延……”

 

这是典型的走廊解释。它可能发生在项目会议上，而不是走廊，但是原则是一样的。我们很少有机会解释我们的工作，所以要准备好一些例子（例如bug2642的悲惨故事）或一些理论知识。

 

实践是少不了的，但是也有一些课程可以帮助你加强你的对话技巧。

 

Principles of Hallway Explanations

走廊解释的原则

 

1、Speak from practice.根据事实说话

最好说自己熟悉的项目，说自己理解的东西。

 

2、Be with your audience.换位思考

替别人想想，一个副总关心的是什么？技术支持经理是怎样工作的？项目经理最害怕的3样东西是什么？

 

3、Check your terms.术语的解释

很多术语是有很多不同的解释的，例如：测试、测试用例、测试计划、回归测试、bug，这些都是危险的词语。你自己要有自己理解的解释。

 

4、Show respect.尊重别人

要认为别人和你一样关心质量、尊重别人的反对意见、质疑和问题，把异议当成是关注、有见解，不管别人是否真的就是这样关心质量，关注测试。

 

5、Provoke interesting questions.抛出有趣的问题

对于一个对问题不感兴趣的人是很难有效地解释的。适当煽动或引诱你的听众问问题。适当地加些行话、术语、矛盾到你的解释中。如果你的听众提出疑问了，说“好眼力，我很高兴你会问这个。这是个很重要的问题。”如果他不问，那么你可以说“你可能也注意到了一些矛盾的地方。”

 

6、Explain things that matter.解释重要的问题

 

7、Be quick. Get to the point.要快、直接、直奔主题

用短句。长句容易被打断，短句会让你有机会完成你的解释。

 

8、Show how everyone is involved.表明我们都在一条船上

我会努力让别人明白：我们都在一条船上。我们都贡献。如果事情没做好我们都会遭罪。

 

9、Be prepared.时刻准备着

准备好关于测试的各种解释。随时记录关于解释的各种想法。

 

What If They Don't Believe You?

如果他们不相信你怎么办？

 

首先不用太担心这个问题。在Harvey这部电影中，Jimmy Stewart说了句有名的台词：“在这个世界，你必须很聪明，或者很愉快。我一直很聪明。我推荐愉快。”有时候你不能说服别人。这时你还有其它的资源：现实。所以，深吸一口气，愉快点，放长双眼瞧吧。事实证明一切。项目可能碰到困难，或者不会。不管怎样，注意记录有关的决定和事情是怎样发展和结局的。

 

最后，项目组会达成共识。人们从自己的经验体会中学东西会比从陌生人的故事中学习抽象的逻辑要学到得更多。而那些共享的经验会为你下次给别人解释测试时提供很好的基础。