第2章 QA协作角色定位：QA职责、开发职责、产品职责、三方协作模型
章节导读：验收标准不是单方制定的文档，而是QA、开发、产品三方协作的契约。本章从角色职责出发，建立三方协作模型，明确各自在验收标准制定与执行中的责任边界与协作路径。
2.1 适用场景
三方协作模型适用于以下典型场景：
- 新功能验收：产品需求进入开发阶段后，需三方共同明确验收标准。
- 回归测试与缺陷修复：需要QA与开发对齐修复标准，产品确认业务影响。
- 跨团队联调与集成验证：涉及多系统交互时，产品定义端到端流程，开发实现接口，QA验证全链路。
- 版本发布前质量门禁：三方共同评审验收结果，决定是否允许发布。
2.2 前置条件
- 产品需求文档（PRD）已评审定稿，包含明确的业务目标与验收条件。
- 团队已分配QA、开发、产品三类角色，且成员熟悉各自职责。
- 已建立统一的验收标准模板与协作工具（如Jira、TAPD、Confluence）。
- 三方约定固定的沟通节奏（如每日站会、周评审会）。
2.3 操作步骤
- 角色职责对齐：召开三方协作启动会，宣读并确认QA、开发、产品的职责边界，记录在案。
- 验收标准共创：产品撰写验收条件草案，开发评估可行性，QA补充可测试性要求，三方评审达成共识。
- 协作路径设定：明确信息传递链路——产品→开发（需求澄清）、开发→QA（提测通知）、QA→三方（验收报告）。
- 验收执行与反馈：QA按验收标准执行测试，开发修复缺陷，产品确认业务满足度，形成闭环。
- 持续改进：每次版本结束后三方复盘协作效率，更新职责矩阵与验收标准模板。
2.4 输入输出物
| 方向 | 输入物 | 输出物 |
|---|---|---|
| 产品 → 三方 | 产品需求文档（PRD）、原型图、验收条件草案 | 定稿的验收条件、业务价值确认清单 |
| 开发 → QA | 提测申请、自测报告、代码分支与部署说明 | 可交付版本、缺陷修复确认单 |
| QA → 三方 | 测试策略、验收用例、缺陷列表 | 验收测试报告、质量评估结论 |
2.5 责任边界
| 角色 | 核心职责 | 验收标准中的关注点 |
|---|---|---|
| QA | 质量验证与把关 | 可测试性、覆盖率、边界条件、异常场景、可重复性 |
| 开发 | 功能实现与自测 | 功能完整性、性能基线、接口契约、自测通过率 |
| 产品 | 需求定义与业务确认 | 业务价值、用户体验、验收条件与需求一致性、优先级 |
关键原则：QA负责“验证是否正确实现”，产品负责“确认实现的是否正确”，开发负责“正确实现需求”。三方职责互不重叠但紧密耦合。
2.6 三方协作模型（SVG框架图）
2.7 记录材料
- 《三方职责登记表》——记录QA、开发、产品在验收标准制定与执行中的具体职责，经三方签字确认。
- 《协作沟通日志》——记录每日站会、周评审会中的关键决策、待办事项与风险项。
- 《验收标准确认单》——每个功能或用户故事的验收条件，由产品起草、开发评估、QA补充后三方电子签批。
- 《版本验收报告》——QA汇总执行结果，包含通过率、缺陷分布、未达标项及改进建议。
2.8 异常处理
| 异常场景 | 表现 | 处理措施 |
|---|---|---|
| 职责重叠或推诿 | QA与开发对缺陷定级争执，或产品越权指定测试用例 | 回归《三方职责登记表》，由项目经理仲裁，更新职责边界 |
| 验收标准理解不一致 | QA按自己理解执行，产品验收时发现偏差 | 立即组织三方澄清会，修改验收条件描述，补充示例 |
| 沟通链路断裂 | 需求变更未及时通知QA，导致用例失效 | 建立变更通知机制（如Slack/飞书机器人），强制@对应角色 |
| 协作流程阻塞 | 开发提测延迟或QA反馈超时，影响版本计划 | 设置SLA（如提测后2小时内QA启动验证），每日站会跟踪 |
避坑提示：不要将“验收标准制定”完全甩给QA或产品单方。缺少任何一方的输入，验收标准都会出现盲区——要么缺业务合理性，要么缺技术可行性，要么缺可测试性。
2.9 验收标准
第2章内容交付需满足以下验收条件：
- QA、开发、产品三方职责清晰定义，无重叠、无遗漏，且已记录在《三方职责登记表》中。
- 三方协作模型图（SVG）完整展示角色节点、连接关系与协作目标，与文字描述一致。
- 输入输出物清单覆盖三方协作全流程，且与操作步骤中各环节对应。
- 异常处理表格至少包含4种典型异常场景，处理措施具体可执行。
- 所有记录材料模板已创建并归档至团队知识库（如Confluence）。