---
title: Sprint 流程中 QA 的位置 — 進場時機、估點、DoR / DoD 完整指南
description: Agile sprint 各階段 QA 該做什麼？什麼時候進場？要不要估點？Definition of Ready / Done 怎麼設？給轉 Scrum 的 QA 的實戰手冊。
category: career
tags: [agile, scrum, sprint, qa-進場, 估點, dor, dod]
date: 2026-06-09
---

# Sprint 流程中 QA 的位置 — 進場時機、估點、DoR / DoD 完整指南

「QA 應該在 sprint 第幾天進場？」、「QA 要不要估點？」、「DoD 該寫什麼？」這三個問題每家公司答案都不同。這篇把 Scrum 的標準流程攤開，**告訴你 QA 在每個儀式該做什麼、怎麼跟團隊談**。

## Scrum 的 5 個儀式 + QA 角色

```
Backlog Refinement → Sprint Planning → Daily Stand-up → Sprint Review → Retro
     (Grooming)       (規劃 sprint)     (每日)          (Demo)         (回顧)
```

| 儀式 | QA 該做的 |
|------|---------|
| **Refinement / Grooming** | 對 story 提澄清問題、估 QA 工時、找風險 |
| **Sprint Planning** | 確認 QA capacity、加 QA tasks、定 DoR / DoD |
| **Daily Stand-up** | 回報 test 進度、提 blocker、要求 dev 配合 |
| **Sprint Review (Demo)** | Demo 前先驗、demo 中協助回答品質問題 |
| **Retrospective** | 提 QA 角度的 process 改善（流程、工具、溝通） |

QA 不只「測試階段才出現」— **整個 sprint 都該在場**。缺席任何一個儀式都會出代價。

## QA 進場時機：「左移」（Shift Left）

### 傳統做法（爛）

```
[Day 1-7] Dev 寫 code
[Day 8-9] QA 開始測試
[Day 10] 緊急修 bug
[Day 11] 又發現新 bug
[Day 14] 含 bug 上線
```

問題：
- QA 9 天才接觸 → 對 story 沒概念
- Bug 在 sprint 末才出 → 修不完 → 推下版
- QA 跟 dev 沒共識 → 互相抱怨

### Shift Left 做法（好）

```
[Refinement, sprint -3] QA 提澄清問題、列風險 case
[Planning, sprint Day 0] QA 加 test plan task、估 QA 工時
[Day 1-3] Dev 寫 code + Unit test，QA 寫 test cases、準備自動化
[Day 4-7] Dev API 完成，QA 開始 API test + 整合 test
[Day 8-9] Dev 改 bug + 收尾，QA 跑回歸
[Day 10] Demo 前驗收
[Day 11-14] Buffer + 自動化補強
```

關鍵：**QA 從 sprint Day 0 就同步進場**，不是等開發完才出現。

### Shift Left 的具體做法

1. **Spec review 階段** → 提需求漏洞（見 [[spec-review-checklist]]）
2. **Story 拆分時** → 問「測試怎麼跑」這個問題
3. **Dev 寫 code 中** → 用 mock / 玩 Postman 提前測 API contract
4. **Code review 也參與** → 看到「奇怪的程式碼」舉手
5. **TDD / BDD** → 跟 dev 一起寫測試案例

## QA 估點：要不要、怎麼估

### 問題的核心

Scrum 教科書說「team 一起估」，但實務上：

- **如果 QA 不估**：dev 估完不含 QA 工時 → sprint 滿載 → QA 加班補
- **如果 QA 估**：估錯了被質問、估準了被視為瓶頸

**結論**：QA **要估**，但用不同的數字。

### 兩種估法

#### 方法 A：QA 跟 dev 共用同一個 story point

- Story point 含 dev + QA 全部工時
- 估的時候要把 QA test、寫自動化、修 bug 一起估
- 例如：dev 覺得 3 點、QA 覺得加 test plan + 自動化要 2 點 → 共識 5 點

**優點**：清楚的 sprint capacity。
**缺點**：QA 估太多時被 dev 嫌，QA 估太少時被自己拖累。

#### 方法 B：QA 估獨立工時（小時）

- Dev 用 story point 估、QA 用工時估
- 兩者分開 capacity plan
- 例如：dev 估 3 點（約 3 天）、QA 估 8 小時 test plan + 4 小時跑 + 4 小時補自動化

