qa-retrospective

⚠️ 安全警告：本技能的示例可能涉及发布流程优化和协作流程调整建议。 这些是复盘议题不是直接操作；请勿未经评审即变更团队流程，先达成共识再落地。 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

复盘与经验沉淀

核心原则

复盘的目的是找到系统性的改进点，而不是找谁背锅。

复盘五步法

第1步：收集数据

数据收集：
├─ 缺陷数据
│   ├─ 本迭代新增缺陷数
│   ├─ 缺陷严重程度分布
│   ├─ 缺陷类型分布
│   └─ 缺陷模块分布
│
├─ 漏测数据
│   ├─ 线上缺陷数
│   ├─ 漏测原因分类
│   ├─ 漏测影响评估
│   └─ 漏测修复情况
│
├─ 测试数据
│   ├─ 用例执行率
│   ├─ 用例通过率
│   ├─ 测试覆盖率
│   └─ 测试效率
│
└─ 其他数据
    ├─ 需求变更次数
    ├─ 测试延期情况
    ├─ 线上故障情况
    └─ 用户反馈情况

第2步：根因分析（5 Whys）

5 Whys分析法：

问题：线上出现XX Bug
├─ Why 1：为什么测试没发现？
│   └─ 因为测试用例没覆盖这个场景
├─ Why 2：为什么用例没覆盖？
│   └─ 因为需求分析时没考虑到
├─ Why 3：为什么需求分析没考虑到？
│   └─ 因为对这个业务场景不熟悉
├─ Why 4：为什么不熟悉？
│   └─ 因为没有相关的知识沉淀
├─ Why 5：为什么没有知识沉淀？
│   └─ 因为没有复盘和总结机制

根因归类：
├─ 思维盲区：没想到
├─ 信息缺失：不知道
├─ 流程问题：流程不完善
├─ 工具问题：工具不支持
└─ 能力问题：能力不足

第3步：制定改进措施

改进措施设计：
├─ 具体：明确做什么
├─ 可执行：能落地执行
├─ 可衡量：有明确标准
├─ 有负责人：明确责任人
└─ 有时间：明确完成时间

改进措施类型：
├─ 流程改进：优化测试流程
├─ 工具改进：引入/优化工具
├─ 知识沉淀：更新Checklist/模板
├─ 能力提升：培训/学习
└─ 协作改进：优化协作方式

示例：
改进措施：更新登录功能测试Checklist
├─ 具体：增加验证码相关测试点
├─ 负责人：XXX
├─ 完成时间：2024-01-15
├─ 验收标准：Checklist更新并通知团队
└─ 效果验证：下次迭代验证效果

第4步：资产沉淀

资产沉淀类型：
├─ Checklist更新
│   ├─ 新增测试点
│   ├─ 修正错误点
│   └─ 优化检查项
│
├─ 模板更新
│   ├─ 用例模板优化
│   ├─ Bug报告模板优化
│   └─ 测试报告模板优化
│
├─ 知识库更新
│   ├─ 常见问题FAQ
│   ├─ 测试经验总结
│   └─ 最佳实践
│
└─ 流程更新
    ├─ 测试流程优化
    ├─ 协作流程优化
    └─ 发布流程优化

第5步：跟踪闭环

跟踪机制：
├─ 定期检查：每周/每月检查改进措施执行情况
├─ 效果验证：验证改进措施是否有效
├─ 持续优化：根据效果持续优化
└─ 经验分享：分享改进经验

闭环检查：
├─ 措施是否执行？
├─ 效果是否达到？
├─ 是否需要调整？
└─ 是否可以推广？

复盘报告模板

# 复盘报告

## 1. 基本信息
- 迭代版本：[版本号]
- 复盘时间：[日期]
- 参与人员：[人员列表]

## 2. 数据回顾
- 缺陷数据：[新增X个，严重X个]
- 漏测数据：[线上X个]
- 测试数据：[执行率X%，通过率X%]

## 3. 问题分析
- 主要问题：[问题描述]
- 根因分析：[5 Whys分析]
- 根因归类：[思维/信息/流程/工具/能力]

## 4. 改进措施
- 措施1：[具体措施]
- 措施2：[具体措施]
- 措施3：[具体措施]

## 5. 资产沉淀
- Checklist更新：[更新内容]
- 模板更新：[更新内容]
- 知识库更新：[更新内容]

## 6. 跟踪计划
- 检查时间：[时间]
- 负责人：[人员]
- 验收标准：[标准]

应用场景

迭代结束后复盘：用户登录模块出现了3个线上Bug → 第1步：收集数据（Bug报告、修复记录、测试用例覆盖） → 第2步：5 Whys分析（why漏测？→边界用例未覆盖→why？→测试设计时未识别边界→why？→需求未说明边界） → 第3步：改进措施（增加边界分析环节、补充典型边界checklist） → 第4步：资产沉淀（将边界checklist更新到启发式清单） → 第5步：跟踪计划（下个迭代验证新增checklist的有效性）