和测试人员相比，开发人员有一个优势就是他们的工作产物是每个人都真正关心的。开发人员编写代码，构建用户期望的、能够为公司赚钱的应用。很明显，代码是项目过程中产生的最重要的文档。
然而，测试人员要处理的是真正的文档和其他临时性的事物。在项目的早期阶段，测试人员编写测试计划；然后，他们创建和执行测试用例，编写bug报告；接下来是准备覆盖度报告，收集用户满意度和软件质量数据。在软件成功发布（或失败）之后，很少有人会问及测试产物是什么。如果软件深受人们喜爱，大家就会认为测试所作所为是理所当然的；如果软件很糟糕，人们可能就会质疑测试工作。但其实也没人真正想要去了解测试到底做了什么。
测试人员不应该对测试文档过于珍爱。软件开发过程充满了痛苦的挣扎：编码、评审、构建、测试、一轮接一轮的开发等，在这个过程里实在很难有时间坐下来欣赏一下测试计划。糟糕的测试用例不会受到足够的关注和改善，它们只会被抛弃，而最后留下来的是更好的测试用例。大家的关注点集中在不断增长的代码库，这才是最重要的东西，理应如此。
作为一种测试文档，测试计划的生命周期是所有测试产物中最短的。在项目早期，人们需要一个测试计划。事实上，项目经理经常坚持必须有一个测试计划，并将编写测试计划作为一个比较重要的里程碑。但是，一旦计划就绪，这些人就把它扔到一边了，既不评审也不更新。测试计划就像是闹脾气的小孩儿手中可爱的毛绒玩具，我们希望它总是存在，到哪里都能带着它，但却从不真正关注它。只有它被拿走的时候，我们才会发出尖叫。
测试计划是最早出现、最先被遗忘的测试产物。在项目早期，测试计划代表了对软件功能的预期。但是除非得到持续的关注，它会很快随着新代码的完成、功能特性的改变以及设计的调整而过期。伴随着计划内或计划外的变更，维护一份测试计划是要花费大量精力的，除非多数项目成员会定期查看，否则测试计划并没有什么价值。
后面这一点是测试计划真正的杀手：试问在产品的整个生命周期中，测试计划能在多大程度上作为测试活动的指导？测试人员会不断参考计划来安排一个应用的测试吗？会要求开发人员在功能增加或修改时去更新测试计划吗？在开发经理管理的to-do列表的时候，他们会在桌面上打开一份测试计划吗？在进展沟通会议上，测试经理会经常参考测试计划的内容吗？如果测试计划真的重要，那么所有这些事情应该每天都会发生。
理想情况下，测试计划应对在项目执行中发挥核心作用，应对在软件的整个生命周期中持续有效：随着代码库的更新而更新，时刻代表最新的产品功能，而不是停留在项目开始阶段的样子。它应该可以帮助一个新加入的工程师迅速跟上项目进展。
下面是谷歌希望测试计划具有的一些特性：
及时地更新；
描述了软件的目标和卖点；
描述了软件的结构、各种组件和功能特性的名称；
描述了软件的功能和操作简介。
从纯粹测试的角度看，我们担心的是测试计划的投入和价值产出是否匹配？
不必花过多的时间去撰写，必须随时可以被修改；
应该描述比测点；
应该能在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足。
在谷歌，采用ACC（Attribute Component Capability，即特质、组件、能力）分析来作为测试计划。
ACC的指导原则如下：
避免散漫的文字，推荐使用简明的列表；
不必推销；
简洁；
不要把不重要的、无法执行的东西放进测试计划；
渐进式的描述；
指导计划者的思路；
最终结果应该是测试用例。
最后一点非常重要：如果测试计划没有把测试用例应该怎么执行描述的足够详细，它就没有达到预先设定的帮助测试的本义。对测试的计划而言，它显然应该让我们清楚地指导需要编写哪些测试用例。当你正好处于“完全了解需要编写哪些测试”这一点时，才算完成了测试计划。
ACC通过指导计划者一次考察产品的三个维度达成这个目标：描述产品目标的形容词和副词；确定产品各部分、各特性的名词；描述产品实际做什么的动词。这样，我们通过测试完成的就是验证这些能力能正常运作、产品各组件能满足应用的目标。
1、A代表特质（Attribute）
特质是系统的形容词，代表李产品的品质和特色，是区别于竞争对手的关键，也是人们选择你的产品而不是竞争对手的产品的原因。
一般来说，产品经理会整理一个系统特质的列表，测试人员通过阅读产品需求文档、团队愿景和使命声明，甚至是挺销售跟潜在的客户描绘这个系统来确定这个列表。说真的，我们发现在谷歌，推销员和产品传道士是极佳的特质来源。一些小窍门可以帮助确定产品特质列表：
简单。如果1~2个小时还没有完成，那么你在这一步花的时间太多了。
精确。确保它来自于团队已经普遍认同的文档或营销信息。
变化。不必担心你是否漏掉了什么--如果后来发现这个特质不明显，极有可能它也不怎么重要。
短小。数量方面，十二个是一个不错的目标，也可以更少。
特质就在那里等着你。如果你不能在几分钟内列举出来，说明你还没有足够的理解你的产品，还不能有效地测试它。一旦熟悉了你的产品，罗列特质不过是几分钟的事情。
2、C代表组件（Component）
组件是系统的名词，在特质被有效识别之后确定。组件是构成代建系统的模块，是使一个软件之所有如此的核心要素和代码块。一般来说，组件容易识别，经常出现在设计文档里。对大型系统来说，它们是架构图里的大框架，经常出现在bug库中的标签里，或者在项目主页和文档中被高亮出来。对小型项目来说，它们是代码里的类和对象。无论何时，只要问一下开发人员“你们在编写什么组件”，你就可以毫不费力地得到一个列表。
与特质一样，在识别组件时，达到何种级别的细致程度是至关重要的。太多的细节除了把人搞晕之外不会再有什么好处，而太少的细节也会导致无物可测。确保一个短小的列表：10看起来不错，20就太多了，除非系统非常大。
3、C代表能力（Capability）
能力是系统的动词，代表着系统在用户指令之下完成的动作。它们是对输入的响应、对查询的应答，以及代表用户完成的活动。事实上，这正是用户选择一个软件的原因所在：他们需要一些功能而你的软件提供了这些功能。
能力处于特质和组件的交点。组件（Component）执行某种功能（function）来满足产品的一个特质（Attribute），这个活动的结果是向用户提供某种能力（capability）。如果你的产品所做的一件事情不属于任何特质和组件的交点，这件事大概也是无关紧要的。
下面是一个例子，展示了一个在线商店具有的能力：
从购物车里增加或删除物品。这是Cart（购物车）组件在满足直观的UI特质时的一个能力。
获得信用卡和验证数据。这是Cart组件在满足便利特质和集成特质时的一个能力。
使用HTTPS处理钱款交易。这是Cart组件在满足安全特质时的一个能力。
基于购物者正在浏览的商品提供建议。这是Search组件在满足便利特质时的一个能力。
计算送货成本。这是UPS集成组件在满足快速和安全特质时的一个能力。
显示剩余库存。这是Search组件在满足便利特质时的一个能力。
推迟购买。这是Cart组件在满足便利特质时的一个能力。
根据关键字、SKU和类目搜索商品。这是Search组件在满足便利和精准特质时的一个能力。
能力一般是面向用户的，表达的是用户眼里系统的行为，往往比特质和组件都要多很多。ACC的前两步遵循简洁原则，而能力则应对描述系统的完整功能，因此基于应用的功能丰富性和复杂性，能力在数量上可以很大。
能力最重要的一个特点是它的可测试性。这是我们用主动语态来表达能力的主要原因。它们是动词，因为我们为了完成某个动作，我们不得不编写测试用例去验证这个能力得到了正确的实现，而用户将因为这个特性而喜欢这个产品。
书写良好的能力需要一些训练。下面是一些能力应该满足的特征：
1、一个能力点应当被表达为一个动作，反映了用户使用被测应用完成一定的活动；
2、一个能力点应当为测试人员提供足够的指导，用以理解在编写测试用例时涉及的变量；
3、一个能力应当与其他能力组合。实际上，一个用户故事或用例可以用一系列能力来描述。如果一个用户故事无法用现有的能力来表达，说明你遗漏了一些能力，或者能力描述的抽象程度太高了。
网友评论