**優點**：QA 工時透明、不被 story point 黑盒掉。
**缺點**：需要團隊接受「story point 不含 QA」這個前提。

### 我的建議

新團隊 / Scrum 純粹派 → 方法 A（共用 story point）
成熟團隊 / QA 工作量變動大 → 方法 B（小時）

**死規矩**：「QA 估的工時 ≥ dev 估的 30%」，否則 spec 太簡單或 QA 太樂觀。

### 估什麼

QA 要估的不只「跑測試」，還有：

| 項目 | 工時估算 |
|------|---------|
| Spec review + 提問 | 1-3 hr |
| 寫 test plan / test cases | 2-8 hr（依 story 大小） |
| 探索性測試 | 2-4 hr |
| 跑迴歸（手動） | 2-8 hr |
| 寫自動化（新增 case） | 2-16 hr |
| 跨瀏覽器 / 跨裝置 | 2-4 hr |
| Bug 重現 + 報告 | 預留 sprint 20% buffer |
| 跟 dev / PM 來回溝通 | 預留 sprint 10% |

**total 通常是「dev 工時 × 0.3-0.5」**。低於這個比例可能漏估。

## Definition of Ready (DoR) — QA 的入場護城河

**DoR = story 能進 sprint 的條件**。不滿足就不該進 sprint。

### QA 該堅持的 DoR 條件

- [ ] Spec 有寫，且 QA 已 review、無 P0 / P1 問題
- [ ] User story 有明確的「Acceptance Criteria」（驗收條件）
- [ ] 跨系統依賴已釐清（哪些第三方、哪些舊功能）
- [ ] Test environment 可用、test data 有準備好
- [ ] UI mockup（如有）已 final
- [ ] Edge case 至少列出 5 個
- [ ] 此 story 不阻擋其他 P0 work

**沒過 DoR 的 story 進 sprint 是團隊的災難**。QA 在 grooming 要敢喊停。

### 典型反例

PM：「這個就是加個按鈕嘛、簡單啦」
QA 應該問：
- 按鈕在哪個頁面？只在 desktop 還是 mobile 也有？
- 點下去做什麼？需要 auth 嗎？權限怎處理？
- 失敗時 UX？
- 成功時要不要送訊息給 backend / log？
- 有沒有需要 i18n？

5 個問題下去、PM 講不清楚 = DoR 沒過。

## Definition of Done (DoD) — QA 的出場保證

**DoD = story 算完成的條件**。低於這個不該被算進 sprint velocity。

### QA 該堅持的 DoD 條件

- [ ] 所有 Acceptance Criteria 都通過
- [ ] Unit test coverage ≥ 團隊定的標準（通常 80%）
- [ ] E2E test 新增 cover 此 story 的 P0 路徑
- [ ] 自動化測試在 CI 跑通
- [ ] 跨瀏覽器測試（Chrome + 至少一個其他）
- [ ] Accessibility 基本檢查（aria、keyboard nav）
- [ ] 效能 baseline 沒退步（LCP、INP）
- [ ] 無 P0 / P1 bug
- [ ] 文件 / changelog 已更新
- [ ] PM 已 sign-off

**「dev 寫完 code 就算 done」是反 Scrum 的**。Done = 可以上 prod。

### DoD 跟 DoR 的差別

| | DoR | DoD |
|---|-----|-----|
| 時機 | 進 sprint 前 | 結 sprint 前 |
| 守門人 | QA + PM | QA + Tech Lead |
| 內容 | 需求清晰度 | 實作完整度 |
| 沒過會 | 退回 backlog | 移到下 sprint（不算 velocity） |

## QA 在 Daily Stand-up 該講什麼

### 爛模板

「昨天測了 login，今天繼續測。」

### 好模板

```
昨天:
- 跑了 cart 模組 25 個 case，3 個 fail（已開 ticket #234, #235）
- API #234 我已重現、附 video，等 dev 排修

今天:
- 跑 checkout 整合測試（依賴 Joe 的 PR #102）
- 開始寫 cart 的 E2E 自動化

Blocker:
- staging 環境的 payment mock 壞了，需要 DevOps 配合
- PR #102 還沒 merge，影響我下午的測試
```

