熟悉该需求相关内容,提前考虑到需求风险,及时反馈需求风险,让开发人员在研发过程中注意,避免产生更多的Bug
分析需求漏洞,及时反馈设计缺陷,需求评审会议时可以立刻修改策划案或会议后修改,避免研发后大量修改或重做
在三方、四方人员对于需求看法的讨论过程中大致确认部分需求的负责人,明确处理人,方便后续的Bug提单
在评审讨论的过程中通过开发人员、策划所描述的逻辑以及实现方式,考虑可能会出现的代码逻辑漏洞以及配置漏洞
对于需求中存在疑问的地方及时提出,让策划方解答问题,为后续的测试用例编写以及测试做准备
可以帮助策划提供一些需求上的建议内容、以及后续的优化,分析玩家群定位,也可以避免研发需求后大量修改或重做
根据讨论的各类要素判定,从测试用例的编写以及测试流程的结束所使用的测试时长,以把控需求风险及测试质量