测试左移：需求相关的质量保障

本文字数：2597 字

阅读时间：8 分钟

测试左移的由来

缺陷的修复成本逐步升高

内文的标题设计有两款，一款是细线搭配粗线的设计；另一款是同样的细线搭配“空心的粗线”。这两款线的设计都可以运用XX的布局，可嵌套和可设置单边边框这两个特性就能做出来。本段文字是Bug，请从下段开始阅读。

下面是质量领域司空见惯的一张图，看图说话，容易得出：大部分缺陷都是早期引入的，同时大部分缺陷都是中晚期发现的，而缺陷发现的越晚，其修复成本就越高。因此，为了降低缺陷修复成本，我们期望在更早的时间发现缺陷。

那么上图是否完全没问题呢？不是的，这张图来源于1996年的一本书《Applied Software Measurement》，这张图画成的时候，敏捷宣言还没诞生呢（敏捷宣言诞生于2001年）。在传统背景下，需求是明确且相对固定的，需求产生的缺陷可以忽略不计。同时，在需求阶段产生的问题可能会引起整体方案的返工，因此，需求产生的问题不太会以软件缺陷的形式来体现。

需求质量呼唤测试左移

随着软件生态的发展，软件需求越来越复杂多变，需求的有效性和传递效率也备受挑战。受大环境影响，需求阶段引入的缺陷就对软件的研发成本造成了影响。同时，软件的研发过程越来越成为一个需要高效协作的整体，各角色之间的界限也变得相对模糊。

为了让质量理念更早的介入软件研发过程，也为了降低缺陷修复的成本、减少不必要的返工，需求的质量变得尤为重要。测试左移因此而生，需求分析人员与测试人员需要协同工作，共同保证需求的质量。

加上需求阶段重画一下上面的图，理想情况下，我们容易得出以下结论：

1. 缺陷的引入从需求阶段就开始持续，到研发阶段达到峰值，然后趋于平缓
   

2. 缺陷从需求阶段就开始陆续被发现，到测试阶段达到峰值，然后趋于平缓
   

3. 从需求阶段到研发初期，缺陷修复的成本极低
   

4. 开发后期到上线，缺陷修复成本一路攀升至高点
   

5. 缺陷发现的数量少于引入的数量，但在上线前后，缺陷发现数量大于引入数量

因此，为了获得更经济的资源投入产出比，我们认为应该在需求阶段和编码初期更多的发现缺陷，从而减少修复成本和返工，这也正是测试左移的价值所在。

那么，该如何保证需求的质量呢？我们在不同的时期面临的需求，其形态是有差异的，所以需要深刻理解这些差异，并有针对性的设计质量活动加以验证。

需求的三个层次

一个很现实的例子

一天，大老板说：“微信小程序不错，我们内部OA流程得做一个，你们安排一下，年内发布就行。” 这就是一个来自大老板的一句话需求。

项目经理拿到这个需求，看到“年内发布”，需求管理看板上就可以多一张卡，只有几个字“OA小程序”，排期可能暂时安排在第三季度。

过了俩月，送走了一批艰难的需求，暂时松口气的项目经理扫到这张卡，瞬间头皮发麻，这还有一个老板亲生的大坑呢，得尽快填上。喊来产品经理，快出一版方案，再找技术经理大致估一下工作量。

只有一句话显然是没法出方案的，产品经理和技术经理各自焦头烂额的研究了两天，又花了半天暂时碰出了OA小程序的初版方案。一周后，方案通过评审。这时，根据既定方案，产品经理细化了一些需求：用户管理，组织管理，流程管理，表单配置，权限配置，审批配置，微信登录等。

即将进入研发阶段，需求又会被再次细化。以用户提交请假单的场景为例，需求可被细化如下图。进入研发后，开发以一定的优先级顺序来领取需求进行研发。

需求的三种粒度

在上面的故事中，为了服务产品规划和不同的管理诉求，需求呈现出以下三个粒度：

史诗故事 > 特性故事 > 用户故事

1. 史诗故事 Epic：粗粒度的描述需求，通常需要多个迭代才能完成，主要用于版本规划时记录和跟踪该功能

2. 特性故事 Feature：也叫主题故事，是一系列相同主题用户故事的集合，主要用于迭代规划、优先级排序和整体估算

3. 用户故事 Story：迭代开发的最小单元，是细粒度的需求描述，主要用于迭代交付过程中的估算、跟踪和管理

不同粒度的需求保障

史诗故事：方案验证 & 测试设计

在产品演进过程中，当面临的需求还是一句话时，测试人员能做的事情并不多。当史诗故事即将进入迭代规划，进行方案设计时，测试人员就可以参与进来了。

方案成型初期，测试人员可以参与方案讨论和技术可行性研究，贡献既有业务流程或潜在业务逻辑，针对有较大质量风险的方案，测试人员有责任提出质疑，并给出建议。

方案确定后，测试人员就可以着手进行测试设计了，测试设计包括但不限于：针对该功能的质量预期，大致的测试规划，现有的测试资源评估，主要的质量风险及响应方式等。

特性故事：需求评审 & 测试计划

临近迭代，需求会以特性的形式体现，此时测试人员可以参与需求评审：

1. 针对功能需求，测试人员先验证需求是否有效，包括需求价值确认，需求涉及场景是否完备，与现有业务逻辑是否有冲突
   

2. 针对功能需求背后的支撑性需求进行澄清，确认支撑性需求的范围、验收标准、测试方式等；此外还需要考虑用户体验
   

3. 考虑需求的拆分是否合理，是否便于估算和迭代管理
   

质量活动方面，测试人员可以落实测试计划了，如各种测试活动的安排，测试效果的评价，测试的重点和难点，测试阶段的输入和输出等，在这个阶段都可以确认了。

用户故事：需求验收 & 测试执行

故事启动时，测试人员需要补充需求验收的用例，以及需求影响范围内的回归用例等。在这以后测试人员主要关注在需求验收和测试执行上，按照测试设计和计划进行测试，确保最终的实现质量。而在此阶段，测试人员尤其需要关注投入产出比，把有限的精力用在刀刃上。行之有效的做法是在测试计划阶段就明确好各功能的质量标准和资源投入，并在测试执行阶段时刻回顾。但计划是死的，人是活的，万一在测试过程中，我们发现计划赶不上变化，就需要随时跟团队沟通并进行灵活调整了。

当然，质量活动并不是以功能测完上线为结束，而是需要完成一个完整的闭环。测试阶段以后的质量活动不在本文讨论的范围内，在此就不做过多展开了。

# 小结

测试左移之所以重要，是因为我们要在缺陷引入的最初阶段就发现它，把缺陷扼杀在摇篮里，而不是等着它像雪球一样越滚越大。而这里的误区在于，测试左移要求的是测试活动尽早介入，而不仅仅是把测试人员进行左移。因此，团队里的每个成员，都需要有测试左移的思想，都可以从一开始就绷紧质量这根弦，确保每个人的工件质量。

而在需求的质量保证活动中，测试人员也需要时不时换帽子，有时可能是终端用户，有时可能是产品经理，也有时可能是产品负责人。不管戴什么帽子，保证各个工件的质量，以及各工件的顺畅集成，都是测试人员可以关注的事。质量相关，我们责无旁贷。

文章来自网络