测试沉思录2. 如何保障需求质量（下）：你应该做到的

Posted 2022-11-01 毕小烦

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了测试沉思录2. 如何保障需求质量（下）：你应该做到的相关的知识，希望对你有一定的参考价值。

欢迎订阅我的新专栏《现代命令行工具指南》，精讲目前最流行的开源命令行工具，大大提升你的工作效率。

上一篇文章我们介绍了保障需求质量需要知道的一些基本内容，接下来，我们看保障需求质量的具体措施。

5. 如何保障需求质量？

如何保障需求质量呢？

我们总结为四个要：既要，又要，还要，且要。

既要规避需求的常见问题，又要进行充分的评审，还要保证过程中的风险可控，且要进行度量和持续改进。

具体怎么做呢？

就是最开始我们讲的那 5 个字：防、评、控、量、改

防，是问题预防，这个很好理解，就是预防问题的发生。
评，就是需求评审，主要是进行审核文档和需求评审。
控，是控制风险，要做的就是需求管理，控制需求变更。
量，是指需求工程的质效度量，全程记录，统计分析。
改，是持续改进，用度量结果辅助持续改进。

5.1 防：问题预防

我们先看防，怎么做好问题的预防。

主要是做到 5 个有：**有原则、有规范、有流程、有分工、有标准。 **

有原则可以遵循，有规范可以参考，有流程可以跟着走，有分工大家各司其职，有标准能够衡量结果。

来具体看看。

有原则

团队共同制定一些需求相关的原则，让所有人在这套原则的指导下进行工作。

比如：

原则1：不要着急写需求，要先明确定义问题，找到问题的本质。
原则2：要立即修复需求文档中的错误。
原则3：要记录需求为什么被引入，知道了原始需求的动机，在遇到需求变更时才好确认是否可以安全地变更。
原则4：要评审需求。
原则5：要合理地组织需求，这有助于读者理解系统功能，也有助于需求编写者在需求变更时定位章节。
原则6：要给需求排优先级，并非所有需求都是同样重要。
原则7：需求的书写要简洁。
…

有了这些原则的指导，再来制定规范、流程和标准。

有规范

产品工作是要有规范可以参考的，要让所有人在进行需求相关的工作时，能有据可依，步调统一，减少例外的事情发生。

因此，要用产品规范来约束产品需求的编写、原型设计、视觉设计、交互设计和产品的实现。而开发和测试跟产品相关的规范，则体现在技术分析设计和测试用例的设计上，这是为了对需求的可行性和完整性查漏补缺。

产品规范都包括什么呢？

主要是需求规范、功能规范、原型规范、视觉规范、非功能需求、命名规范等，都是些通用的规则。

有流程

以需求评审为关键节点，我们把需求的流程分为三段：评审前、评审中、评审后。

评审前需要： 产品立项（新项目）→ 产品内审 → 需求预审 → 审阅文档
评审中需要： 认真且充分的评审需求
评审后需要： 需求修订 → 评估工时 → Planning Meeting → 视觉评审 → 技术评审 → 用例评审

在 Planning Meeting 之后，本次迭代的需求就算确定了，这就建立了一个需求基线，后续所有的变更都要走需求变更流程。

需求阶段的流程如下所示：

整个需求阶段的流程大致就是：

项目经理组织 kick off 告诉大家，我们要开始新项目了，讲讲背景，目标啥的，就相当于动员大会。 → 然后产品经理忙着写需求，先产品经理互审，内部达成一致 → 接着跟专家组讨论可行性 → 然后让项目组成员提前熟悉文档（以便评审时有针对性） → 最后也是最重要的就是正式组会评审需求 → 之后回答&修订评审时记录的问题 → 提供 PRD 终稿 → 开发&测试分析估计 → Planning meeting 确定迭代内容和范围 → 视觉/技术/用例评审对需求进行查漏补缺。

有分工

所有角色都要有明确的分工，大家各司其职，要求是，把自己的工作做到最好；

有标准

要制定需求的准入准出标准，也就是质量卡点，来控制需求的质量。

需求评审准入的原则是： 需求文档是完善的，价值是明确的，技术是可行的，拆分是合理的，风险是可控的。
需求评审准出的原则是： 需求文档是经过评审的、最新的、完整的，无歧义的，是可以被拆成任务，可评估，可实现的。

