10分钟测试计划

Posted: 01 Sep 2011 02:28 PM PDT

By James Whittaker

文章来源：Google Test Blog

Anything in software development that takes ten minutes or less to perform iseither trivial or is not worth doing in the first place. If you take this ruleof thumb at face value, where do you place test planning? Certainly it takesmore than 10 minutes. In my capacity as Test Director at Google I presided overteams that wrote a large number of test plans and every time I asked how longone would take I was told “tomorrow” or “the end of the week” and a few times,early in the day, I was promised one “by the end of the day.” So I’ll establishthe task of test planning to be of the hours-to-days duration.
软件开发过程中花10分钟或者更少时间能搞定事情要么不值得做要么不会是很重要紧急的事情。如果用这条定律你怎么看待测试计划？当然测试计划需要不止十分钟。我作为Google的测试主管，要求我们团队写很多的测试计划，并且每次当我问到需要多长时间的时候他们总是回答“明天”或者“本周末”，今天早晨我就得到了一个“今天晚些时候”的答复。所以我认为做一个测试计划需要几个小时到几天的时间。

As to whether it is worth doing, well, that is another story entirely. Everytime I look at any of the dozens of test plans my teams have written, I seedead test plans. Plans written, reviewed, referred to a few times and then castaside as the project moves in directions not documented in the plan. This begsthe question: if a plan isn’t worth bothering to update, is it worth creatingin the first place?
同样，对于值不值得做测试计划，这是完全是另外一个问题。每次我看到我的团队写的这些测试计划，我只看到死的测试计划。书面的方案，评估，修改多次然后当项目不再需要文档的时候这些测试计划就都被束之高阁。这样就产生一个问题：如果一项计划不值得花心思去更新那么当初建立这个计划是否值得？

Other times a plan is discarded because it went into too much detail or toolittle; still others because it provided value only in starting a test effortand not in the ongoing work. Again, if this is the case, was the plan worth thecost of creating it given its limited and diminishing value?
另外一种测试计划被丢弃的原因是测试计划太详细或者太宽泛。还有一种是因为测试计划只在开始测试时有用，测试进行过程中就失去作用了。如果是这样子，那么是否值得建立一个测试计划，规定一些事项，然后在项目中越来越失去作用？

Some test plans document simple truths that likely didn’t really needdocumenting at all or provide detailed information that isn’t relevant to theday to day job of a software tester. In all these cases we are wasting effort.Let’s face facts here: there is a problem with the process and content of testplans.
一些测试计划只简单的列出来一些根本不需要文档化的条例，或者给出一些详细的规定这些规定根本和每天的软件测试工作一点不相关。上述情况都是在浪费资源。让我们直面问题：测试计划的过程和内容是怎样的。

To combat this, I came up with a simple task for my teams: write a test plan in10 minutes. The idea is simple, if test plans have any value at all then let’sget to that value as quickly as possible.
为了论证测试计划，我给我的团队分配了一个简单的任务：十分钟之内写一个测试计划。这个想法很简单，如果测试计划有意义那么让我们尽快找到其意义。

Given ten minutes, there is clearly no room for fluff. It is a time period socompressed that every second must be spent doing something useful or any hopeyou have of actually finishing the task is gone. This was the entire intentbehind the exercise from my point of view: boil test planning down to only the essentialsand cut all fat and fluff. Do only what is absolutely necessary and leave thedetails to the test executors as opposed to the test planners. If I wanted toend the practice of writing test plans that don’t stand the test of time, thisseemed a worthwhile exercise.
只有十分钟，当然只能去粗取精。10分钟时间很短所以每秒都必须用来做有用的事或者可能促使你完成这项任务的事情。从我的角度来说我设置这项任务基于以下观点：时间很紧急的测试计划会留下比较重要的内容去除那些无关紧要的项目。做那些真正需要做的事，违背测试计划执行者的职责把那些细节问题留给测试执行者们去做。如果我想停止那些不能在项目进行中起作用的测试计划，这样做看起来值得一试。

However, I didn’t tell the people in the experiment any of this. I told themonly: here is an app, create a test plan in 10 minutes or less. Remember thatthese people work for me and, technically, are paid to do as I tell them. And,again technically I am uniquely positioned to begintermination procedures with respect to their Google employment. On top of thatI am presuming they have some measure of respect for me, which means they werelikely convinced I actually thought they could do it. This was important to me.I wanted them to expect to succeed!
然而，我不会告诉参加实验的人这些事情，我只告诉他们：这是app，10分钟之内做一个测试计划。这些人是在我手下干的，并且他们做我让他们做的事情可以得到报酬的，并且，我是唯一一个可以终止他们和Google之间雇佣关系的人。然后我冒昧的假设他们尊重我，这意味着他们相信我让他们做的事情。这是很重要的，我想让他们期望成功！

