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

欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织-测试团队的敏捷转型》已出版（机械工业出版社），各大电商平台热销中，30万字350页，“阅读原文”有官方购买链接。

验收测试是质量左移的利器，也是团队各角色对需求形成共识的“语言”。遗憾的是大多数团队没有好好利用这个武器，仅仅把验收测试当成P0用例，在流程最后才使用。

需求评审前给出验收测试点

在产品经理组织需求评审会之前，我们是否就可以对需求定义的概念进行“逻辑测试”？

我们可以提前和产品经理沟通需求规格文档，提出修改意见，或者抛出有针对性的验收测试点请对方确认。如图：测试和产品在特性需求评审前的讨论流程。

在需求评审会议上，我们也许可以一边看着需求规格说明，一边看着需求对应的验收测试点，甚至列出了包括历史上真实发生过的关联缺陷！这个时候，开发还没有开始思考如何实现呢！如下图所示，是需求和验收测试的二合一表格示范，以方便团队在需求评审时，同步核对质量风险和验收测试点，提高评审效率。

这种创新措施的好处就是，开发把测试要验证的关键场景早早地记在脑里，再交付时几乎不会出现对于测试人员而言很低级的质量问题。

需要说明的是，测试提前梳理的这些测试点，可以经过产品确认后成为用户验收测试用例（UAT），也可以细化为（方便开发自测的）普通验收用例（AT）。验收测试的基本介绍在这里：聊聊用户故事与测试启发。

在聊聊Scrum三大角色的质量意识和文化建设提到过，敏捷研发团队针对需求评审完成条件可以设置准入门槛，定义为DoR（Definition of Readiness），这也是团队共同遵守的纪律。DoR中通常都会要求用户故事的“验收测试用例”必须由团队确认完成。一旦验收测试用例成为团队各个环节的“交付共同语言”，将极大地推动各个角色从一开始就重视质量，并且清楚自己的工作是如何对齐质量要求的，避免不同角色对于需求质量的理解差异太大。

在需求讨论中，不同角色自以为“理解”了需求，实际上想的可能并不一致。

下图展示了在迭代的各个环节，验收测试用例作为共同语言贯穿全流程。

需求评审的质量把关

首先要明确，需求的设计质量并不是只由产品经理负责，特性团队的每个成员都可以对需求设计的高质量负责。很难有人能够通过市场、用户和技术等方面的全盘思考，拿出一个高品质的产品设计方案。团队需要群策群力，帮助产品责任人快速提升需求设计的质量水平，并且定义达成足够水平的文档质量标准。

敏捷团队不追求文档的详尽，而是要求定义清楚边界和风险。具体纳入哪些“必填内容”，可以由一线团队根据自己业务特性和规模来定制纪律，例如针对初期上市产品，需求评审更关注主打什么功能，而不是缺失什么功能。

以下是本文推荐的需求文档质量把关项：

1）需求的上线背景和商业目标是否明确？需求的来源和交付日期是否明确？

2）如何评估本需求带来的商业价值？上线应关注的产品健康度指标有哪些，期待值范围是多少？

3）针对本需求的市场分析和竞品分析（可选）。如果需求规格复杂，需要提供业务逻辑图。

4）本需求在哪个主体上实现，它的上下游是谁？本需求对上下游主体有什么影响，交互逻辑是什么？本需求的成功上线依赖哪些服务，具体依赖关系如何？

5）本需求是否涉及性能变化，稳定性风险或者资金安全风险？如果是，请给出详细分析（可请开发人员给出）？

6）所有需求的优先级是否明确且唯一？

7）本需求的上线策略是怎样的？

最后，除了上文提到的，把“完成验收测试用例”这一条纪律纳入DoR，我们还可以把其他有利于需求质量提升的好纪律都纳入DoR，让团队共同为需求的精益化负责。DoR全部完成，才意味着需求评审阶段全面完成，可以进入开发设计环节。下图是一个团队设计的完整DoR例子。

我们可以用这两个度量指标来牵引团队在需求评审和验收测试的效果产出：

验收测试覆盖率：评审需求中，有多少比例的需求有给出明确的验收测试用例？

需求前置缺陷数（建议数）：有多少设计缺陷（建议）在需求评审中被提出，并接受（修改需求文档）？

俗话说“磨刀不误砍柴工”，澄清需求过程中多一些思考碰撞，未来构建产品质量的成本就会低很多倍。

UAT（用户验收测试）效果保障的关键

UAT该怎么做？

在行业公司的实践中，UAT通常是产品发布前的最后一道关卡，让最终用户通过验收测试，确认产品能否满足需求，同时让产研团队得到有价值的反馈，明确后面的改进方向。最终用户应该是本产品典型的真实使用者，也是合同交付的支付方（如有）。

