James Whittaker系列——10分钟测试计划

10分钟测试计划

Thursday, September 01, 2011
By James Whittaker

在软件开发中，一般只需要十分钟或更少时间做的事都被当成小事，不值重视。如果你把这个思想视为信条，那“测试计划”又被置于何种境地？当然写测试计划肯定是要超过10分钟的。作为谷歌的测试主管，我主导了不少测试计划的撰写，每次我问到组员多久能写完测试计划，他们都告诉我“明天”或者“周末”，但是早一天前，我收到的承诺就已经是“今天下班前”。所以，接下来，我要把测试计划的任务期限变成以小时以天来计。
要是怀疑这种方式是否可取，那我这儿还有另外一个实例。每次我都会看组员写的一打测试计划，而我看到的都是死气沉沉的测试计划。写计划、评审、计划文档用过几次，然后项目有变而计划文档又没涉及到这变化部分，之后自然就被抛弃在一边。这里凸显了一个疑问：如果计划不值得费时间去更新，那它还值得在项目一开始就费时费力吗？
还有些时候，一个计划会因为写的太粗或者细节太多而被抛弃；还有时，计划仅仅在测试开始时能发挥效用。同样的问题又引申出来，难道测试计划的价值只能停留在局限又狭小的范围内吗？

一些测试计划文档所阐述的内容可能根本不能用文档来描绘，同样，文档提供的内容和日常的测试工作可能也不能完全关联起来。我们一直可能都在做无用功。让我们一起来面对一个现实吧：当下测试计划和测试工作之间是有矛盾的。

为了解决这一矛盾，我在我的团队里试验了一项方法：测试计划的写作限定在10分钟以内。这个想法的出发点很简单，物尽其用，如果测试计划有用，那我们能尽快get到重点。

 只给10分钟，那时间就被完全压缩，只能花在有效的细节上。我从这项方法中得到的经验就是：高度提炼测试计划，去掉所有其他无谓的细枝末节。只做最有必要的部分，把详细的细节留给测试执行人员。如果，我想把测试计划变成测试中更加有效的部分，这是一个值得一试的方法。
然而，实施这一方法时，我并没有明确告诉我的组员。我仅仅告诉他们：这是一个应用，用10分钟甚至更少的时间来完成测试计划。记住，从技术上来说，这些人是为我工作的。我需要他们的信任，需要他们坚信自己能做到。这对我来说很重要，我希望他们抱着必赢的信念。

在准备阶段，组员需要花一定的时间来适应，熟悉这种方式。然后，在一些工具（Google Docs，APP Engine，对话视频等）的帮助下，这方面花费的时间越来越少。

接下来谈谈实施的过程：

刚开始时，到了10分钟，我就去打断组员，起初，他们无法完成。我告诉他们，超时了，但这是很好的尝试。之后的10分钟，还是会出现同样的问题。但是他们已经开始做得更快，并开始尝试不同的角度，耗时和不值得尝试的部分都会被很快地抛弃掉。
在每一个项目中，团队都找到能加快工作效率的技术方法。组员们选择列出清单，以写好的长篇段落为基调来创建网格（这句求翻译？？create grids over writing long paragraphs of prose）。句子描述。。。是的，段落描述。。。不。他们在文档格式和说明上花费更少的时间，不再强调文档能力。
实践中最重要的有三个方面：
1、属性要用极度准确的副词和形容词来描述，比如快速、可用的、安全、易用的，等等。
2、组件要用名词表述，这里组件指产品代码部分中的类、模块名称和功能点。
3、功能用动词来描述用户的动作和行为。

团队并没有在分配的10分钟写完过测试计划。但是，在这10分钟内，他们能理清属性和组件（或者其他类似的部分）并开始尝试文档的功能点。在接下来的20分钟后，在大部分实践中组员能找到足够多的功能点，这些功能点是之后创建用户故事（user stories）和测试用例的有效起点。
这个尝试，至少对我来说，是成功的。我给了他们10分钟，而希望的是1小时。他们实际能在半小时完成近80%的工作。80%不够？我们知道测试本身都不能穷尽，又何苦要求文档如此呢？我们也知道，测试一开始，相关事物（计划、需求、架构等等）也是随时在变的，所以，单单孤立地死守计划文档的精确度，显然是脱离实际的。
在30分钟或者更短时间内完成80%，这就是我所说的10分钟测试计划！