具体标准（略）

5.2 评：需求评审

评审目的

虽然大家都知道为何要需求评审，但很多人被问到「为何要需求评审」时，还是说不清楚，因此，我们先谈谈需求评审的目的。

《软件需求》中说：一些公司每投入 1 小时审查需求文档，可以避免 10 个小时的劳动，1000% 的投资回报率，可不容小觑。

既然投入产出比这么高，那需求评审到底解决了什么问题呢？

① 做什么：需求评审让每个人都清楚的知道自己要做什么。
② 为什么：需求评审指明了团队努力的方向，信念一致才能义无反顾。
③ 要做对：需求评审澄清了需求的内容，是项目成败的关键。
④ 想清楚：需求评审让产品经理想得更清楚，减少无效投入。
⑤ 更完整：需求评审通过不同视角的多方审视，让需求更完整。

评审目标

知道了需求评审的目的，我们再看评审的目标。

要让团队能够：

清楚背景：了解为什么要做；
认同价值：需求的价值能够被有效传递；
明确目标：需求要达成的业务目标是什么，最好能量化；
澄清问题：需求的内容、逻辑、影响；
清楚影响：需求对关联业务的影响，对用户可能造成的影响等；
去除冗余：测试和开发要给出初步可行性和工作量的评估，把不可行的、工作量超大的需求提前砍掉，节省交互和视觉设计的时间。（Planning 时会更细）
保障质量：确保产品需求合理、合规、合法；
关注体验：性能、易用性等；

测试人员：

要知道：谁主导？谁参与？分工是什么？依赖是什么？影响是什么？
要了解：需求的背景、价值、规划和目标；
要搞懂：需求的逻辑、功能和细节；
要关注：评审的流程、进度和结果；
要控制：需求文档的质量、级别分布和需求的变更；
要提出：产品质量方面的问题，包括性能、安全和体验；

评审形式

以什么样的形式进行需求评审呢？

最常见的也就三种形式：

审阅文档： 产品经理提前 1 ~ 2 天，把 PRD 发给项目组成员，以便提前熟悉，带着问题参加评审；
需求评审： 是指需求评审会，一般我们将需求评审就等同于需求评审会，产品经理组会，将项目组成员及跟此项目相关的人员叫在一起，通过产品经理的讲解来对需求进行系统性的评审；这种评审也叫正式评审，是保障需求质量最有效的手段。
三方评审： 产品、开发、测试三方评审，一般用于需求变更的时候，要的，做的和测的人在一起把需求评了，在坐位上就行，站会也行。

这三种形式在不同的阶段进行，也就是评审前，评审中和评审后，审阅文档是对文档的静态检查，需求评审是对 PRD 的讨论澄清，三方评审通常是需求变更时的快速讨论。

评审策略

通用的清单可参考常见问题来制定。

比如：

需求是否有价值？
需求是否可测？
需求拆分的是否合理？
需求是否明确了优先级？分布是否合理？
是否需要性能测试？如果要，具体的性能指标是什么？
是否需要安全测试？
是否涉及埋点需求？
是否对其他业务（依赖你的业务）有影响？
是否对其他业务有依赖？依赖的服务是现成的，还是要同步开发？同步开发的联调和上线时间确认了吗？
是否涉及数据迁移？
是否有降级开关？
是否涉及 AB 测试？
…

5.3 控：控制风险

控制风险主要是管理需求版本、状态和变更，这里主要看变更。

我们从共识、原因、要求、限制、流程、申请、评估、应对这 8 个方面来看。

1/8 共识

团队对于需求变更要有共识。

什么共识呢？

共识1. 敏捷拥抱变化，但要有限制，要有流程（可以变更，但要控制）。需求变更不一定是坏事，事先将所有需求定义好几乎是不可能的。因为，技术在革新，世界在变化，出现新的市场机遇，政策法规变化以及业务需求过时等等。所以，一个高效的团队是能够灵活应对变化的。

共识2. 变更总是有代价的，这个代价团队要能接受。

2/8 原因

要分析引发需求变更的原因是什么？

比如：

需求有疑问
需求有遗漏
需求有错误
实现有问题
需求有重复
需求有变化

