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 的具體做法
- Spec review 階段 → 提需求漏洞（見 [[spec-review-checklist]]）
- Story 拆分時 → 問「測試怎麼跑」這個問題
- Dev 寫 code 中 → 用 mock / 玩 Postman 提前測 API contract
- Code review 也參與 → 看到「奇怪的程式碼」舉手
- 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 要做的
- Demo 前一天先驗 — 列「demo 中可能爆炸的點」
- Demo 中協助回答品質問題 - 「這支援 mobile 嗎？」→ QA 答（我有測 iOS + Android） - 「有測 dark mode 嗎？」→ QA 答
- 建議的 demo 順序 — Happy path → 一個邊界 → 一個 fail recovery
- 誠實回報已知問題 — 「這個 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 提前。」
反模式
- QA 等 dev 寫完才看 spec — 進場太晚、改不完
- QA 不估點 — 工時隱形、永遠加班
- DoD 沒包 QA — Story 算 done 了 bug 還沒修 → 下版炸
- Daily 只說「測試中」 — 沒人知道你在幹嘛
- Retro 只抱怨 — 沒提 process 改善
最後
QA 在 sprint 不是「跑測試的」，是「整個流程的品質負責人」。從 grooming 提問、planning 估點、daily 透明、demo 護航、retro 改 process — 每個儀式都要在場、都要發聲。做好這些，bug 自然少、上線自然順、團隊自然會給你資深的位置。