聊聊测试左移到需求阶段

这是鼎叔的第七十九篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》,星标收藏,大量原创思考文章陆续推出。本人新书《无测试组织-测试团队的敏捷转型》​​​​​​​已出版(机械工业出版社),各大电商平台热销中,30万字350页。

测试左移是多年来测试行业的热门话题,在实际的践行中容易停留在“意识流”层面,仅仅是鼓励测试人员应该“主动做什么”,然而在业务压力大的常态下,被鼓励的尝试往往无疾而终。只有基于敏捷理念的理解,对研发生命周期各个环节进行质量内建实践,才能把测试左移落实成好习惯,形成好流程,最终内化为敏捷团队的本能。

具体而言,测试左移,可以移动到需求澄清阶段,也可以移动到开发设计、编码和开发自测阶段。

而测试右看,是指当研发阶段的测试活动结束,产品进入发布上线阶段时,测试人员依然不能放松对质量数据和用户反馈的敏锐度,持续汲取下个迭代如何改进的反馈,形成滚动提升的飞轮。

测试左移和右看》这个专辑,将基于多年来的测试团队实践,分享在测试左移和右看活动中的推荐做法和有效经验,它们也是敏捷理念在测试活动中的落实,在整个软件生命周期中持续性测试。

为什么要左移到需求阶段

敏捷测试的本质是尽早测试,频繁测试,推动质量从源头内建。

而产品研发的源头,自然是需求产生及澄清阶段。精益需求的产生过程,就是测试左移最早可以发力的地方。

如果我们忽视在需求阶段的测试左移活动,仅依靠软件工程层面的效能提升,始终会存在部分本质矛盾难以解决的情况。需求质量难以提升,那么很容易给技术团队带来频繁的返工和浪费。测试左移到需求的本质,就是从一开始尽量提高需求的可测试性。

基于敏捷知识,先从精益需求的产生过程进行介绍。相关内容请参考 聊聊精益需求的产生过程

一个软件产品需求的产生流程可以简单分为这几个阶段,最终将形成价值验证的闭环。

聊聊测试左移到需求阶段_第1张图片

制定业务目标:确定产品的愿景,商业机会,和核心价值(包含产品定位的差异化策略等),并确定目标群体。以此为蓝图制定本年度的商业发展目标,包含量化指标。

梳理用户(或客户)需求:通过多种调查方式,如用户访谈,用户画像,用户调查问卷等,完成相关的定性定量分析,挖掘出用户真正需要满足的诉求,即定义好产品的“问题域”。在此阶段可以将梳理完成的用户需求写成BRD(商业需求文档)。

产品设计方案:在产品核心目标和定位的基础上,根据用户的本质诉求,形成完整的产品设计创意思路,最终给出可落地的产品设计方案,即梳理出产品的“解决域”。所谓可落地就是成本,时间,技术能力等限制条件都可以满足。这个阶段就可以开始输出PRD(产品需求文档)了。

拆解单个功能需求及用户故事:根据产品设计方案,对产品能力需求进行梳理和优先级排序,整理出具体的需求描述,然后进一步识别/拆解为可开发的用户故事。

需求评审会议:完成了上述的需求定义过程,产品负责人组织需求评审会议,和技术团队以及其他项目干系人澄清产品方案,分享需求背景知识,需求定义和优先级。团队估算工作量,确认交付计划(包括重要发布计划和短期迭代计划)。

测试人员如何提升需求质量

以上就是常见的需求产生及澄清过程,期间并非只由产品人员唱独角戏。在这些阶段中可以进行上一个专辑介绍的多种敏捷测试实践活动 聊聊团队如何开始敏捷转型(合辑共15篇)。我们测试同学可以从下面几个方面进行质量把关,并输出专业意见,帮助产品经理和特性团队,在进入开发环节之前提升需求质量。

1)明确需求价值。

2)完善用户画像和用户故事场景。

3)需求评审前给出验收测试点,帮助团队建立需求验收标准。

4)迭代计划会议确保需求拆解合理,测试任务纳入估算。

5)需求评审中把关质量,并明确DoR纪律。

这篇文章重点说说测试人员如何实践前两方面的活动。

明确需求价值

首先,需要向业务方或产品经理获得背景知识,为什么我们要上这个需求?

