QA Team OKR / KPI 設計指南 — 從 vanity metric 到真正影響業務
「Test coverage 80%」「Bug 數降 20%」是 99% QA team 在用的 KPI，但這些都是 vanity metric — 量了沒人在乎。這篇講怎麼設 QA team 真正有影響力的目標。
OKR vs KPI vs SLA vs SLI vs SLO 一次說清
flowchart LR
Direction[目標方向] --> O[OKR<br>季度方向]
Measure[持續量測] --> K[KPI<br>常態指標]
Promise[對外承諾] --> SLA[SLA<br>合約承諾]
SLI[實際量到的] --> SLO[SLO<br>內部目標]
O --> Diff[OKR vs KPI:<br>OKR 改進方向<br>KPI 持續觀察]
style O fill:#06b6d4,color:#fff
style K fill:#10b981,color:#fff
style SLA fill:#ef4444,color:#fff
style SLO fill:#f59e0b,color:#fff
| 詞 | 用途 | 例子 |
|---|---|---|
| OKR | 季度目標、要改變的 | 「Production P0 bug 從 5/月 → 1/月」 |
| KPI | 常態觀察、不一定要動 | 「CI pass rate」「MTTR」 |
| SLA | 給客戶 / 業務的承諾 | 「99.9% uptime」 |
| SLO | 內部目標、SLA 的 buffer | 「99.95% uptime」 |
| SLI | 實際量到的數字 | 上週 uptime 99.97% |
這篇講 OKR + KPI。SLA / SLO / SLI 是 SRE 領域。
OKR 的本質：Objective + Key Result
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 內部數字。
5 個 vanity metric 陷阱
mindmap
root((Vanity<br>Metrics 陷阱))
Test 覆蓋率
只看數字
不看哪些 path
80% 但 critical 沒測
Bug 數
只看絕對值
不看 severity
改用「逃逸 bug」
自動化案件數
寫越多越好
flaky case 也算
改用 stable case
QA Velocity
QA story point
跟 dev 等價沒意義
改用 cycle time
回歸 case 數
越多越好?
應該越少越好
改用 risk coverage
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：花在維護的時間
OKR 起手範本（按 QA 角色）
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 全部跟）
OKR 設定時的 4 個原則
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」
季度 OKR review 流程
flowchart LR
W1[Q 開始]:::start --> W2[設定 KR]
W2 --> W3[每週 check-in]
W3 --> W4[Mid-quarter review]
W4 --> W5[Q 結束 score]
W5 --> W6[Retro]
W6 --> Next[下 Q 設定]
classDef start fill:#06b6d4,color:#fff
style W2 fill:#a855f7,color:#fff
style W3 fill:#10b981,color:#fff
style W4 fill:#f59e0b,color:#fff
style W5 fill:#ef4444,color:#fff
style W6 fill:#a855f7,color:#fff
style Next fill:#06b6d4,color:#fff
每週 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 是健康的。
KPI Dashboard（常態觀察）
OKR 之外、Lead 應該每週看的：
mindmap
root((QA Lead<br>每週看的<br>KPI))
交付
Cycle time
PR throughput
Sprint commit ratio
品質
Escaped bug
MTTR
Severity-weighted bug
自動化
Pass rate
Flaky rate
Stable case count
團隊
Velocity 個人趨勢
1-on-1 sentiment
Burnout signal
Process
Spec review 涵蓋率
DoR / DoD compliance
Code review 速度
工具：Grafana / Looker / Notion / Google Sheets 都可。重點是有 dashboard、不是用什麼。
跟 dev / PM team 對齊
flowchart TD
QA[QA OKR] --> Align{對齊到}
Align --> Eng[Eng OKR]
Align --> Prod[Product OKR]
Align --> Co[Company OKR]
Eng --> E1["『縮短 cycle time』"]
Prod --> P1["『NPS 提升』"]
Co --> C1["『Q4 上線 X 大功能』"]
QA --> Q1["QA KR: 降 escaped bug<br>→ 支持 NPS"]
QA --> Q2["QA KR: 縮 QA cycle time<br>→ 支持 cycle time"]
QA --> Q3["QA KR: 大功能 0 P0 bug<br>→ 支持上線"]
style QA fill:#06b6d4,color:#fff
style Co fill:#ef4444,color:#fff
QA OKR 必須 ladder up 到 company OKR。否則 CEO 不會買單。
對 individual 績效評估的影響
OKR ≠ 個人績效評估。
OKR: team 的目標、stretch 達 70%
個人績效: 對 OKR 的貢獻 + behaviors + growth
個人 70-100% 達成是好的、不需要每個 KR 100%。
反模式
flowchart TD
Anti[OKR 反模式] --> A1[設 10+ 個 KR]
Anti --> A2[KR 全部 100% 達成]
Anti --> A3[KR 不 measurable]
Anti --> A4[只 QA 內部指標]
Anti --> A5[設了不 check-in]
Anti --> A6[未達標就責怪]
Anti --> A7[Q 中途偷改 KR]
style A1 fill:#ef4444,color:#fff
style A2 fill:#ef4444,color:#fff
style A3 fill:#ef4444,color:#fff
style A4 fill:#ef4444,color:#fff
style A5 fill:#ef4444,color:#fff
style A6 fill:#ef4444,color:#fff
style A7 fill:#ef4444,color:#fff
| 反模式 | 解法 |
|---|---|
| 設 10+ KR | 砍到 3-5 |
| 全部 100% | 設更難的 stretch |
| 不 measurable | 加 number + deadline |
| 內部指標 | 改業務指標 |
| 不 check-in | 每週 15 分鐘 |
| 責怪 | 改成「為什麼沒達」learning |
| 中途改 | 改情境而非 KR、或正式 mid-Q review |
一頁式 OKR 設定範本
# Q3 2026 QA Team OKR
## Objective
讓 [team] 在 [business metric] 上贏過 [競品 / 上 Q]
## Key Results
### KR1: [Outcome metric, not output]
- Baseline: [現在值]
- Target: [Q3 結束值]
- Owner: [Name]
- Weekly check-in: [Day]
### KR2: ...
### KR3: ...
## How we measure
- Dashboard: [link]
- Weekly check-in: [day/time]
- Mid-Q review: [date]
## Risks
- [Risk 1] - Mitigation: ...
## Dependencies
- [Team X] - what we need from them
給 Lead 的 5 句話
- 設 OKR 是收斂注意力、不是擴張責任
- 業務指標 > QA 內部指標
- 3-5 個 KR、不要 10 個
- 沒達標不是失敗、是 learning
- OKR 的價值 50% 在過程、50% 在結果
最後
QA 最大的存在感問題、是「我們做的事看起來像支援、不像產出」。好的 OKR 把 QA 工作翻譯成業務語言、讓所有人看見影響。從這季開始換掉「自動化覆蓋率」、換成「上線後體驗」、6 個月後 CEO 會主動找你聊 QA 預算。