quality-postmortem
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese<objective>
Analyze escaped defects, test suite health, and quality process gaps through structured, blameless postmortems. Every postmortem produces 1-3 concrete, tracked action items -- not vague commitments to "be more careful." The goal is systemic improvement, not individual blame.
</objective>
<objective>
通过结构化的无责复盘分析逃逸缺陷、测试套件健康状况以及质量流程中的漏洞。每次复盘需产出1-3项具体的、可追踪的行动项——而非“更加谨慎”这类模糊的承诺。目标是系统性改进，而非追究个人责任。
</objective>
Quick Route
快速指引
| You have... | Go to | Template |
|---|---|---|
| One escaped bug to dissect | Bug Pattern Analysis | Escaped Bug Analysis ( |
| 10+ escaped bugs, looking for themes | Aggregating Patterns Over Time | — |
| A proactive quarterly check (no incident) | Test Suite Health Review | — |
| A P0/P1 production incident | Postmortem Template for Quality Incidents | |
| A recurring sprint/monthly review | Retro Meeting Template | |
| 你遇到的情况 | 处理方向 | 模板 |
|---|---|---|
| 需剖析单个逃逸缺陷 | 缺陷模式分析 | 逃逸缺陷分析（ |
| 有10+个逃逸缺陷，需寻找共性规律 | 长期模式汇总 | — |
| 主动进行季度检查（无事件发生） | 测试套件健康评审 | — |
| 发生P0/P1级生产事件 | 质量事件复盘模板 | |
| 定期进行迭代/月度评审 | 回顾会议模板 | |
Discovery Questions
探索性问题
Check in the project root first — it carries quality goals, risk areas, and test suite details that anchor any postmortem. Use it and skip anything already answered there. Then clarify:
.agents/qa-project-context.md-
Do you have a regular retro cadence? Per-sprint, monthly, or only after incidents? Regular cadence catches slow-burn problems. Incident-only cadence misses patterns until they explode.
-
What triggered this postmortem? A production incident? A pattern of escaped bugs? A feeling that the test suite is not catching enough? Test suite degradation? The trigger determines the focus.
-
What data is available? Bug tracker with severity and discovery phase? CI history with pass rates? Flaky test reports? Coverage trends? Without data, postmortems devolve into opinion sessions.
-
What happened with previous postmortem action items? Were they completed? Tracked? Forgotten? If past action items are abandoned, the team has learned that postmortems do not matter. Fix the follow-through before running another postmortem.
-
Who should participate? Engineers who worked on the affected area. QA who tested (or did not test) it. Product owner if the impact was user-facing. Engineering manager if systemic changes are needed. Keep the group to 4-8 people.
-
What are the current test suite health concerns? Rising flakiness? Slow execution? Coverage gaps in critical areas? Stale quarantine? Health reviews are proactive postmortems -- they prevent incidents instead of reacting to them.
首先查看项目根目录下的——其中包含质量目标、风险区域和测试套件详情，是所有复盘工作的基础。若已有答案，可跳过对应问题。随后明确以下内容：
.agents/qa-project-context.md-
是否有固定的回顾会议节奏？ 每迭代一次、每月一次，还是仅在事件发生后召开？固定节奏能发现渐进式问题，仅在事件后召开则会错过潜在规律，直到问题爆发。
-
触发本次复盘的原因是什么？ 生产事件？逃逸缺陷的共性模式？感觉测试套件未能捕获足够缺陷？测试套件性能退化？触发原因决定了复盘的重点。
-
有哪些可用数据？ 包含严重程度和发现阶段的缺陷追踪工具？带有通过率的CI历史记录？不稳定测试报告？覆盖率趋势？若无数据，复盘会沦为主观意见讨论。
-
之前复盘的行动项执行情况如何？ 是否已完成？是否被追踪？是否已遗忘？若过往行动项被搁置，团队会认为复盘毫无意义。在开展新复盘前，需先解决行动项的跟进问题。
-
哪些人员应参与复盘？ 负责受影响区域的工程师、测试过（或未测试过）该区域的QA、若影响用户则产品负责人也需参与、若需系统性变更则工程经理参与。参与人数控制在4-8人。
-
当前测试套件的健康问题有哪些？ 不稳定性上升？执行速度缓慢？关键区域覆盖率不足？隔离测试用例过时？健康评审是预防性复盘——旨在预防事件而非事后应对。
Core Principles
核心原则
1. Blameless Means Systemic
1. 无责意味着聚焦系统
Blameless does not mean "no one is accountable." It means the analysis focuses on systems, processes, and tools rather than individual performance. "Why did the system allow this defect to escape?" is a blameless question. "Why did the developer not write a test?" is a blame question that stops the analysis too early. The developer did not write a test because: the test framework was hard to use, the PR checklist did not require it, there was no pairing to transfer knowledge, or time pressure made it feel optional. Those are systemic issues with systemic fixes.
无责并非指“无需任何人负责”，而是指分析重点在于系统、流程和工具，而非个人表现。“为何系统允许该缺陷逃逸？”是无责式问题；“为何开发者未编写测试？”是追责式问题，会过早终止分析。开发者未编写测试可能是因为：测试框架难以使用、PR检查清单未要求编写测试、无结对编程传递知识、时间压力使其成为可选项。这些都是系统性问题，需系统性解决方案。
2. Focus on Patterns, Not Incidents
2. 聚焦规律而非单个事件
A single escaped bug is an anecdote. Three escaped bugs in the same feature area over two months is a pattern. Postmortems should aggregate incidents to find recurring themes: same root cause, same team, same test gap, same phase of the pipeline. Patterns are actionable. Individual incidents are just fire-fighting.
单个逃逸缺陷只是个案。两个月内同一功能区域出现3个逃逸缺陷则是规律。复盘需汇总事件以发现重复出现的主题：相同根因、同一团队、相同测试漏洞、流水线同一阶段。规律具有可操作性，单个事件只是救火行为。
3. Every Postmortem = 1-3 Concrete Action Items
3. 每次复盘需产出1-3项具体行动项
An action item is concrete when it has: a specific deliverable ("add integration tests for the coupon API"), an owner ("assigned to Alex"), a deadline ("by end of sprint 14"), and a verification method ("PR merged, tests passing in CI"). "Improve testing" is not an action item. "Write 5 integration tests for the payment service edge cases by March 30" is.
行动项需满足以下条件才算具体：明确交付物（“为优惠券API添加集成测试”）、负责人（“指派给Alex”）、截止日期（“第14迭代结束前”）、验证方式（“PR已合并，CI中测试通过”）。“改进测试”不是行动项，“在3月30日前为支付服务的边缘场景编写5个集成测试”才是。
4. Track to Completion
4. 追踪至完成
Action items that are not tracked are not completed. Use the team's existing work tracker (Jira, Linear, GitHub Issues). Tag them ( or equivalent). Review completion status at the start of the next postmortem. If items are consistently abandoned, either the items are too large (break them down) or they are not prioritized (make them sprint commitments).
postmortem-action未被追踪的行动项无法完成。使用团队现有的工作追踪工具（Jira、Linear、GitHub Issues）。为行动项添加标签（如）。在下一次复盘开始时评审完成状态。若行动项持续被搁置，要么是内容过于庞大（需拆分），要么是未被优先处理（需纳入迭代承诺）。
postmortem-action5. Measure Improvement With Two Metrics, Not One
5. 用两个指标衡量改进效果，而非单个
After implementing action items, measure whether the problem recurred. If the postmortem identified a gap in payment testing and the action was to add integration tests, track: did another payment bug escape? Without measurement, postmortems are rituals, not tools.
Track two metrics together:
- Defect escape rate (did similar bugs reappear?)
- Action-item-closure rate (what fraction of action items shipped within their committed window?)
A high closure rate with rising escape rate means the team is doing the work but doing the wrong work. A low closure rate means the postmortems are theater. Modern incident response platforms (incident.io, Rootly, FireHydrant) track action-item follow-through natively — owner, due date, completion status — so derive both numbers from what's already there before building a dashboard.
实施行动项后，需衡量问题是否再次出现。若复盘发现支付测试存在漏洞，行动项是添加集成测试，则需追踪：是否有新的支付缺陷逃逸？若无衡量，复盘只是形式主义，而非实用工具。
需同时追踪两个指标：
- 缺陷逃逸率（类似缺陷是否再次出现？）
- 行动项完成率（行动项在承诺期限内完成的比例？）
高完成率但逃逸率上升，说明团队在做无用功；低完成率说明复盘只是走形式。现代事件响应平台（incident.io、Rootly、FireHydrant）原生支持行动项跟进追踪——负责人、截止日期、完成状态——因此无需搭建仪表盘，直接从现有平台获取这两个指标即可。
6. AI Drafts the Timeline; a Human Owns the Judgment
6. AI生成时间线，人类负责判断
If your team uses AI SRE tooling (Rootly AI SRE, incident.io's AI SRE / auto-drafted post-mortems), let it draft the incident timeline and propose candidate root causes from logs and traces. Then a named blameless RCA owner — distinct from the incident commander who managed the response — runs the 5 Whys, picks the real root cause, and writes the action items. AI is good at correlation across noisy data; it is bad at deciding what mattered. Treat AI output as a starting deck, not the conclusion. For cheap timeline drafting, Sonnet 4.6 is sufficient; reserve heavier models for ambiguous causation.
若团队使用AI SRE工具（Rootly AI SRE、incident.io的AI SRE/自动生成复盘报告），可让其从日志和追踪数据中生成事件时间线并提出候选根因。随后由指定的无责RCA负责人（与负责事件响应的指挥官不同）开展5Why分析，确定真实根因并撰写行动项。AI擅长在嘈杂数据中寻找关联，但不擅长判断重要性。将AI输出视为起点，而非结论。若仅需生成时间线，Sonnet 4.6已足够；复杂因果分析可使用更强大的模型。
Bug Pattern Analysis
缺陷模式分析
Categorizing Escaped Defects
逃逸缺陷分类
When a bug reaches production, classify it along three dimensions to identify prevention opportunities. The single-bug worksheet (Escaped Bug Analysis) lives in .
references/templates.md当缺陷进入生产环境时，从三个维度进行分类以识别预防机会。单缺陷分析表（逃逸缺陷分析）位于中。
references/templates.mdDimension 1: Root Cause Category
维度1：根因类别
| Category | Description | Example |
|---|---|---|
| Logic error | Business logic incorrect or incomplete | Discount not applied for edge case currency |
| Integration failure | Two components do not communicate correctly | API returns different format than frontend expects |
| Data issue | Unexpected data shape, null values, encoding | User with emoji in name breaks CSV export |
| Race condition | Timing-dependent behavior | Two concurrent checkouts oversell last item |
| Configuration | Environment-specific settings wrong | Feature flag enabled in staging, disabled in prod |
| Regression | Previously working behavior broken | Refactor removed null check, old bug returns |
| Missing requirement | Behavior not specified, gap in product spec | No error handling for expired OAuth tokens |
| Performance | Functional but too slow under load | Search timeout with 100K+ records |
| 类别 | 描述 | 示例 |
|---|---|---|
| 逻辑错误 | 业务逻辑错误或不完整 | 边缘货币场景下折扣未生效 |
| 集成失败 | 两个组件通信异常 | API返回格式与前端预期不符 |
| 数据问题 | 意外的数据格式、空值、编码问题 | 用户名含表情符号导致CSV导出失败 |
| 竞态条件 | 依赖时序的行为异常 | 两个并发结账请求超卖最后一件商品 |
| 配置问题 | 环境特定设置错误 | staging环境启用功能标志，生产环境禁用 |
| 回归缺陷 | 原有正常功能被破坏 | 重构移除空值检查，旧缺陷重现 |
| 需求缺失 | 行为未被定义，产品规格存在漏洞 | 未处理OAuth令牌过期的错误场景 |
| 性能问题 | 功能正常但负载下速度过慢 | 10万+记录时搜索超时 |
Dimension 2: Which Test Level Should Have Caught It
维度2：本该捕获缺陷的测试层级
| Level | What it catches | If it escaped this level |
|---|---|---|
| Unit | Logic errors, edge cases, boundary conditions | Tests exist but missing edge case? Or no tests at all? |
| Integration | API contracts, data flow, service interactions | Integration tests exist? Do they cover error responses? |
| E2E | User journey failures, UI state management | Is this critical path covered? Was the specific scenario tested? |
| Manual/Exploratory | Visual issues, usability problems, unusual workflows | Was exploratory testing performed? Was the area in scope? |
| Monitoring | Performance degradation, error rate spikes | Are alerts configured? Are thresholds correct? |
| 层级 | 捕获范围 | 若缺陷逃逸该层级 |
|---|---|---|
| 单元测试 | 逻辑错误、边缘场景、边界条件 | 测试存在但遗漏边缘场景？或根本无测试？ |
| 集成测试 | API契约、数据流、服务交互 | 是否存在集成测试？是否覆盖错误响应？ |
| 端到端测试（E2E） | 用户流程失败、UI状态管理 | 关键路径是否被覆盖？特定场景是否被测试？ |
| 手动/探索性测试 | 视觉问题、可用性问题、异常流程 | 是否开展了探索性测试？该区域是否在测试范围内？ |
| 监控 | 性能退化、错误率飙升 | 是否配置了告警？阈值是否合理？ |
Dimension 3: Prevention Opportunity
维度3：预防机会
| Opportunity | Action | Example |
|---|---|---|
| Add test | Write a test at the appropriate level | Add unit test for currency rounding edge case |
| Improve existing test | Existing test was too narrow | Extend checkout E2E to include coupon + international currency |
| Add quality gate | CI check would have caught it | Add schema validation for API responses in CI |
| Improve requirements | Spec was ambiguous or incomplete | Add acceptance criteria for error states to story template |
| Add monitoring | Detect sooner even if not prevented | Add alert for error rate > 1% on payment endpoint |
| Training/Process | Knowledge gap or process gap | Run a session on defensive coding for nullable fields |
| 机会 | 行动 | 示例 |
|---|---|---|
| 添加测试 | 在合适层级编写测试 | 为货币舍入边缘场景添加单元测试 |
| 优化现有测试 | 现有测试范围过窄 | 扩展结账E2E测试，覆盖优惠券+国际货币场景 |
| 添加质量门禁 | CI检查可捕获缺陷 | 在CI中添加API响应的schema验证 |
| 完善需求 | 规格模糊或不完整 | 在用户故事模板中添加错误状态的验收标准 |
| 添加监控 | 即使未预防也能更早发现 | 为支付端点添加错误率>1%的告警 |
| 培训/流程优化 | 知识或流程漏洞 | 开展空字段防御性编码培训 |
Aggregating Patterns Over Time
长期模式汇总
After analyzing 10+ escaped bugs, look for patterns:
Escaped Bug Summary: [Q1 2026]
═══════════════════════════════
Total escaped bugs: 14
By root cause:
Logic error: 5 (36%) ← unit tests needed
Integration failure: 4 (29%) ← API contract tests needed
Data issue: 3 (21%) ← input validation gaps
Configuration: 2 (14%) ← env parity issues
By area:
Checkout: 6 (43%) ← highest risk, needs investment
User management: 4 (29%)
Reporting: 2 (14%)
Settings: 2 (14%)
By should-catch level:
Unit: 5 (36%) ← developers not testing edge cases
Integration: 4 (29%) ← missing integration test layer
E2E: 3 (21%)
Monitoring: 2 (14%)
Top action themes:
1. Add integration tests for checkout API (covers 4 of 14 bugs)
2. Mandate unit tests for all calculation/validation logic (covers 5 of 14)
3. Add currency and encoding edge cases to test data fixtures (covers 3 of 14)This aggregation reveals where investment has the highest return: fixing one systemic issue (integration tests for checkout) would have prevented 29% of all escaped bugs. Patterns that recur across multiple quarters belong in the doc, not just the next sprint's action items — promote them so the strategy reflects where defects actually escape.
test-strategy分析10+个逃逸缺陷后，寻找规律：
Escaped Bug Summary: [Q1 2026]
═══════════════════════════════
Total escaped bugs: 14
By root cause:
Logic error: 5 (36%) ← unit tests needed
Integration failure: 4 (29%) ← API contract tests needed
Data issue: 3 (21%) ← input validation gaps
Configuration: 2 (14%) ← env parity issues
By area:
Checkout: 6 (43%) ← highest risk, needs investment
User management: 4 (29%)
Reporting: 2 (14%)
Settings: 2 (14%)
By should-catch level:
Unit: 5 (36%) ← developers not testing edge cases
Integration: 4 (29%) ← missing integration test layer
E2E: 3 (21%)
Monitoring: 2 (14%)
Top action themes:
1. Add integration tests for checkout API (covers 4 of 14 bugs)
2. Mandate unit tests for all calculation/validation logic (covers 5 of 14)
3. Add currency and encoding edge cases to test data fixtures (covers 3 of 14)该汇总揭示了投资回报率最高的领域：修复一个系统性问题（结账API的集成测试）可预防29%的逃逸缺陷。跨季度重复出现的规律应纳入文档，而非仅作为下一迭代的行动项——将其升级，使测试策略能反映缺陷实际逃逸的区域。
test-strategyTest Suite Health Review
测试套件健康评审
A proactive postmortem for the test suite itself. Conduct quarterly or when symptoms appear.
针对测试套件本身的预防性复盘。每季度开展一次，或在出现症状时开展。
Flaky Test Trends
不稳定测试趋势
Flaky Test Trend Review
═══════════════════════
Current flaky rate: _____ % (target: <2%)
Trend (last 3 months):
Month 1: _____ %
Month 2: _____ %
Month 3: _____ %
Direction: [ ] Improving [ ] Stable [ ] Worsening
Top 5 flakiest tests (by failure count):
1. _____________________ — _____ failures — root cause: _____
2. _____________________ — _____ failures — root cause: _____
3. _____________________ — _____ failures — root cause: _____
4. _____________________ — _____ failures — root cause: _____
5. _____________________ — _____ failures — root cause: _____
Quarantine:
Tests in quarantine: _____ count
Oldest quarantine: _____ days (target: <14)
Quarantine resolved this month: _____ countFlaky Test Trend Review
═══════════════════════
Current flaky rate: _____ % (target: <2%)
Trend (last 3 months):
Month 1: _____ %
Month 2: _____ %
Month 3: _____ %
Direction: [ ] Improving [ ] Stable [ ] Worsening
Top 5 flakiest tests (by failure count):
1. _____________________ — _____ failures — root cause: _____
2. _____________________ — _____ failures — root cause: _____
3. _____________________ — _____ failures — root cause: _____
4. _____________________ — _____ failures — root cause: _____
5. _____________________ — _____ failures — root cause: _____
Quarantine:
Tests in quarantine: _____ count
Oldest quarantine: _____ days (target: <14)
Quarantine resolved this month: _____ countExecution Time Trend
执行时间趋势
Track current full suite duration, 3-month trend, and the 5 slowest tests. If duration is increasing, check for: tests that can move to nightly, sequential stages that can parallelize, slow test data setup (use API instead of UI), large test files that need splitting for better shard distribution.
追踪当前全套件执行时长、3个月趋势以及5个最慢的测试。若时长增加，检查：是否可将部分测试移至夜间执行、可并行化的串行阶段、缓慢的测试数据准备（使用API而非UI）、需拆分以优化分片的大型测试文件。
Coverage Gap Review
覆盖率漏洞评审
Track overall coverage (lines/branches), critical paths with insufficient coverage (payments, auth, data export should be 90%+), recently changed code without test updates (cross-reference with the coverage report), and features shipped without E2E coverage.
git log --since="30 days ago"追踪整体覆盖率（行/分支）、覆盖率不足的关键路径（支付、认证、数据导出应达到90%+）、近期变更但未更新测试的代码（交叉引用与覆盖率报告）、未开展E2E测试就发布的功能。
git log --since="30 days ago"Disabled/Skipped Test Inventory
禁用/跳过测试清单
Audit all skipped/disabled tests by age and reason. Tests skipped < 1 week are likely in progress. Tests skipped 1-4 weeks need a ticket and timeline. Tests skipped 1-3 months are overdue -- fix or delete. Tests skipped > 3 months should be deleted -- they will never be fixed. For each: fix and unskip, delete (obsolete), or move to quarantine with a ticket link.
按时长和原因审核所有被跳过/禁用的测试。跳过<1周的测试可能正在开发中；跳过1-4周的测试需创建工单并设定时间线；跳过1-3个月的测试已逾期——修复或删除；跳过>3个月的测试应删除——永远不会被修复。针对每个测试：修复并取消跳过、删除（已过时）、或移至隔离区并关联工单链接。
Process Improvement Cycles
流程改进周期
The Improvement Sprint
改进迭代
Dedicate a fixed portion of each sprint (10-15% of capacity) to quality improvement, drawn from postmortem action items and health review findings.
Structure:
1. IDENTIFY — Top 3 pain points from latest retro/postmortem
2. ROOT CAUSE — 5 Whys analysis for the #1 pain point
3. PROPOSE — Solution with effort estimate (S/M/L)
4. IMPLEMENT — One improvement per sprint (start small)
5. MEASURE — Did the metric improve? By how much?
6. ITERATE — If not improved, dig deeper. If improved, tackle #2.在每个迭代中分配固定比例的产能（10-15%）用于质量改进，任务来自复盘行动项和健康评审结果。
流程：
1. 识别 — 从最新回顾会/复盘中选出Top3痛点
2. 根因分析 — 针对头号痛点开展5Why分析
3. 提案 — 给出带工作量估算（S/M/L）的解决方案
4. 实施 — 每个迭代完成一项改进（从小处着手）
5. 衡量 — 指标是否改善？改善幅度如何？
6. 迭代 — 若未改善则深入分析；若已改善则处理二号痛点。5 Whys Root Cause Analysis
5Why根因分析
The 5 Whys technique peels back surface symptoms to reveal systemic causes. The key discipline: keep asking "why" until you reach a process, system, or structural cause -- not an individual's action.
Example: Payment bug escaped to production
Problem: Users were charged twice for a single purchase.
Why 1: The payment API was called twice on form submit.
Why 2: The submit button was not disabled after the first click.
Why 3: The frontend developer did not implement button disabling.
Why 4: The acceptance criteria did not mention double-submit prevention.
Why 5: The story refinement process does not include edge case review
for payment-related stories.
Root cause: Process gap — payment stories are not reviewed for transaction
safety edge cases before development begins.
Action: Add a "Payment Safety Checklist" to the story template for any
story touching payment flows. Checklist includes: idempotency,
double-submit prevention, partial failure handling, timeout behavior.
Owner: [Product Manager] — Due: [Next sprint]5 Whys guidelines:
- Stop when you reach something the team can change (process, tool, structure). Asking "why is the budget limited?" goes too far.
- The chain may branch -- one symptom may have multiple contributing causes. Follow the most impactful branch.
- Verify each "why" with evidence, not assumption. "The developer did not write tests" -- is that true? Check the PR. Maybe tests existed but were insufficient.
- If you reach "human error" as a root cause, you have not gone far enough. Humans make errors. The system should make errors difficult or detectable.
5Why技术通过层层剥离表面症状，揭示系统性根因。关键原则：持续问“为什么”，直到找到流程、系统或结构性根因——而非个人行为。
示例：支付缺陷逃逸至生产环境
问题：用户单次购买被重复扣费。
为什么1：表单提交时支付API被调用两次。
为什么2：首次点击后提交按钮未被禁用。
为什么3：前端开发者未实现按钮禁用功能。
为什么4：验收标准未提及重复提交预防。
为什么5：涉及支付的用户故事在开发前未进行边缘场景评审。
根因：流程漏洞——支付相关用户故事在开发前未评审交易安全边缘场景。
行动：为所有涉及支付流程的用户故事模板添加「支付安全检查清单」。清单包括：幂等性、重复提交预防、部分失败处理、超时行为。
负责人：[产品经理] — 截止日期：[下一迭代]5Why指南：
- 当找到团队可改变的因素（流程、工具、结构）时停止提问。问“为何预算有限？”过于深入，超出团队可控范围。
- 因果链可能分支——一个症状可能有多个促成因素。选择影响最大的分支跟进。
- 用证据验证每个“为什么”，而非假设。“开发者未编写测试”——是否属实？查看PR。可能测试存在但不足。
- 若根因是“人为错误”，说明分析不够深入。人都会犯错，系统应使错误难以发生或可被检测。
Proposing Solutions with Effort Estimates
带工作量估算的解决方案提案
For each root cause, propose 1-3 solutions at different effort levels. Example for a recurring flaky-test problem:
Root Cause: E2E tests fail intermittently on async-loaded content
Solution A (Small — 1 day):
Replace fixed waitForTimeout calls with explicit wait-for-condition
assertions in the 5 flakiest specs.
+ Quick to implement, kills the most common flake source
− Manual, one spec at a time; new flakes can creep back in
Solution B (Medium — 1 sprint):
Solution A across the suite + add a flaky-test detector to CI that
reruns failures once and tags any test that passes on retry.
+ Automated detection, surfaces flakes before they erode trust
− Requires CI config change; reruns add pipeline time
Solution C (Large — 2 sprints):
Solution B + auto-quarantine tagged tests and route them to an
owner-assigned backlog with a 14-day fix-or-delete SLA.
+ Self-healing trust in the green build; flakes can't block releases silently
− Needs quarantine infrastructure and ownership process buy-in
Recommendation: Start with A immediately, implement B this sprint,
plan C for next quarter as strategic work.针对每个根因，提出1-3个不同工作量级别的解决方案。以下是针对重复出现的不稳定测试问题的示例：
根因：E2E测试在异步加载内容时间歇性失败
方案A（小型——1天）：
将固定waitForTimeout调用替换为显式的等待条件断言，应用于5个最不稳定的测试用例。
+ 快速实施，解决最常见的不稳定问题
− 手动操作，逐个测试用例处理；新的不稳定问题可能再次出现
方案B（中型——1个迭代）：
在全套件中实施方案A + 在CI中添加不稳定测试检测器，自动重跑失败测试，并标记重试通过的测试。
+ 自动检测，在不稳定问题影响信任前发现
− 需要修改CI配置；重跑会增加流水线时长
方案C（大型——2个迭代）：
实施方案B + 自动隔离标记的测试，并将其分配至负责人的待办列表，设定14天的修复或删除SLA。
+ 自动恢复对绿色构建的信任；不稳定测试无法静默阻塞发布
− 需要隔离基础设施和所有权流程的认可
推荐：立即实施方案A，本迭代实施方案B，将方案C规划为下一季度的战略工作。Postmortem & Retro Templates
复盘与回顾会议模板
Two heavy, copy-paste formats live in :
references/templates.md- Postmortem Template for Quality Incidents — for P0/P1 production bugs, data loss, security issues, or outages from a code change. Summary, severity/impact, UTC timeline table, root cause, 5 Whys, what tests existed / were missing, detection, immediate/short-term/long-term action tables, lessons learned.
- Retro Meeting Template — for recurring sprint/monthly quality retros: a 7-section, 30-60 minute agenda (previous action item review → data review → went well → needs improvement → root cause discussion → new action items → close) plus facilitator notes.
Both open by reviewing the previous retro's action items — that closed loop is the accountability mechanism; without it, items vanish silently.
两个可直接复制粘贴的模板位于中：
references/templates.md- 质量事件复盘模板——适用于P0/P1级生产缺陷、数据丢失、安全问题或代码变更导致的故障。包含摘要、严重程度/影响、UTC时间线表格、根因、5Why分析、现有测试/缺失测试、检测方式、立即/短期/长期行动项表格、经验教训。
- 回顾会议模板——适用于定期迭代/月度质量回顾：7个环节、30-60分钟议程（过往行动项评审→数据评审→做得好的地方→需改进的地方→根因讨论→新行动项→结束）加上主持人提示。
两个模板均以评审上一次回顾会的行动项开头——这种闭环是问责机制；若无此环节，行动项会悄无声息地消失。
Anti-Patterns
反模式
Blame-Driven Postmortems
追责式复盘
Focusing on who made the mistake rather than what system allowed the mistake to reach production. Blame creates fear. Fear creates hiding. Hiding creates bigger incidents. When the question is "who wrote this bug?" people learn to avoid visibility. When the question is "what process gap allowed this?" people learn to improve the process.
聚焦于谁犯了错，而非系统为何允许错误进入生产环境。追责会引发恐惧，恐惧会导致隐瞒，隐瞒会引发更大的事件。当问题是“谁写的这个bug？”，人们会学会避免暴露；当问题是“哪个流程漏洞导致了这个问题？”，人们会学会改进流程。
Postmortems Without Action Items
无行动项的复盘
A cathartic discussion that produces understanding but no change. If the meeting ends without specific, assigned action items, the same problem will recur. Worse, the team learns that postmortems are therapy sessions, not improvement tools.
一场宣泄情绪的讨论，仅产生理解却无任何改变。若会议结束时未产出具体的、指派负责人的行动项，同一问题会再次发生。更糟的是，团队会认为复盘只是疗愈会话，而非改进工具。
Action Items Without Follow-Through
无跟进的行动项
Generating action items that go into a backlog and are never prioritized. This is worse than no action items because it creates the illusion of improvement. If postmortem actions are not completed within 2 sprints, escalate. Action items die for predictable reasons — audit your closure rate against this checklist before blaming "we forgot":
- No owner. Items assigned to a team rather than a person become nobody's job. Fix: assign to a named person with enough context to start.
- No due date. "Soon" is not a date. Fix: a specific sprint or calendar date.
- Scope too big. "Refactor the test framework" cannot land in a sprint. Fix: break it into items that each fit a single PR.
- No review at the start of the next retro. Without a forced check-in, items vanish silently. Fix: a standing calendar slot that opens every retro with a closed-loop review.
- No metric attached. If completing the item doesn't move a number you can name, you can't tell whether it worked.
Counter-pattern: open every retro with a 5-minute "previous action items" review. Mark each as Done / In Progress (with current ETA) / Dropped (with reason).
生成的行动项进入待办列表后从未被优先处理。这比无行动项更糟，因为它制造了改进的假象。若复盘行动项在2个迭代内未完成，需升级处理。行动项无法完成的原因可预见——在归咎于“我们忘了”前，对照以下清单审核完成率：
- 无负责人：指派给团队而非个人的行动项会变成无人负责的工作。解决方法：指派给有足够背景知识可启动工作的具体人员。
- 无截止日期：“尽快”不是具体日期。解决方法：指定具体迭代或日历日期。
- 范围过大：“重构测试框架”无法在一个迭代内完成。解决方法：拆分为可在单个PR中完成的小项。
- 下一次回顾会未评审：若无强制检查，行动项会悄无声息消失。解决方法：在每次回顾会开头设置固定的5分钟“过往行动项”评审环节。
- 无关联指标：若完成行动项无法改变某个可量化的指标，则无法判断其是否有效。
应对模式：每次回顾会开头用5分钟评审“过往行动项”，标记每个行动项为已完成/进行中（含当前预计完成时间）/已取消（含原因）。
Postmortems Only After Incidents
仅在事件发生后开展复盘
Waiting for a production fire to conduct a quality review. Proactive health reviews (test suite health, coverage trends, flaky test inventory) prevent incidents. Conduct proactive reviews monthly. Reactive incident postmortems supplement the proactive cadence — they do not replace it.
等待生产事故发生才进行质量评审。预防性健康评审（测试套件健康、覆盖率趋势、不稳定测试清单）可预防事件。每月开展预防性评审。响应式事件复盘是对预防性节奏的补充——而非替代。
Root Cause Analysis That Stops Too Early
过早终止的根因分析
"The developer did not write a test" is not a root cause. It is a symptom. Why did they not write a test? Was the framework hard to use? Was there no time? Was there no requirement? Was there no pairing or review? Stopping at the individual level prevents systemic improvement.
“开发者未编写测试”不是根因，只是症状。为何他们未编写测试？框架难以使用？没时间？无要求？无结对编程或评审？停留在个人层面会阻碍系统性改进。
Vague Action Items
模糊的行动项
"Improve test coverage" and "be more careful with deployments" are not action items. They cannot be tracked, measured, or verified. Compare: "Add integration tests for payment webhook handling, covering success, failure, and timeout scenarios. Owner: Alex. Due: Sprint 14. Verification: PR merged with 3 new integration tests passing in CI."
“提高测试覆盖率”和“部署时更加谨慎”不是行动项。它们无法被追踪、衡量或验证。对比：“为支付Webhook处理添加集成测试，覆盖成功、失败和超时场景。负责人：Alex。截止日期：第14迭代。验证方式：PR已合并，3个新集成测试在CI中通过。”
Data-Free Retros
无数据的回顾会
Running quality retrospectives based on feelings and opinions rather than data. "It feels like we have more bugs lately" might be true or might be recency bias. Check the data: is the escaped bug count actually increasing? Where are the bugs concentrated? Without data, the team solves the loudest problem, not the most important one.
基于感受和意见开展质量回顾会。“感觉最近bug更多了”可能属实，也可能是近因偏差。查看数据：逃逸缺陷数量是否真的增加？bug集中在哪些区域？若无数据，团队会解决最受关注的问题，而非最重要的问题。
Verification
验证
The artifact is the written postmortem plus its tracked, closed-loop action items. Prove it landed — smallest check first.
bash
undefined产出物为书面复盘报告及其可追踪的闭环行动项。按以下步骤验证是否完成——从最基础的检查开始。
bash
undefinedEvery action item became a real, owned, dated ticket — not a doc bullet.
每个行动项都已转化为真实的、有负责人和截止日期的工单——而非文档中的项目符号。
(gh example; swap for jira issue list
/ Linear API as appropriate)
jira issue list（以下为GitHub示例；可替换为jira issue list
/ Linear API等）
jira issue listgh issue list --label postmortem-action --json number,title,assignees,milestone
| jq '[.[] | select(.assignees == [] or .milestone == null)]'
| jq '[.[] | select(.assignees == [] or .milestone == null)]'
gh issue list --label postmortem-action --json number,title,assignees,milestone
| jq '[.[] | select(.assignees == [] or .milestone == null)]'
| jq '[.[] | select(.assignees == [] or .milestone == null)]'
Expect: [] (empty). Any item missing an owner or due milestone is not done.
预期结果：[] （空数组）。任何缺少负责人或截止里程碑的项均未完成。
The escaped defect's timeline is reconstructable from evidence, not memory.
逃逸缺陷的时间线可从证据（而非记忆）中重建。
git log --since="<introduced-date>" --until="<detected-date>" --oneline -- <affected/path>
git log --since="<引入日期>" --until="<发现日期>" --oneline -- <受影响路径>
Expect: the introducing commit is in this range and named in the postmortem.
预期结果：引入缺陷的提交在此范围内，并在复盘报告中提及。
The fix/regression test the action item promised actually exists and passes.
行动项承诺的修复/回归测试确实存在且通过。
git log --grep="<INCIDENT-ID>" --oneline # the fix commit references the incident
<your test runner> <new regression test path> # exits 0
Then confirm by reading: the 5 Whys ends on a process/tool/structure cause (not "developer didn't write a test"), and both the action-item-closure rate and the escaped-defect rate are recorded — not just one.git log --grep="<事件ID>" --oneline # 修复提交引用了事件ID
<你的测试运行器> <新回归测试路径> # 返回0（测试通过）
随后通过阅读验证：5Why分析终止于流程/工具/结构性根因（而非“开发者未编写测试”），且同时记录了行动项完成率和缺陷逃逸率——而非仅记录其中一个。Done When
完成标准
- Escaped defect timeline reconstructed (introduced, released, detected, resolved) with supporting evidence from commit history and bug tracker.
- 5 Whys root cause analysis completed and stopped at a systemic cause (process / tool / structure), not at "developer didn't write a test."
- Test gap identified and mapped to a specific coverage hole (missing test type, missing scenario, or missing area).
- Action items assigned with named owners and due dates, added to the team's work tracker with a postmortem tag.
- Findings shared with the team in a written summary — not siloed in QA or lost in a private document.
- Action-item-closure-rate tracked alongside escaped-defect rate (both metrics, not one); for incident postmortems, both are derivable from the incident platform's native follow-through tracking.
- If AI SRE tooling is in use, the AI-drafted timeline and candidate root causes are recorded as input, and a named blameless RCA owner (not the incident commander) signed off on the human-authored 5 Whys and action items.
- 已重建逃逸缺陷的时间线（引入、发布、发现、解决），并配有提交历史和缺陷追踪工具的支持证据。
- 已完成5Why根因分析，且终止于系统性根因（流程/工具/结构），而非“开发者未编写测试”。
- 已识别测试漏洞，并映射到具体的覆盖缺口（缺失测试类型、缺失场景或缺失区域）。
- 行动项已指派具体负责人和截止日期，添加至团队工作追踪工具并带有复盘标签。
- 已将发现结果以书面摘要形式分享给团队——而非仅保存在QA手中或私人文档中。
- 已同时追踪行动项完成率和缺陷逃逸率（两个指标，而非单个）；对于事件复盘，两个指标均可从事件平台的原生跟进追踪数据中获取。
- 若使用AI SRE工具，已记录AI生成的时间线和候选根因作为输入，且指定的无责RCA负责人（而非事件指挥官）已签署确认人工撰写的5Why分析和行动项。
Related Skills
相关技能
- qa-metrics — Provides the data (defect escape rate, flakiness rate, coverage trends) that postmortems analyze and act upon. Use it for the ongoing dashboard; use this skill for the analysis session.
- test-reliability — Flaky test classification and quarantine management, which feeds into test suite health reviews.
- test-strategy — When postmortems reveal systemic gaps that recur across quarters, the test strategy is the document that gets updated.
- shift-left-testing — Many postmortem action items are shift-left practices: earlier testing, better requirements, dev/QA pairing.
- release-readiness — Quality gates and release criteria should be updated based on postmortem findings; use it for live go/no-go, not retrospective analysis.
- qa-metrics——提供复盘分析和行动所需的数据（缺陷逃逸率、不稳定率、覆盖率趋势）。该技能用于持续仪表盘；本技能用于分析会话。
- test-reliability——不稳定测试分类和隔离管理，为测试套件健康评审提供数据。
- test-strategy——当复盘揭示跨季度重复出现的系统性漏洞时，需更新测试策略文档。
- shift-left-testing——许多复盘行动项属于左移测试实践：更早测试、更完善的需求、开发/QA结对编程。
- release-readiness——质量门禁和发布标准应根据复盘结果更新；该技能用于实时准入决策，而非回顾性分析。
Reference Files (in references/
)
references/参考文件（位于references/
目录下）
references/- templates.md — Copy-paste Postmortem Template for Quality Incidents, Retro Meeting Template + facilitator notes, and the single-bug Escaped Bug Analysis worksheet.
- templates.md——可直接复制的质量事件复盘模板、回顾会议模板+主持人提示，以及单缺陷逃逸缺陷分析表。