聊聊“产品验收”

产品的每个迭代周期发布之前，都会有一个“验收”环节，针对不同的产品管理/项目管理模式，产品验收的过程会略有差异。

但作为一个从“设计”到看见“实物”的时刻，仍然需要产品团队把好最后一关。

作为测试入行的我，这些年也经历了很多验收测试，如果团队真的能够重视验收测试，并将其标准化、规范化，能识别很多潜在风险，也能让原本80分的系统快速提升为90分。

所以，今天就来聊一聊我理解的产品验收测试。

一、验收测试的阶段

从标准的项目管理过程来看，一个项目自立项开始，基本可以分为：需求阶段、设计阶段、开发阶段、测试阶段、上线及试运行阶段。

而测试阶段可以分为：单元测试（有些团队会归到开发阶段）、冒烟测试、SIT测试（系统集成测试）、UAT测试（用户/产品验收测试）。

自研类产品，验收测试一般会由产品团队主导，而项目制的产品，验收测试一般由甲方的业务方、需求提出方主导，或者由甲方委派第三方测试团队开展验收测试工作。

这里就会存在一个问题：验收测试人员，并非用户的实际使用者。这个问题下文再展开。

二、验收测试的准入条件

一个标准的测试管理流程中，每一个阶段都需要建立“准入”条件，否则一方面浪费测试人员的时间，另一方面也会降低上一阶段人员的执行标准。

比如为什么开发人员交付的功能，测试人员在正式开始测试时要进行冒烟测试？一个连主流程都有问题的功能，异常控制能做到什么程度呢？

因此，去年为了提升产品团队的验收效率，我也制定了一些准入标准，各位同行可以结合自身团队情况维护一套自己的“验收准入条件”。

1、上一阶段的测试报告

上一个阶段大多是系统集成测试，测试完成后的测试报告将作为一个基础的条件。

而这份报告重点关注什么？或者说从测试完成到出具报告可能存在几天的延迟，这时我们就干等着吗？

其实我们需要的并非“报告”这个形式，而是其中的关键结果：测试通过率。并且关注一下未通过、遗留的缺陷是什么情况，是否会阻碍验收进度，影响用户的场景闭环。

当然，一个正常的团队，各个角色之间的沟通应该是很通畅的，大多数问题在准入前，测试和产品之间应该会有多次的讨论，只不过在真正要启动验收时，还需要重点关注一下。

2、验收账号

在测试环境下，测试账号是一个非常重要，但又经常被大家忽略的问题。如果能有一个合适的测试账号，维护一套合理的测试数据，将会为测试阶段的提效带来质的改变。

因此，在正式开始验收测试之前，我们需要基于测试用例围绕的场景，提前准备好测试账号，并且最好能掌握一些基础的数据库操作，能够自己维护、设计测试账号，而不是每次找测试人员或开发人员。

时间久了，不仅会浪费对方的时间，也会让对方觉得你，很不专业。

一个新的测试阶段开始时，大多数系统都要清理测试数据，尽量让系统与刚上线时的状态一致。然而，想必很多人也体会过，数据清一次，系统崩一次。

所以关于测试数据的问题，需要协调技术负责人整理一份健壮的数据清理脚本，并在系统集成测试阶段经受住考验。

3、验收测试用例

上一条提到，验收测试开始前需要设计好测试用例，准入条件满足之后即可开始验收。

而测试用例的准备及评审，可以放在项目设计阶段，或者集成测试中期。具体时间大家可以结合实际情况确定。

我的习惯是在需求评审阶段引入测试用例的宏观设计，设计评审阶段开始进行测试用例的编写，设计评审结束后，进行测试用例的评审（系统集成测试），集成测试用例评审结束后，进行验收用例的评审。

这样做的好处，一方面可以使后置阶段提前介入，从而保证业务由粗到细的顺序拆解。

另一方面也能够将“敏捷迭代”的管理思路融入各阶段协作过程中，以降低交接、单线程工作等待的资源消耗。

4、什么时候开始启动？

按照上述的思路，产品验收虽然是最后一个环节，但它的启动阶段可以前置到“设计阶段末期”或“开发阶段初期”，提前将验收的目标、用例、评审几个环节达成一致，等到正式进入验收测试后，直接做执行即可。

其实就是以敏捷的思维交叉协同。

三、验收测试阶段的人员分工

验收阶段主要涉及三类角色：产品（业务）、测试、开发。

产品：是本阶段的主导人，负责具体执行、决策、协调、结果产出等相关事项。

当然在此过程大概率会涉及UI或UE方面的调整，根据公司的团队组成不同而略有差异，在此我将这些分工都纳入产品团队。

测试：协助产品维护测试环境和测试数据、定位问题、分析问题、协调开发资源等。

开发：负责缺陷修复工作，以及对复杂问题的分析、设计工作。

四、验收测试的侧重点

验收测试的目标与集成测试有很多区别，所以侧重点也有很多不同。

另外，基于参与验收测试的人员特性，在测试过程中看待问题的角度和决策方向都有较大差异。

1、核心业务流程

本阶段的测试重点在核心业务流程和用户体验层面，对后台处理逻辑的合理性、性能等不会过度关注。

