译者：蔡小滢
在软件开发上任何花费时间少于十分钟的都是非常琐碎或者优先级不高的。如果你使用这个准则来衡量事情的价值，那么你打算怎么看待测试计划呢 ？当然，要进行一个测试计划所花费的时间是不止10分钟的。
在我担任 Google 测试主管时，我带领过一个写大量测试计划的团队，每每询问到完成一个测试计划需要多长的时间，我总被告知「明天」，「这周末」或者有几次被告知「今天晚些时候」。所以我会理解为完成一个测试计划是需要几个小时到几天的时间。
至于测试计划是否值得做，这个又是一个问题了。每次我看到我的团队写的大量的测试计划时候，我觉得这些测试计划是没有生机的。测试计划被完成，审查，参考几次之后，随着项目朝着计划并没有覆盖的方向进展，测试计划也相应地被束之高阁。这个现象带来了新的问题 : 如果一个测试计划不值得花心思去更新，是否值得去创建呢 ？
测试计划被废弃的其中一个原因是测试计划太详细或者太宽泛。还有一种原因是测试计划只在开始测试时有用，而过程中就失去作用了。如果是这样子，那么是否值得建立一个测试计划,做其一些限制并降低一点指标。
一些测试计划只简单的列出来一些根本不需要文档化的条例，或者给出一些详细的规定这些规定根本和每天的软件测试工作一点不相关。上述情况都是在浪费资源。让我们直面这些现象：测试计划的实施过程和内容制定是有问题的。
为了解决这个问题，我给我的团队分配了一个简单的任务：十分钟之内写一个测试计划。这个想法很简单，如果测试计划有意义那么让我们更快地找到其意义。
只有十分钟，当然只能有所侧重的做事情。10分钟时间很短所以每秒都必须用来做有用的事或者可能促使你完成这项任务的事情。
从我的角度来说建立这项任务基于以下目的：
-
减少测试计划中无关紧要的项目
-
做最有必要的事情，把不在测试计划者的职责范围内的和过于细节的问题留给测试执行者们去做
然而，我不会告诉参加实验的人这些事情，我只告诉他们：这是app，10分钟之内做一个测试计划。
这些人是在我手下工作的，并且他们做我让他们做的事情可以得到报酬的，并且，我是唯一一个可以终止他们和Google之间雇佣关系的人。然后我冒昧的假设他们尊重我，这意味着他们相信我让他们做的事情。这是很重要的，我想让他们期望成功！
他们可以会问一些关于 app 的问题来熟悉应用并为测试计划做准备，但是，因为他们经常使用这些 app (GoogleDocs, App Engine, Talk Video, etc.) ，所以前期的准备时间减少了。
所以这是这项任务的进展：
-
他们开始了，十分钟内做了一些事，然后我告诉他们时间到。
-
他们说还没完成，我回答不管怎么样时间到了，做的不错，这里还有另外一个更加困难的事情需要你来处理一下。
- 10分钟过后，相同的事情发生了，我又换了一个任务。他们开始工作更快并且开始从不同的角度思考，那种需要花很长时间的或者不太重要的事情都被搁置一边了。
- 对于每个任务，大家开始使用各种技术来加速工作。他们选择记少量笔记画表格，或者一句话，而不是写大段的描述语句，
- 他们花很少的时间调整格式和写批注，时间主要用来写重要的功能。事实上，功能，或者软件能完成什么事情就是计划中最重要的部分。所有的团队都在有限的时间内不约而同的写下了软件的功能。
以下就是我的实验得出的最重要的三点：
-
属性 概念测试被定义为“确保”，例如速度，可用性，安全性，接入性等等
- 模块 这个名词定义了组成产品的主要代码块，他们是类，模块和应用的特点
- 功能 这个词描述了用户的行为和活动
这项实验是成功的，至少对我来说。我给了他们10分钟并且等了1小时，他们在30分钟内完成了80%的工作。
那么80%的工作真的足够了吗？我们都知道我们不能测试所有的情况那为什么还要写下所有的情况？我们都知道当我们开始测试了，事情（计划，需求，框架等）会变来变去，其他的事情都有变动而我们却严格的遵循计划似乎并不符合实际。
30分钟之内完成80%的测试计划，这就是我所说的10分钟的测试计划！
原文链接：http://zhuanlan.zhihu.com/softwaretesting/19634772
翻译自：http://googletesting.blogspot.com/2011/09/10-minute-test-plan.html
