QA 在敏捷團隊中的角色轉型：從守門員到品質教練

1. 傳統 QA vs 敏捷 QA 的根本差異

2. QA 在 Scrum 各儀式中的角色

• 評估測試工作量

  每個 User Story 的測試時間要算進 Story Point

• 確認驗收標準

  確保每個 Story 有明確、可測試的 Acceptance Criteria

• 提出風險

  哪些功能技術風險高、需要更多測試時間

• 自動化評估

  哪些新功能適合自動化、需要多少時間建置

• 昨天測了什麼、發現什麼問題

  昨天測了什麼、發現什麼問題

• 今天計劃測試什麼

  今天計劃測試什麼

• 是否有 Block（例如等待開發修 Bug、測試環境問題）

  是否有 Block（例如等待開發修 Bug、測試環境問題）

• 提前預警：「這個功能明天才能交給我測，時間會很趕」

  提前預警：「這個功能明天才能交給我測，時間會很趕」

• 本次 Sprint 的測試覆蓋範圍與品質報告

  本次 Sprint 的測試覆蓋範圍與品質報告

• 發現的重要 Bug 與其影響

  發現的重要 Bug 與其影響

• 自動化測試的新增進度

  自動化測試的新增進度

• 品質趨勢圖（Bug 數量、嚴重度分布等）

  品質趨勢圖（Bug 數量、嚴重度分布等）

• 哪些 Bug 本來可以更早發現

  哪些 Bug 本來可以更早發現

• 測試環境有什麼需要改善的

  測試環境有什麼需要改善的

• 團隊的 Definition of Done 是否需要調整

  團隊的 Definition of Done 是否需要調整

• 自動化測試有哪些 Flaky Test 需要修復

  自動化測試有哪些 Flaky Test 需要修復

3. Definition of Done：品質的底線

• 程式碼通過 Code Review

  程式碼通過 Code Review

• 單元測試通過且覆蓋率達標

  單元測試通過且覆蓋率達標

• 功能測試通過（手動或自動化）

  功能測試通過（手動或自動化）

• 無 Critical/Major 等級的未修復 Bug

  無 Critical/Major 等級的未修復 Bug

• 文件已更新

  文件已更新

• 整合測試通過

  整合測試通過

• 效能無退化（與基準比較）

  效能無退化（與基準比較）

• 安全掃描通過

  安全掃描通過

• 跨瀏覽器/裝置測試完成

  跨瀏覽器/裝置測試完成

• 自動化迴歸測試通過

  自動化迴歸測試通過

4. QA 與開發的協作模式

• 優點

  溝通成本最低、對業務理解最深

• 缺點

  QA 容易被孤立、缺乏同儕交流

• 優點

  兼顧嵌入與專業成長

• 缺點

  雙重回報關係可能產生優先級衝突

• 優點

  品質意識最高、沒有丟過牆的問題

• 缺點

  需要團隊具備高度的測試素養、可能忽略專業測試技巧

5. 敏捷 QA 的自動化策略

• 核心業務流程

  每次發布都要確認的關鍵路徑

• 頻繁迴歸的功能

  每個 Sprint 都可能被影響的模組

• 資料驅動測試

  需要大量輸入組合的測試場景

• 還在頻繁變動的 UI

  自動化了馬上就要改，維護成本太高

• 一次性的驗證

  只需要測一次的場景不值得投資自動化

• 需要人類判斷的測試

  視覺美觀、用戶體驗等主觀評估

6. QA 轉型的心態調整

• 從「找 Bug」到「預防 Bug」

  你的價值不在發現多少 Bug，而在幫團隊避免多少 Bug

• 從「獨立把關」到「協作共責」

  品質是整個團隊的責任，不是 QA 一個人扛

• 從「完美主義」到「風險導向」

  不可能測試所有情境，學會評估風險、聚焦重要的

• 從「被動接收」到「主動參與」

  不等開發交付才開始，從需求階段就介入

7. 常見問題 FAQ