As preparation they could spend some time with the app in question andfamiliarize themselves with it. However, since many of the apps we used (GoogleDocs, App Engine, Talk Video, etc.) were tools they used every week, this timewas short.
他们可能会问一些关于app的问题来熟悉和为测试计划做准备，但是，因为他们经常使用这些app作为工具，所以前期的问题和准备时间比较短。

So here's how the task progressed:
所以这是这项任务的进展：

They started, did some work and when ten minutes passed I interrupted them.They stated they weren't done yet. I responded by telling them they were out oftime, nice try, here's a different problem to work on. 10 minutes later, thesame thing happened and I changed the problem again. They began working fasterand trying different angles, things that were too time consuming or not worththe effort got jettisoned really quick!
他们开始了，十分钟内做了一些事，然后我告诉他们时间到。他们说还没完成，我回答不管怎么样时间到了，做的不错，这里还有另外一个更加困难的事情需要你来处理一下。10分钟过后，相同的事情发生了，我又换了一个任务。他们开始工作更快并且开始寻求不同的角度，那种需要花很长时间的或者不太重要的事情都被搁置一边了。

In each case, the teams came up with techniques that helped speed things along.They chose to jot down lists and create grids over writing long paragraphs ofprose. Sentences … yes, paragraphs … no. They wasted little time on formattingand explanations and chose instead to document capabilities. Indeed,capabilities or what the software actually does, were the onecommonality of all the plans. Capabilities were the one thing that all theteams gravitated toward as the most useful way to spend the little time theywere given.
对于每个任务，大家开始使用各种技术来加速工作。他们选择记少量笔记画表格而不是写大段的描述语句。句子-可以，一段话-不要。他们花很少的时间调整格式和写批注，时间主要用来写重要的功能。事实上，功能，或者软件能完成什么事情就是计划中最重要的部分。所有的团队都在有限的时间内不约而同的写下了软件的功能。

The three things that emerged as most important:
以下就是我的实验得出的最重要的三点：

1. Attributes the adverbs and adjectives that describe thehigh level concepts testing is meant to ensure. Attributes such as fast,usable, secure, accessible and so forth.
1 属性 概念测试被定义为“确保”，例如速度，可用性，安全性，接入性等等

2. Components the nouns that define the major code chunks thatcomprise the product. These are classes, module names and features of theapplication.
2 模块 这个名词定义了组成产品的主要代码块，他们是类，模块和应用的特点

3. Capabilities the verbs that describe user actions andactivities.
3 功能 这个词描述了用户的行为和活动

None of the teams finished the experiment in the 10 minutes allotted. However,in 10 minutes they were all able to get through both the Attributes andComponents (or things that served a similar purpose) and begin documentingCapabilities. At the end of an additional 20 minutes most of the experimentshad a large enough set of Capabilities that it would have been a usefulstarting point for creating user stories or test cases.
没有一个团队在10分钟之内完成了我分配的任务，10分钟之内他们只完成了属性和组件（或者类似的意思）和功能的开头部分。如果再加20分钟大部分的团队完成了很大的功能部分，这部分在测试用例或者用户手册里面会起到指导作用。

Which, at least to me, made the experiment a success. I gave them 10 minutesand hoped for an hour. They had 80% of the work complete in 30 minutes. Andreally isn’t 80% enough? We know full well that we are not going to testeverything so why document everything? We know full well that as we starttesting, things (schedules, requirements, architecture, etc.) are going tochange so insisting on planning precision when nothing else obeys such acalling for completeness seems out of touch with reality.
这项实验是成功的，至少对我来说。我给了他们10分钟并且等了1小时，他们在30分钟内完成了80%的工作。那么80%的工作真的足够了吗？我们都知道我们不能测试所有的情况那为什么还要写下所有的情况？我们都知道当我们开始测试了，事情（计划，需求，框架等）会变来变去，其他的事情都有变动而我们却严格的遵循计划似乎并不符合实际。

80% complete in 30 minutes or less. Now that’s what I call a 10 minute testplan!

30分钟之内完成80%的测试计划，这就是我所说的10分钟的测试计划！