需求理解和沟通的流程规范
在整个测试过程中,需求的正确理解是整个测试的核心环节。从整个产品的设计开发过程,测试工程师都要参与其中,大概分为以下几个阶段:需求评审会前、需求评审会中、需求评审会后、用例设计及测试中。...
在整个测试过程中,需求的正确理解是整个测试的核心环节。从整个产品的设计开发过程,测试工程师都要参与其中,大概分为以下几个阶段:需求评审会前、需求评审会中、需求评审会后、用例设计及测试中。每一个阶段应该怎么做呢?
首先,需求理解不同阶段的需求确认量可以用几个占比说明一下:
测试阶段
需求了解比重
需求评审会前
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%。
- 小结
关注 搜狗测试
微信扫一扫关注公众号