测试管理 如何保障需求质量(上):你应该知道的

TesterHome小助手 · 2022年04月29日 · 最后由 路闲 回复于 2022年05月17日 · 3274 次阅读

作者 | 毕小烦

引言:每个测试人员都知道保障需求质量非常重要,那到底为什么这么重要?又如何来保障需求质量呢?如果要回答好这些问题,必须得了解需求是什么,从哪里来到哪里去,只有搞清楚需求的来龙去脉和常见的问题,我们才能够制定出合理的保障措施。本文从测试的视角梳理了保障需求质量需要了解的方方面面。

如何保障需求质量?

关于这个问题,用 5 个字总结就是:防、评、控、量、改。


什么意思?

光看这 5 个字当然看不懂,我们也没办法用一句话就讲清楚如何保障需求质量,但为了能讲清楚,我们得知道需求的来龙去脉,知道需求是什么,从哪来,到哪去,过程中会经历什么,哪些会出现问题,哪些会隐藏风险,我们要重点关注什么。

正式开始。

1. 为何要保障需求质量?

我们所有人都在说保障需求质量非常重要,都在说我们的测试工作要提前,要左移,要在需求阶段进行严格的质量控制。

那大家有没有想过,为何需求质量这么重要?

一句话总结就是:需求是最有价值的质量控制点。

为什么这么说呢?

可以从三个方面来回答。

1. 需求是源头:没有需求研发都不用做了

首先是因为,需求是所有研发工作的源头,如果做一件事情,从源头就错了,那后果可想而知。

质量管理专家 林雪萍 老师对质量有个观点:

质量控制是环环相扣的体系,从上游的产品设计阶段,到中游的研发阶段,再到下游的发布阶段,每个环节创造的价值是在不断下降的。

对质量管理来说,价值最高的就是上游,产品的设计决定了产品的基本质量和可靠性水平。如果产品设计本身不过硬,那么,下游生产现场的工程师和工人再怎么努力、再具有工匠精神,顶多只能在车间有一些有限的补救,无法改变产品本身的先天缺陷。

这就好像拍一部电影,用了一流的演员、最棒的摄影师和最贵的服装化妆道具,但剧本本身漏洞百出、满是槽点,那么无论演员多么卖力演出,也很难扭转局面。

这个观点放到互联网产品研发中也同样适用。

从华为的 IPD 产品研发流程中也能看得比较清楚,需求从客户中来,通过需求管理,经过产品研发流程,最后再到客户中去,如此循环。如果对客户的需求理解错了,那后续的所有工作可能都是徒劳。

虽然软件产品到了下游可以进行需求变更,但变更带来的成本浪费是巨大的。

2. 需求是核心:所有工作都围绕需求展开

在研发过程中,需求属于核心位置,所有工作都围绕需求展开。
下面这张图展示了需求与其他工作过程的关系:

由此可见,需求的质量直接影响着其他工作的结果和质量。

所以需求是源头也是核心。

3. 需求是成本:需求是控制成本的关键

除此之外,需求也意味着成本。

《软件开发的 201 个原则》中有一条原则说:要立即修复需求规格说明中的错误。

为什么呢?

《探索需求》这本书里也给出了一组数据,说明了在需求阶段引入的错误,给后续阶段发现和修复所带来的成本情况。

如下所示:

发现错误的阶段 成本倍数
需求阶段 1
设计阶段 3~6
编码阶段 10
开发自测阶段 15 ~ 40
测试阶段 30 ~ 70
运营阶段 40 ~ 1000

所以,严格控制需求质量,保障高质量的产品需求,是控制整体研发成本最有效的手段,也是产品取得成功的关键。

2. 什么是需求?它从哪来到哪去?

2.1 需求定义

「需求」这个词在我们的日常工作中出现的频率特别高,像市场需求、业务需求、用户需求、技术需求等等,到处都是需求。

那到底什么是「需求」?

「需求」这个词拆开就是「需要」和「要求」,中文的解释是:由需要而产生的要求。

所以我们可以简单理解为,市场需求就是由市场需要而产生的要求。用户需求就是由用户需要而产生的要求。依此类推。

有个叫布莱恩·劳伦斯(Brian Lawrence)的职业规划顾问,对需求做了一个定义,他说:「需求是任何能驱动设计做出选择的东西。」

换句话说,你的商业设计,产品设计,服务设计等等都是由需求来驱动的,区别在于需求方(提出需求的人)不同。

图片

《软件需求》的作者说:「需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性,可以是一种对系统开发进程的约束。」

这里所说的需求当然是指「软件需求」了,它说需求是多种不同类型的信息的统称。这些信息包括了客户视角的外部系统行为(客户需求)以及来自开发人员视角的一些内部特征(功能需求)。包括了系统在特定条件下的行为和属性,使目标用户觉得系统易于甚至乐于上手(用户体验)等等。

所以,软件需求不是某个人或某个角色的诉求,而是多方干系人的诉求,是多种信息聚合,分析、平衡的结果。

2.2 需求工程