第一,不做这个需求有什么损失?用户对我们这个需求有多期待?有没有具体反馈声音可以让我们学习?这对于测试场景的思考有极大好处。

第二,这个需求对公司有什么好处?提高满意度口碑,还是能提高收入?有利于我们未来盈利么?新需求是否匹配产品的“调性”(定位),它是否有利于产品长期目标的达成?

能提高用户口碑,或者提高利润的功能,自然是我们着力要保障的高优先级需求。

知道了业务价值是什么,成功的方向是什么,就能更充分地调动项目参与工程师的积极性。

其次,如何客观度量产品特性上线后带来了预期的价值?

虽然产品负责人对产品设计的价值(或商业变现目标)负责,但是产品价值是体现在具体指标的,和用户场景息息相关。测试人员知道了商业上的度量指标定义和目标,就能更加关注要验收的核心场景。

另外,对于预期价值的思考及信息同步,也给了产品负责人以终为始的压力。产品需求绝不是越多越好,甚至有可能新功能上线越多,用户流失越快。把产品预期价值和背后的逻辑晾晒给技术团队看,既可以推动产品设计更加深思熟虑,也可以获得技术人员宝贵的早期意见输入。

再次,多挖掘本产品相关的竞品信息和行业信息。

看竞品。本产品的竞争对手为用户提供了哪些相似能力的解决方案?他们和本产品的说明书差异是什么?实现方案有啥不同(哪个感觉更靠谱)?测试人员从中可思考什么场景、什么指标可以用来做竞品对比。

看行业(本领域)。本产品所在的细分领域,有什么规范/默认潜规则,是本产品(需求)应该顾忌的?本领域是否有约定俗成的产品形态/交互风格,让用户早已养成习惯?这背后有什么博弈故事么?理解约定俗成的法律、规范、强大习惯,就可以让测试断言(是否有效缺陷,严重程度如何)更有底气,降低争论成本。

最后,当需求功能上线一段时间后,敏捷特性团队通常应该复盘上线的结果,确认具体商业价值指标是否达成预期,产品设计方案是否达到预期,还可以针对上线的具体特性功能,观察用户使用健康度(通过数据埋点)是否达到设计预期。

如果没有达到预期,产品团队要思考背后缺失了什么,以此来调整后面的设计方案和需求安排。

完善用户画像和用户故事场景

测试人员同产品经理一道,梳理用户画像并给出自己的看法,再根据目标用户的特征和视角,针对性地调整测试优先级和覆盖场景。

首先,我们可以挖掘下,目标用户是从哪些维度来划分的?

一是从人口学特征划分,包括年龄,性别,地域,人体特征(如左撇子,手型大小,视力情况等等)。

二是从使用习惯和经验划分,如新手用户和老手用户,强目的性用户(专找秒杀,或用完即走)和漫游型用户(随便看看)。从中我们总结出用户的痛点和对产品的期待。

三是从文化背景/社会背景划分,识别用户的特征,如城市白领,小镇居民,乡村农民;如高级知识分子和中学文凭的工人;如中国大陆用户和东南亚用户等。对于测试人员不熟悉的社会文化背景,比如海外市场产品,有必要认真学习当地社会和文化知识,甚至出差去该国家走访,体验典型用户所处的生活氛围。

四是从平台角度来划分,是公司外部用户还是公司内部用户(如管理员)。

理解了被划分的主要用户类型,我们可以在脑海里尝试给每种类型创造一个生动的典型人物,起一个名字,如电商产品的用户——张小婷,想象她具备上述哪一种个性特征,如果她给我们产品的各个功能进行满意度打分,会打几分?标准是什么?她会用什么关键词来表达情绪?

当然,我们也可以从客服“用户之声”详细原声访谈中,或者从产品经理做用户调研的定性分析和定量分析中,寻找生动的典型用户形象、使用习惯和评价尺度。

至于如何完整梳理产品的用户故事场景,我们可以学习和实践用户故事地图的脑爆和设计方法(待下回分解)。而用户故事的具体概念和估算&拆解实践,请参考:聊聊用户故事与测试启发,聊聊用户故事的估算和拆解

你可能感兴趣的:(敏捷测试转型,精益工程,敏捷流程)