QA Team OKR / KPI 設計指南 — 從 vanity metric 到真正影響業務

「Test coverage 80%」「Bug 數降 20%」是 99% QA team 在用的 KPI，但這些都是 vanity metric — 量了沒人在乎。這篇講怎麼設 QA team 真正有影響力的目標。

這篇講 OKR + KPI。SLA / SLO / SLI 是 SRE 領域。

Objective: 我們要達成什麼 — 質性、激勵人心
Key Result: 怎麼知道達成了 — 量化、可驗證

爛例子：

O: 改善 QA quality
KR1: 增加自動化覆蓋率
KR2: 減少 bug

「Quality」是空的。「增加」「減少」沒目標。

好例子：

O: 讓上線後使用者體驗不被品質問題打斷

KR1: Production P0 bug 從 5/月 → 1/月
KR2: 客服 quality-related ticket 從 30/月 → 10/月
KR3: NPS 中提到「bug」的負評從 12% → 3%

每個 KR 都是業務角度、不是 QA 內部數字。

1. Test Coverage（最毒的指標）

「80% line coverage」可能 critical path 全沒測。

用什麼取代：

• Critical path coverage：top 10 business flow 100% E2E
• Mutation testing score：測試品質、不只 line coverage
• Defect detection rate：CI 抓到 vs 漏到 prod 的比例

2. Bug 數絕對值

100 個 P3 typo bug ≠ 1 個 P0 結帳壞掉。

用什麼取代：

• Escaped bug：上線後抓到的 bug 數
• Severity-weighted bug count：(P0 × 100 + P1 × 10 + P2 × 1)
• MTTR：bug 從發現到修好平均時間

3. 自動化案件數

數量沒意義、穩定度跟覆蓋的 risk 才有意義。

用什麼取代：

• Stable case count：過去 30 天 pass rate ≥ 95% 的 case
• Flaky rate：flaky case / total case
• Risk coverage：critical path 自動化覆蓋率

4. QA Velocity（最被誤用）

QA story point 跟 dev 不可比、總和也沒意義。

用什麼取代：

• QA cycle time：從 PR 進 review 到 QA approve 的時間
• PR throughput：每週 merge 的 PR 數
• Bottleneck index：sprint 內因 QA 拖延的 story 數

5. 回歸 case 數

「我們有 5000 個 regression case」聽起來厲害、其實是負擔。

用什麼取代：

• Critical regression coverage：top risk 是否都覆蓋
• Regression effectiveness：跑出的 fail 真的是 bug 的比例
• Test maintenance hours：花在維護的時間

Junior / Mid QA OKR

O: 把我 own 的 X 模組品質拉到 team 最佳

KR1: 該模組 escaped bug 從 8/月 → 2/月
KR2: 該模組 critical path 100% 自動化
KR3: PR review 平均回應時間 < 4 小時

Senior QA OKR

O: 提升 team 整體交付速度與品質

KR1: Lead 一個 cross-team initiative（spec review pilot）
KR2: 把 flaky rate 從 12% → 3%
KR3: Mentor 1 個 junior，他升 Mid

QA Lead OKR

O: 建立 quality culture，讓 dev 主動關心 quality

KR1: 把 quality discussion 放進每個 sprint planning（100% sprint）
KR2: Dev 寫 unit test coverage 從 60% → 80%
KR3: Spec review 流程上線、過去 sprint 80% feature 有走流程
KR4: Hire 1 個 senior、留住所有現有人

QA Manager / Director OKR

O: 讓 quality 變成公司可量化的競爭優勢

KR1: NPS 中 quality 相關正評從 20% → 40%
KR2: P0 production incident 從 1/月 → 0
KR3: 客服 quality-related ticket 從 30 → 5/月
KR4: 跨 team QA practices 落地（4 個 team 全部跟）

1. 用業務指標、不用 QA 內部指標

爛 KR：「自動化覆蓋率 80%」 好 KR：「Production P0 bug 從 X → Y」

業務指標 = CEO 也會關心的事。

2. 數量少、聚焦

QA team 一季 3-5 個 KR、不超過 5。多了沒人記得。

3. Stretch goal，不是 commitment

OKR 是「努力可能達到 70%」、不是 100% commitment。 100% 達標代表設太低。

4. 量化、可驗證

爛 KR：「改善 dev / QA 合作」 好 KR：「Dev 在 retro 給 QA 滿意度從 6/10 → 8/10」

每週 check-in（15 分鐘）

- 上週進度（每個 KR 一個 number）
- 這週 priority
- Blocker

Mid-quarter review

- 每個 KR 預測會達成幾 %
- 識別 at-risk 的 KR
- 重新分配資源 / 砍 KR

Q 結束 scoring

每個 KR 給分 0.0-1.0：

0.0-0.3: 失敗、要 analysis
0.4-0.6: 進步但未達標
0.7-1.0: 成功
> 1.0: 設太低、下 Q 拉高

整 team 平均 0.7 是健康的。

OKR 之外、Lead 應該每週看的：

工具：Grafana / Looker / Notion / Google Sheets 都可。重點是有 dashboard、不是用什麼。

QA OKR 必須 ladder up 到 company OKR。否則 CEO 不會買單。

OKR ≠ 個人績效評估。

OKR: team 的目標、stretch 達 70%
個人績效: 對 OKR 的貢獻 + behaviors + growth

個人 70-100% 達成是好的、不需要每個 KR 100%。

# Q3 2026 QA Team OKR

讓 [team] 在 [business metric] 上贏過 [競品 / 上 Q]

KR1: [Outcome metric, not output]

• Baseline: [現在值]
• Target: [Q3 結束值]
• Owner: [Name]
• Weekly check-in: [Day]

KR2: ...

KR3: ...

• Dashboard: [link]
• Weekly check-in: [day/time]
• Mid-Q review: [date]

• [Risk 1] - Mitigation: ...

• [Team X] - what we need from them

1. 設 OKR 是收斂注意力、不是擴張責任
2. 業務指標 > QA 內部指標
3. 3-5 個 KR、不要 10 個
4. 沒達標不是失敗、是 learning
5. OKR 的價值 50% 在過程、50% 在結果

QA 最大的存在感問題、是「我們做的事看起來像支援、不像產出」。好的 OKR 把 QA 工作翻譯成業務語言、讓所有人看見影響。從這季開始換掉「自動化覆蓋率」、換成「上線後體驗」、6 個月後 CEO 會主動找你聊 QA 預算。