需求理解和沟通的流程规范

需求理解和沟通的流程规范

http://mp.weixin.qq.com/s/-Puws9HvZAIWkioyot1Pgg

在整个测试过程中，需求的正确理解是整个测试的核心环节。从整个产品的设计开发过程，测试工程师都要参与其中，大概分为以下几个阶段：需求评审会前、需求评审会中、需求评审会后、用例设计及测试中。每一个阶段应该怎么做呢？

首先，需求理解不同阶段的需求确认量可以用几个占比说明一下：

测试阶段	需求了解比重
需求评审会前	50%
需求评审会中
需求评审会后
测试大纲设计中	40%
测试大纲执行中	10%

当然随着团队效率的提升，这个比重也会发生变化，这里只做参考。

下面，具体说明一下，在不同阶段了解需求的详细流程和规范。

• 需求评审会前

要想知道需求评审会前做什么，先让我们思考一下，需求评审会的目的。通过与需求评审会的发起者产品沟通，产品组织需求讨论会的目的是初步讲解一下产品要做什么、产品方向，在开发、测试在场的情况，发现交互、需求中不足的地方或者不合理的地方，互相弥补，便于产品交互后期的更新和补充完善需求。

总之，产品方希望需求确认问题能尽量暴露在前面，故在需求讨论会中，可以抛出尽可能多的问题。

评审会流程图：

                           

详细说明：                         

1、产品需要在需求评审会前至少前一天发出需求文档，具体地说，需要给测试工程师预留4-8h工作日去阅读文档。举例，产品在1月2日10:00举行需求讨论会，至少需要在1月1日14:00前发出需求文档。如果产品没有提前发出，各平台项目负责人需要找产品沟通此事，调整需求讨论会时间。

2、测试工程师要及时阅读自己负责模块的需求文档，备忘记录和准备相关问题。如果准备得比较充分，可以提前邮件发给产品和交互（提前发出问题不做强制要求）。

      

• 需求评审会中

在需求评审会中，产品和交互讲解各个功能点的需求，相关测试负责人就可以在这个阶段提问自己准备的问题，同时，如果有其他新的问题、想法、观点，都可以在这个阶段提出。

当然，不是该模块负责人的测试工程师，也可以提出一些问题、想法和观点，多多益善。

这个阶段，可能产生出以下几种问题：

1、产品和交互可以当场解答的较为明显的问题。

2、需要三方一起讨论后，形成一个结论。

3、非常细节，需要较长时间仔细思考的问题。

针对问题1和2，形成结论，产品、交互和测试都需要进行笔记备忘，针对问题3，产品要对问题做好备忘（这里项目负责人要前期与产品沟通清楚，产品需要自觉记录问题）。

 

• 需求评审会后

这个阶段主要是指从需求评审会结束到用例设计前这段时间。

这个阶段产品和交互的工作量比较多，主要是整理需求评审会中的问题，等待有了准确结论，需要再发布一份更加完善的需求文档和交互设计稿，并且更新到SVN上。这个更新时间最好不要晚于测试用例设计排期的时间，如果产品有不能在测试用例设计前发出最终文档的风险，项目负责人要与产品交互做好沟通工作。

在需求评审会前、中、后，这整个过程，需求确认任务应该完成50%。

• 测试大纲设计中

在收到最终版的需求文档后，测试就可以开始按照排期编写测试大纲了，这个过程中一定会遇到很多需要确认的问题，逐步确认问题就好。

重点关注：

与产品交互确认问题最终一定要落实在书面上，如果是邮件确认的问题，最后要有邮件的结论；如果是口头确认的问题，要有邮件对结论的总结。并且邮件均要公示到全项目组，且一定要抄送相关开发。

在测试大纲设计中，需求确认任务应该完成40%。

• 测试大纲执行中

测试大纲执行中，也是开发提测后的阶段，在具体的操作中，也会引发一些思考补充，可以在这个阶段确认这些问题。但是这个阶段不是确认需求问题的主要阶段，只能起到一个锦上添花的作用，应该尽量避免核心需求逻辑的推翻，或者大批量的需求确认问题。

在测试大纲执行中，需求确认任务应该完成10%。

• 小结

总之，需求评审会和用例设计中，是需求确认的黄金时间，在这个阶段能够把问题确认清楚，对于整个产品发版效率会有很大帮助。