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

欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》​​​​​​​​​​​​​​已出版（机械工业出版社），各大电商平台热销中，30 万字 350 页。https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484406&idx=1&sn=a212bc2097183b808f80799f63879078&chksm=c24fb694f5383f821b65703f247ab66da22369e60b952f146f3e0bf6c6bb9e7d93bb0a60c45c&token=1118927019&lang=zh_CN#rd

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

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

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

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

为什么要左移到需求阶段

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

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

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

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

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

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

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

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

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

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

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

以上就是常见的需求产生及澄清过程，期间并非只由产品人员唱独角戏。在这些阶段中可以进行上一个专辑介绍的多种敏捷测试实践活动 聊聊团队如何开始敏捷转型（合辑共 15 篇）https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484346&idx=1&sn=479db5fece61937437a598c50565c886&chksm=c24fb6d8f5383fce28074877b5faa74b14b152093e656c007c6394a4b76b344a770a99480df8&scene=21#wechat_redirect。我们测试同学可以从下面几个方面进行质量把关，并输出专业意见，帮助产品经理和特性团队，在进入开发环节之前提升需求质量。

1）明确需求价值。

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

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

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

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

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

明确需求价值

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四是从平台角度来划分，是公司外部用户还是公司内部用户（如管理员）。

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

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

至于如何完整梳理产品的用户故事场景，我们可以学习和实践用户故事地图的脑爆和设计方法（待下回分解）。而用户故事的具体概念和估算&拆解实践，请参考：聊聊用户故事与测试启发，聊聊用户故事的估算和拆解 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484290&idx=1&sn=f6d6a09e3ede91a85b5e346f1e0a812d&chksm=c24fb6e0f5383ff68d1e0b27fd0d9119d456897178e5f27d1af9f14b57644055b0b1d8390867&scene=21#wechat_redirect