如果我们无法引入真实的用户参与UAT，我们应该模拟用户来完成测试（小心，假扮用户并不容易）。我们需要识别不同用户的类型和角色，并在UAT中覆盖这些角色：即“角色扮演探索测试法”，思考这类用户最看重什么，会如何行动。

下面是James Bach在《HTSM-启发式测试策略模型》对UAT的定义：

在很多公司，UAT的成本是非常高的，因为要引入业务方代表或者真实用户进行测试，如果收益效果达不到预期，就会怨声载道，阻碍产品交付市场的时间。

对于产研部门在国内的海外业务而言，UAT更是非常重要但耗时耗力的过程，国外UAT人员确实能发现不少海外市场独有的问题，但时差、语言、网络环境、跨国沟通和产品熟悉程度，都成为阻碍UAT的拦路虎。

从产研团队的视角，收集用户对产品的反馈方式有多种，其优缺点各不相同，如：

第一种，用研当面访谈。优点是可以直接观察用户表情和真实使用状态，感受用户的心声。缺点就是成本很高，预约一个用户的花费不菲，访谈设计和分析的专家成本很高，不可能应用于大量需求或大量用户的调研。

第二种，产品AB测试。通过一定的用户流量导入，在两种不同的界面观察用户的选择，看看那种界面转化率更高。这个方式优点是实现成本低（需要先有一个AB实验平台），结论可量化，放心。缺点是AB设计场景有限，需要设计者有一定的敏锐洞察，也无法拿到用户真实的心声描述。

第三种，产品灰度+自动反馈搜集。通过灰度放量，以及强大的反馈入口（埋点系统和APP反馈框），快速搜集大量用户的试用意见和数据。优点是成本低，技术成熟，能搜集到用户的行为大数据，避免风险事故蔓延。缺点是依然有线上风险可能，且大量反馈数据是极低价值的，处理效率低。

第四种，产品Showcase，给用户或业务代表完整演示待发布功能。优点是耗时少，反馈简单直接。缺点是组织成本略高，用户仅仅单向反馈意见，没有充分试用，容易掩盖各种问题。

和上面几种反馈方式对比，UAT的优点是能集中搜集一批真实用户的详细反馈意见，确认需求上线前无明显遗漏问题。缺点是会延长全量发布时间，组织UAT的成本高，反馈问题的含金量通常有限。

如果不能打造高效率的UAT，就难以达成产研侧和业务侧同时满意的效果。

高效UAT的组织纪律

一个可持续的高效UAT机制，重点是形成几个关键纪律：

1 选择哪些产品需求发布一定要做UAT，那些发布不用做UAT。

鼎叔的观点是：从0到1的核心产品版本，交互界面变化巨大的卖点内容，涉及客户操作流程巨大变化的需求，涉及大额资金的营销活动需求等，以及其他安全/经营高风险的需求，应该做UAT。

其他的需求发布，如日常迭代的稳定期产品需求，难以从用户视角观察到的需求，健康度监控完善的产品，不需要做UAT。

2 明确UAT通过标准。

因为UAT需要用户代表（业务方）确认通过，为了不影响发布节奏，我们要明确不通过的红线，如基本业务逻辑不通过，阻塞型缺陷，涉及舆情公关的安全/合规缺陷等。

互联网产品讲究小步快跑和试错，因此对于非红线的普通缺陷或体验问题，产品负责人应该作为是否在发布前修复的决策人。

业务方（用户代表）应该在需求讨论阶段可以就看到需求文档，并对上线功能范围进行确认，甚至有机会参与迭代版本的演示。这样可以提前反馈意见，避免到了UAT阶段再提出新需求。

3 对参与UAT人员的要求。

为了提高UAT执行效率，UAT团队如果不是由最终用户组成，则应该尽量稳定，有一部分人能熟练使用产品，如果能提前阅读需求文档/操作手册更好。

UAT团队应在规定时间内反馈问题。从探索式测试的组织经验来看，把团队集中在现场，进行有奖比赛式的UAT是效率最高的。正如聊聊集体缺陷大扫除所说，计划好的验收测试用例只是底线，我们更鼓励UAT人员尽量大胆地探索产品问题。

现场应该有一位UAT组织者，负责介绍流程，维护纪律，控制时间，拉通产研和业务双方就分歧快速达成一致，缩短反馈处理周期，这样执行效率会高很多。

4 技术保障效率。

考虑到UAT执行的高成本，技术侧应该在UAT执行前准备好测试环境，测试账号/数据，技术答疑指南，并提供高质量的UAT待测版本。因为这个阶段已经临近发布了，版本内部测试应该很充分了，已有端到端的质量保障。