需求评审相关

[he-sb]

产品将一个即将实施的需求，讲解给相关参与人（开发，设计，测试等）。

需求的形式：

• 需求文档
  • 背景，级别，收益，内容，业务流程，交互示例，影响范围说明
  • 模板，确认
• 一句话需求
  • 没有规范
• 口头传达
  • 产品有想法-找开发口述-边讲解边调整
  • 几次讲解内容还可能有出入

评审的目的：

对齐

• 保证相关人员了解需求
  • 统一产品，开发，测试等对需求的理解
• 讨论实现过程中可能存在的问题和解决方案
  • 不同角度，讨论优化，避免开发过程中遇到严重影响进度的困难
• 明确职责和项目周期
  • 人员，职责，参与时间

谁来组织

一般是产品来讲解需求，但我们作为测试，发现了需求存在理解困难，有较多歧义的时候，也要积极主动的去组织需求评审，邀请产品或开发来进行讲解。积极主动，不要提测后才开始工作（测试左移）。

评审时要做什么

测试人员的关注点：

• 关注公司，部门规划
• 分辨需求类型（不是所有需求都需要评审）
• 关注产品规划，找准责任人
• 督促评审，关注交付进度，风险预警
• 提前阅读需求文档

如何评审：

• 测试左移的意识
  • 测试工作在需求评审时已开始，不是在开发完成，提测后才开始，每个阶段都有测试需要做的工作
• 根据以往经验（测试经验，对业务的理解，客户的使用习惯等）对需求形成自己的意见，有异议要积极反馈
• 关注大家的不同意见，讨论并找出优化方案，达成一致
• 对需求的修改，确保产品修改相应文档，确保需求变动的文档化
• 确认时间节点
• 根据需求，明确测试范围
  • 本次需求要保证的内容
  • 可能影响的原有业务
  • 是否需要其他业务支持
• 根据需求类型，确定测试方案
  • 需求确认--功能测试
  • 并发需求--性能测试
  • 安全相关--安全测试
  • 影响范围--回归测试

评审之后

• 待确认内容是否达成一致
  • 达成一致的部分是否确认
  • 若未确认，是否影响整体规划，何时能给出确认方案
  • 避免无效会议（讨论了很久，最终没有形成准确方案，无法进行后续的落地实施）
• 交付物的跟踪和确认
  • 需求文档是否修改
  • 开发和设计有无需要准备的内容
  • 时间节点是否 / 何时确定
• 时间节点确认
  • 需求更改交付时间
  • 设计完成时间
  • 测试用例评审时间
  • 提测时间
  • 测试起止时间
  • 上线时间
• 需求的维护和管理
  • 需求变动有没有更新到文档
  • 设计文档有无统一管理
  • 开发过程中，因技术问题引起的需求变动，是否落实到文档，是否将变动同步给各参与方

---

参考来源：

1. 测试人员如何进行需求评审 · TesterHome

[he-sb]

太水了，就放在这里备忘吧，不用加进博客里了。。