需求是怎么从一个想法变成一个产品功能的呢?

这就要看需求工程了。

需求的开发也是一个迭代的过程,是一个逐步完善的过程,我们很难在刚开始就把所有可能的情况都想清楚,信息的准确性和全面性以及产品经理的能力、经验、视角、思维局限都会影响需求质量。

那,需求的开发过程是什么呢?

一般是:获取 → 分析 → 规范 → 确认 → 实现 → 验证

如下所示:

从商业需求、市场需求、业务需求、用户调研、竞品分析等方面获取需求 → 理解以后进行归类,并与软件需求联系起来 → 再编写产品需求文档,用一致的、可存取、可评审的方式记录不同类型的需求 → 然后召开需求评审会通过多方视角确认需求 → 之后就是视觉&交互设计,系统分析设计,测试分析设计去细化需求,再通过编码去实现需求 → 最后是验证需求的完成情况

每个阶段都是不断细化和完善的过程。

2.3 需求来源

正所谓无需求不产品,产品需求是从哪里来的呢?

基本流程如下图所示:

3. 需求是怎么写出来的?

描述需求要写文档,但说到文档,我们常听说的有三种:BRD、MRD、PRD,分别是:商业需求文档、市场需求文档和产品需求文档

BRD -> MRD -> PRD 是一个从高到低的逐层递进的关系,BRD 从战略高度告诉我们做什么产品,MRD 从战术的角度告诉我们怎么做,PRD 非常细化的告诉我们做成什么样。

而我们测试人员最关注的则是 PRD。

PRD 涉及的信息要素主要有版本记录、需求分析、需求设计、全局说明、原型设计等,一般是用 Word + 原型图(Axure/墨刀/Figama)来写。

怎么判断 PRD 写的好还是不好呢?

其实,PRD 的好坏不在于好不好看,而是信息传递的完整性和准确性,可以让一个完全没有接触过这款产品的人看了也能了解清楚。

敏捷项目

敏捷项目中使用产品待办列表(product backlog)来组织管理需求,是由 Product Owner 负责制定的一个按照重要性的级别排序的用户故事列表。

这个产品待办列表会用一些平台来管理,比如 JIRA、禅道等,然后分配到特定的迭代中实现,在迭代得以进一步澄清。

用户故事是什么?
用户故事是敏捷方法的一部分,它是从客户的角度出发,对功能的简短描述。

用户故事描述的是:
作为某个用户类型,我想要做一些事情,以便达成一些目标。

比如,作为一位有品味的中年大叔,我想个性化设定自己的微信头像,以便能够彰显个性。

如何对故事进行分级管理呢?
按工作量从大到小排序应该是:主题 > 史诗 > 特性 > 用户故事 > 任务。

简单点讲,用户故事(Story)是故事的最小单位,用来描述用户需求。而大的故事就是史诗(Epic),比史诗更具象的或多个故事的集合就是特性(Feature),按类别区分的大故事就是主题(Theme)。

用户故事(Story)用来描述需求,而任务(Task)是从用户故事中拆出来的具体的开发任务。

不同级别的故事所需的时间如下图所示:

很多人可能搞不清楚用户故事和需求文档之间的关系,可能会有这样的疑问:用户故事可以代替需求文档吗?

虽然我们可以将产品待办列表视为传统项目需求文档的替代品,但用户故事的描述是不完整的,它就是一句话需求,你没有办法拿这一句话去设计和开发。

通常比较好的做法是将「用户故事」作为实际需求的参考,在 PRD 中去细化它,添加原型图、逻辑图和实例化等。

如下图所示:

这里有一个实例化需求的概念,实例化需求的英文是 Specification by Example,简称 SBE,直译过来就是用实例说明需求。

为避免需求沟通过程中的「知识诅咒」,“实例化需求” 方法从场景出发,以用户的操作实例来澄清需求。

相比一般的规格说明,实例更加场景化,能够激发参与和深度讨论;同时,实例是具体的,其典型形式是:「在什么情况下,做什么操作,会得到什么结果」。基于具体的实例,更加便于沟通中的双向确认,保证理解的一致和场景覆盖。

如下图所示:

4. 常见的需求问题

关于常见问题,我们从理解、表达、体验、可行、管理这 5 个方面来看,对应的问题就是:理解不对、表达不准、体验不好、可能不行、管理不好。

高质量的需求正好是常见问题的反面:

共收到 4 条回复 时间 点赞

都在说左移,可能连需求质量是啥都不知道?建议读下。

测试同学都应该学习下。

管理不好这个,有啥好工具建议么?

现在测试用例通过平台编辑历史可以跟踪、代码通过 git 可以跟踪,唯独需求啥时候变、变了啥没有合适工具去跟踪。经常需求评审的时候需求质量还不错,后面实际开发时有些需求会进一步补充或者微调,就会因为管理不好出各种问题。

confluence 可以管理

confluence 也是不行的,需求需要多方驱动的,在于产品这边需要形成良好的行为规范,需求变动进行记录并通知多方

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册