3/8 要求

提出需求变更是有要求的，不能随便就提。

比如：

要求1. 提出需求变更前是经过深思熟虑的。
要求2. 审核需求变更要有一个拍板的人。
要求3. 需求变更的信息要通知所有干系人。
要求4. 处理需求变更有一致的变更流程。

4/8 限制

需求变更是要有限制的。

比如：

限制变更的时间窗口，比如，在 Release 之后不允许任何需求变更，除非 CTO 同意。
限制需求变更的频率和范围。比如，一个迭代中变更的需求率不能超过多少，或变更的成本不能超过多少。

5/8 流程

需求变更要有明确的变更流程，要能够以一致且有效的方式来处理需求变更。

比如，下面这个变更的基本流程：

6/8 申请

变更申请非常重要，通常会有一个「变更申请模板」来规范申请。

这个模板要能回答什么项目？谁？因为什么原因，在什么时候申请需求变更？谁开发？谁测试？有风险吗？如果有怎么应对？评估依据是什么？谁评审的？谁最终审核的？

所以对模板的要求，基本是：可评估可追溯可管理

7/8 评估

对变更影响的评估非常重要，它是审批者/干系人来判断是否同意变更的关键因素。

申请和评估的模板可参考下图：

8/8 应对

既然变更在所难免，那作为测试人员应该如何应对变更呢？

这里主要是应对工作量增加的问题，因为所有的风险、影响最终都会化为工作量。

分两种情况来考虑，面对增加的工作量。

如果交付日期不变，则可以考虑：
- 砍：砍掉优先级低的需求，来减少工作量。
- 加：增加人力或部分工作外包，来分摊工作量。
- 降：牺牲部分不重要的质量来保交付，比如只精测优先级高的需求，优先级低的风险低的可以让开发自测，或产品验收测试。
如果交付日期可变，这就简单了：
- 延：延长交付时间。

所以，请记住应对需求变更的四字真言：砍、加、降、延。

5.4 量：质效度量

![image.png](https://img-blog.csdnimg.cn/img_convert/af76038eb78fcb0ff79e7fbf849e3d8c.png
接下来我们看量，也就是度量需求相关的质量和效率，目的是为持续改进提供定性或定量的分析依据。

那，度量什么？

第1个，度量需求影响（也就是需求质量造成的结果），第2个是，度量需求本身（也就是源头），第3 个，度量需求过程。

1. 度量需求影响（结果）

先看度量需求质量造成的影响，通过结果数据来反推源头和过程的问题。

为什么要从结果来反推呢？

因为通过问题来驱动改进，是最有效的方式。

比如：

返工时长：由于需求缺陷或变更造成返工的工作量；
延期次数：由于需求缺陷或变更造成项目或迭代延期的次数；
延期天数：由于需求缺陷或变更造成项目或迭代延期的总天数；

2. 度量需求本身（源头）

这个可以参考前面讲的需求的问题进行度量，用户故事则可以参考 INVEST 原则进行度量。

3. 度量需求过程（过程）

要跟踪需求的整个流转过程（全生命周期），监控需求的流转过程和状态，记录过程中的数据，比如：需求问题的类型，需求相关的耗时等，以便分析影响，还有后续的统计分析。

基本路径是：记录 -> 归类 -> 统计 -> 分析 -> 改进

接下来我们看看如何改进。

5.5 改：持续改进

关于持续改进，我们从改进的目标、原则、路线和方法来讲。

首先

确定：改进的目标

改进的目标肯定是降本增效。

比如：

减少因需求错误而导致的返工：
1. 统计在迭代周期的各阶段，因需求问题（错误、遗漏…）造成返工的时长。（需求错误造成的成本浪费）
  2. 统计设定基线之后发现的需求问题占比。（评审不充分）
减少开发过程中澄清需求所花的时间：
1. 统计设定基线之后，需求的疑问和争议数量。
  2. 统计解决每个疑问和争议所花的时间。

对于选择哪些指标，我们可以遵循一种简单的思考方式：目标 - 问题 - 指标（GQM：Goal-Question-Metric），首先写出改进目标，然后判断团队达成目标必须解决的问题是什么，最后，确定能够为每个问题提供答案的指标。

这些指标能够作为关键绩效指标。

比如：