---
title: QA Team OKR / KPI 設計指南 — 從 vanity metric 到真正影響業務
description: QA Lead 怎麼設 team 目標。OKR vs KPI 差別、避免 vanity metric（自動化覆蓋率陷阱）、跟業務指標串聯、季度 review 範本。
category: career
tags: [okr, kpi, qa-metrics, team-goals, leadership]
date: 2026-06-11
---

# 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 一次說清

```mermaid
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 陷阱

```mermaid
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 流程

```mermaid
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 應該每週看的：

```mermaid
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 對齊

```mermaid
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%**。

## 反模式

```mermaid
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 設定範本

```markdown
# 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 句話

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

## 最後

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