清楚的「完成 / 今天 / 阻礙」+ 具體 ticket / PR 編號 → **stand-up 5 分鐘內讓全 team 知道 QA 狀態**。

## QA 在 Sprint Review (Demo) 的角色

### 別讓 dev 自己 demo

Dev demo 容易：
- 跑 happy path，跳過邊界
- 美化 bug、含糊帶過
- 不展示 edge case

### QA 要做的

1. **Demo 前一天先驗** — 列「demo 中可能爆炸的點」
2. **Demo 中協助回答品質問題**
   - 「這支援 mobile 嗎？」→ QA 答（我有測 iOS + Android）
   - 「有測 dark mode 嗎？」→ QA 答
3. **建議的 demo 順序** — Happy path → 一個邊界 → 一個 fail recovery
4. **誠實回報已知問題** — 「這個 story done 了，但有個已知 P2 bug 排下版」

## QA 在 Retrospective 該帶什麼話題

### 不要只講「測試辛苦」

爛例子：「這 sprint 太多 bug、改不完」→ 空話、沒解法。

### 帶 process 改善

好例子：
- 「上 sprint Story #X 三次推延，原因都是 spec 不全。提議下次 grooming 加 spec checklist 5 題必答」
- 「自動化 E2E 跑 30 分鐘，flaky 5%。下 sprint 排 4 小時補強」
- 「Bug ticket 平均回應 2 天，提議 dev 每天早上花 30 分鐘 triage」

QA 在 retro 提的議題往往是**整個 team process 最有改善空間的地方**。不要藏私。

## Sprint 各階段 QA 行事曆模板

```
[Sprint -3 days] Refinement
  - 讀 PRD、Spec
  - 列澄清問題（用 [[spec-review-checklist]]）
  - 列高風險 case

[Sprint Day 0] Planning
  - 確認 capacity（不超載）
  - 加 QA tasks（test plan、自動化）
  - 確認 DoR / DoD

[Day 1-3] Dev 寫 code
  - 寫 test cases
  - 設定 test environment
  - 跑 API 早期測試（用 mock）

[Day 4-6] Dev API 完成
  - API integration test
  - 開始準備 E2E case

[Day 7-9] Dev UI 完成
  - 全功能 testing
  - Cross-browser
  - 探索性測試

[Day 10-12] Bug 修復 + 回歸
  - Bug verification
  - Regression
  - 自動化補強

[Day 13] Demo 前一天驗
  - Demo dry run
  - 列已知 issue

[Day 14] Demo + Retro
  - 協助 demo
  - 提 retro 議題
```

## 常見爭議與應對

### Q1: 「QA 估太多 — sprint 容不下」

不要直接砍 QA 工時。**砍 story scope** 或 **砍 sprint 範圍**。

提議：「這個 story 我估 8 小時 QA、dev 估 3 天。如果想 fit，建議把 X 子功能拆下 sprint。」

### Q2: 「QA 還沒測完就要 demo」

舉手喊停。「我還有 5 個 case 沒跑、demo 風險高。建議延一天 demo」。

如果硬要 demo，**自己 demo 前驗一次、列已知問題、誠實在 demo 中說**。

### Q3: 「dev 給的 PR 太晚、來不及測」

Retro 講。提議：

- PR submit deadline 設在 sprint Day 9
- 之後的 PR 自動延下 sprint
- 用 trunk-based + feature flag 可以分散 PR

### Q4: 「PM 半路加 story」

DoR 沒過。直接拒。

「這個 story 沒走 grooming、沒估點、沒 DoR check，這 sprint 不收。下 sprint 我幫你 priority 提前。」

## 反模式

1. **QA 等 dev 寫完才看 spec** — 進場太晚、改不完
2. **QA 不估點** — 工時隱形、永遠加班
3. **DoD 沒包 QA** — Story 算 done 了 bug 還沒修 → 下版炸
4. **Daily 只說「測試中」** — 沒人知道你在幹嘛
5. **Retro 只抱怨** — 沒提 process 改善

## 最後

QA 在 sprint 不是「跑測試的」，是「**整個流程的品質負責人**」。從 grooming 提問、planning 估點、daily 透明、demo 護航、retro 改 process — **每個儀式都要在場、都要發聲**。做好這些，bug 自然少、上線自然順、團隊自然會給你資深的位置。