比如在页面上输入A，经过处理输出B，我们只需要确认A、B的结果没有问题即可。至于是A->C->D->E->B，还是A->F->B，大多数验收测试不会关注。后台的处理过程应该在设计阶段、集成测试阶段进行验证。

比如报表查询的等待时间是3秒还是3.5秒，对于业务人员也不会关注，只要不超过一定的“阈值”即可。而真正的性能测试、安全测试等，都有相应的测试阶段“专项攻克”。

所以本阶段最关键的内容，依然是核心业务流程，即主干+分支，或者是核心场景+辅助场景。

我们需要从用户的角度来评估，这些功能是否能够解决预期问题，是否能够为原有流程带来效率提升。

术业有专攻，如是而已。

2、关键用户体验

另外，验收测试的重点是用户体验测试。这里包含了平台体验一致性、易用性、交互效率、合理性等，根据不同的产品类型，还包含创新性、趣味性等。

很多产品在前期并不重视用户体验，最终呈现了一个看似什么问题都能解决，但没有用户使用的“残次品”，很多问题也是出现在了验收测试阶段。

这里着重强调一个“用户思维”。无论是哪类人员进行验收测试，都要站在目标用户群体的画像上，试着以他们的角度、认知、习惯来审视当下的产品功能，而非利用自己的习惯进行评判。

举个不恰当的例子：假设这款产品是为视力较差且不戴眼镜的用户设计的，字体就要放大，布局就要稀松。而验收测试的人即便视力正常，也要遵循目标用户的操作习惯。

或者产品是为年轻女性提供的，验收人是中年男性，则更需要站在目标用户的习惯下审视这些功能。

而且，本身验收测试人员对互联网软件工程的理解比较浅，因此更要发挥自己的优势，以用户、场景、业务为导向，在此阶段中发现潜在的操作问题。

3、验收的准出标准

验收测试的结束，意味着产品达到上线标准。但达到上线标准并不代表没有缺陷，所以我认为验收测试的准出原则主要有以下几个：

（1）新一轮验收测试中，主流程+辅助流程的缺陷修复率达到100%；

（2）遗留缺陷在不影响系统正常运行前提下，多方达成一致确认可后续迭代优化；

（3）产品整体的视觉体验验证通过；

（4）对于升级类产品，对于原有功能的影响度测试完成；

最后，形成验收测试报告，将本次测试的结果写清楚。

五、验收测试的问题处理

1、交叉验收

我最初的想法，是让团队内的人员进行“交叉验收测试”，即张三负责的需求，验收测试由李四做；李四负责的需求，验收测试由王五做。

这样交叉验收的好处是：一方面组内同学都可以相互了解产品的业务全貌，避免形成思维壁垒；另一方面也是做了一层保障，让新同学测试，更容易找到用户视角。

但前提都要以团队内的资源情况和工程进度为基准，适度调整。

2、缺陷处理机制

大部分缺陷，直接找到测试人员或开发人员进行验证、修复即可。

但有时会遇到不太好改的问题，或者随着时间推移导致政策变动、用户预期及偏好变动、市场变动等情况，让业务人员发现本版并不能满足业务要求。

此时，如何做决策？

每个团队的决策影响因素都不一样，在此我仅分享两个曾经使用的原则：

（1）少量极端场景下存在等级为高级的缺陷要进行需求变更

若需求变更程度小于10%且工作量在1周内的本版本解决，可以进行需求变更；若需求变更范围影响涉及比例超过原需求10%则延至下一版本，并确定延期交付的时间。

（2）经过产品评审会讨论，此功能不再验收（忽略）。

有些问题虽然存在，但为特殊场景下的低频偶发情况，经过评审会讨论后，将其忽略。

3、验收轮次

正常来讲，产品验收测试做两轮即可，如果遇到交付质量较高的版本，一次测试直接通过也可以。

但我也遇到过验收测试做了多轮的情况，大多是因为前期流程控制和交接的问题，在本阶段出现了需求变更、需求蔓延等，导致后续的过程异常艰难。

也有一些集成测试质量较差的，导致验收测试一直在关注细节。

其实每个测试阶段要进行几轮，并没有一个明确的规范，我们可以结合当下版本的大小、风险的高低、资源配置情况等，制定不同的要求。

但千万要注意，每当新一轮测试伊始，经常会出现一些稀奇古怪的问题，这些问题一定要引起团队的重视，因为在软件层面，任何一个问题的出现都不是偶然。

很多稀奇古怪的问题，恰恰反映了当下团队的项目过程管理体系的缺失。

写在最后

今天的分享，基本框架是去年我在团队中构建的产品验收流程，然而随着我的离开，也没有机会验证此流程的效果，这不得不说是一种遗憾。

一份流程的建立不仅需要对现状和目标的考量，更需要牵头人的督导和推动，在面对多重阻碍时适度调整，最终经过几个周期的迭代，让各个角色都形成一种习惯。

而这个周期，大概率要以“季”或“年”为单位衡量，确实很难，但我相信一定有团队在做，或已经做出了成果。

最后总结一句：

产品团队要站好最后一班岗，既要为自己的设计方案负责，更要为自己的交付结果负责。

作者

不想延期，公众号：不想延期。半路转行的B端泛金融产品，坚持“以实践验证理论，以输出倒逼成长”的目标。点滴珍贵，重在积累

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！