头痛的产品验收到底该怎么作？

近期带着团队再推进PMTalk产品的迭代和新版本上线。

围绕着自家的小程序、和PC、还有客户端app3个形态下不断作调试和优化。若是你关注使用过PMTALk，就应该能够感觉到咱们在近年也在发生了较大的变化。

对于小团队或创业项目的产品，产品验收便可以减小资源和时间的浪费，还能快速投入到下个环节工做。

我如何在团队里作产品验收的？分享下个人经验。

1.搞清楚验收和测试的区别

这个部分实际上就把不少小团队搞晕了。

因为没有测试人员、或专业的验收流程，致使产品的验收和测试所有混在一块儿。每次都是开发结束了后才进行测手验收。

其实验收和测试是2个彻底不一样的内容。

1.测试的工做

软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否知足规定的需求或弄清预期结果与实际结果之间的差异。

测试是依照产品经理的需求文档或测试用例进行还原，即便需求文档是错误的，包括没有描述到的逻辑问题，测试的工做要么是跳过不测试，要么是根据错误的需求来描述。

需求开始迈入UI设计前，需求评审中会拉上测试，搞清楚了需求的背景、目的以及需求大致范围后，测试会基于需求文档输出测试用例。产品经理则要求通读测试用例进行把控用例的描述是否准确，同时有无遗漏需求。

▲某测试用例

好比上图是测试用例的描述，针对功能下的操做前置条件、后置条件、基本操做流程进行描述。

一个功能需求会涉及到上百条测试用例，须要测试人员提早撰写和产品经理评估。

2.产品验收

产品验收和测试的目的彻底不一样，但产品验收产生的过程会和测试相重复，但产品验收的目的只有一个

当前产品版本能不能上线、能不能正式发布。在小公司里没有审核流程的说明，产品经理和业务负责人、或者老板赞成就能够发版本。

产品验收阶段会发现不少问题，好比功能的设计缺陷、逻辑错误，甚至是最致命的功能无效、没法解决需求问题。

咱们PMTalk会整理出验收表，以下包含了序号、问题、截图、优化描述、解决状态。

解决状态由开发进行标记和同步。其余部分则是产品经理填写

▲验收文档

以序号来定位优化问题，属于BUG的就概括为当前版本，属于优化的就归属到下一个版本。

▲BUG池

在BUG文档里下面字段以下

解决状态：

当前BUG是否解决，是关键再次验收的标准。

优先级：

根据紧急和重要程度来建设4个优先级，分别是P一、P二、P三、P4

模块：

BUG的功能定位，在哪个位置上

平台：

若是涉及到多个产品端和系统的介入，则须要定位出BUG在那个平台或系统上。若有调用科大讯飞语音能力，因为没有充值帐户致使客户端的语音识别能力受阻，就是第三方平台能力欠费致使。

问题描述：

主要描述逻辑问题、UI问题、文案问题，给出正确的对应描述。若是涉及到复杂逻辑和复杂效果，则须要当面评审沟通。

提出人：

标记出问题的提出人，多是业务、也多是运营、还有多是产品经理。总之定位出问题的直接提出者，注意不是责任人。由于不少时候责任人不是提出

问题类型：

问题的类型根据验收的环节不一样，有很是大的区别。好比UI还原不正确的，属于Ui问题、与需求描述不一致的属于功能缺陷、常见的问题好比点击没有反应、跳转错误则属于BUG。

但不少时候若是团队比较小，均可以统称为BUG，惟独须要优化的单独罗列出来便可。

3.上线验收最难的是进度与状态更新

几乎每一个公司都会出现这样的问题

就是产品上线前验收发现的问题，更新进度不及时就会致使重复测试以及资源浪费。

因此很是推荐各位产品经理使用禅道、TB这样的协同项目管理工具。及时更新BUG的状态和数量，盯紧对应问题的开发、UI执行人，注意不是负责人是第一执行人。

固然项目和系统仍是要依靠人力管理，好的研发管理制度能够明显减小BUG解决时间，而扮演这个角色的人几乎都是产品经理为主。

若是所有丢给项目经理或研发负责人来管，其实也是否是一个合格的产品经理。

今天的分享就在这。