聊聊“产品验收”

2 评论 3919 浏览 43 收藏 16 分钟

产品在迭代更新之际,每个迭代周期发布的时候,都会有个“验收”的过程,那么要如何做好这个验收环节呢?本文总结了相关思路以及问题处理的步骤,希望对你有所帮助。

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

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

作为测试入行的我,这些年也经历了很多验收测试,如果团队真的能够重视验收测试,并将其标准化、规范化,能识别很多潜在风险,也能让原本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端泛金融产品,坚持“以实践验证理论,以输出倒逼成长”的目标。点滴珍贵,重在积累

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 好巧哈,从星球,到公众号,再到人人都是产品经理。
    我也坚信“输出倒逼成长”

    来自北京 回复
  2. 昨天就因为验收没做好被叼了

    来自北京 回复