引言：為什麼 QA 與 QC 在 Scrum 中至關重要？
在 Scrum 敏捷開發中，品質保證（Quality Assurance, QA）與品質控制（Quality Control, QC）不僅是技術層面的活動，更是確保產品成功、降低風險、提升團隊效率的關鍵策略。本文將從三個視角深入探討：
- 專案經理與客戶：QA/QC 如何降低專案風險、提升 ROI 與客戶滿意度
- 研發人員（RD）：哪些具體實踐與工具可以幫助開發團隊提升品質
- QA 工程師：可立即遵循的測試策略、自動化實踐與最佳範例
QA 與 QC 的核心差異：從概念到實踐
QA（品質保證）：預防性策略
定義：QA 是一套預防性的流程與活動，目的是在開發過程中建立品質標準，避免缺陷產生。
核心理念：「預防勝於治療」—在問題發生前建立正確的流程與標準。
實際應用範例：
- 在 Sprint Planning 中定義「完成的定義」（Definition of Done, DoD）
- 建立程式碼審查（Code Review）流程
- 設計測試策略與測試計畫
- 建立自動化測試框架
QC（品質控制）：檢測性活動
定義：QC 是透過測試與檢查，識別產品中的缺陷並確保其符合品質標準。
核心理念：「驗證與確認」—確保產品符合需求與規格。
實際應用範例：
- 單元測試（Unit Testing）
- 整合測試（Integration Testing）
- 系統測試（System Testing）
- 驗收測試（User Acceptance Testing, UAT）
QA 與 QC 的關係
| 比較面向 | QA（品質保證） | QC（品質控制） |
|---|---|---|
| 目標 | 預防缺陷產生 | 檢測並修正缺陷 |
| 時機 | 整個開發生命週期 | 主要在開發完成後 |
| 責任 | 整個團隊 | 主要是 QA 工程師 |
| 方法 | 流程改善、審查、培訓 | 測試、檢查、驗證 |
| 產出 | 流程文件、標準、指南 | 測試報告、缺陷清單 |
專案經理與客戶視角：QA/QC 的商業價值
1. 降低專案風險
問題場景：專案後期發現重大缺陷，導致上線延遲或品質問題。
QA/QC 解決方案：
- 早期風險識別：透過 Sprint Planning 中的 QA 審查，在需求階段即發現潛在風險
- 持續驗證：每個 Sprint 結束時的增量交付都經過完整測試
- 可預測性提升：透過自動化測試與 CI/CD，每次變更的影響都可被快速評估
實際案例：某電商平台在導入 QA 流程後，上線前的重大缺陷從平均 15 個降至 3 個，上線延遲事件減少 70%。
2. 提升投資回報率（ROI）
成本比較：
- 需求階段修正缺陷：成本 1x
- 開發階段修正缺陷：成本 10x
- 測試階段修正缺陷：成本 15x
- 上線後修正缺陷：成本 100x
QA 的投資回報：
- 投資 1 元在 QA 流程（需求審查、設計審查）
- 可節省 10-100 元的後期修正成本
實際數據：根據 IEEE 的研究，軟體專案中 60-80% 的缺陷來自需求與設計階段，但在這些階段投入的 QA 資源通常不到 20%。
3. 提升客戶滿意度
品質的三個層次：
- 符合需求：產品做對了客戶要的功能（QC 驗證）
- 無缺陷：產品穩定可靠（QC 測試）
- 超越期待：產品易用、效能佳（QA 設計審查）
實務建議（給 PM）：
- 在每個 Sprint Review 中展示測試覆蓋率與缺陷趨勢
- 建立「品質儀表板」，即時追蹤品質指標
- 將 QA/QC 活動納入 Sprint 時程規劃，避免壓縮測試時間
研發人員（RD）視角：實踐方法與工具整合
1. 在 Scrum 流程中整合 QA 活動
Sprint Planning 階段
RD 應參與的 QA 活動：
- 需求澄清：與 PO、QA 一起確認 User Story 的驗收條件（Acceptance Criteria）
- 可測試性評估：確保每個 User Story 都有明確的測試方法
- 測試策略討論：決定哪些功能需要單元測試、整合測試、E2E 測試
實際範例：
User Story: 用戶可以透過信用卡付款
Acceptance Criteria:
1. 支援 Visa、MasterCard、JCB
2. 付款失敗時顯示明確錯誤訊息
3. 付款成功後寄送確認信
Testing Strategy:
- 單元測試：付款邏輯、錯誤處理
- 整合測試：與金流 API 整合
- E2E 測試：完整購物流程
- 手動測試：錯誤訊息呈現、郵件格式
Daily Scrum 階段
RD 應分享的品質資訊：
- 昨天完成的功能是否通過單元測試
- 是否有技術債需要處理
- 是否遇到測試困難的情況
Sprint Review 階段
RD 應展示的品質證據：
- 測試覆蓋率報告
- 自動化測試執行結果
- 效能測試數據（如適用）
2. 開發團隊的品質實踐
實踐 1：測試驅動開發（TDD）
為什麼 TDD 幫助 RD：
- 先寫測試後寫程式，確保程式符合需求
- 測試即文件，新加入團隊的 RD 可快速理解程式邏輯
- 重構時有測試保護，降低引入新缺陷的風險
實際範例：
# 1. 先寫測試（Red）
def test_calculate_discount():
order = Order(total=1000, discount_code="VIP20")
assert order.calculate_final_price() == 800 # 20% 折扣
# 2. 寫程式讓測試通過（Green）
class Order:
def calculate_final_price(self):
if self.discount_code == "VIP20":
return self.total * 0.8
return self.total
# 3. 重構改善程式碼品質（Refactor）
class Order:
DISCOUNT_RATES = {
"VIP20": 0.2,
"VIP10": 0.1
}
def calculate_final_price(self):
discount_rate = self.DISCOUNT_RATES.get(self.discount_code, 0)
return self.total * (1 - discount_rate)
實踐 2：持續整合（CI）與自動化測試
RD 應建立的 CI Pipeline：
- 程式碼提交 → Git Push
- 自動建置 → 編譯、打包
- 自動測試 → 單元測試、整合測試
- 程式碼品質檢查 → SonarQube、ESLint
- 部署到測試環境 → 自動部署
- 回饋結果 → Slack、Email 通知
工具推薦：
- CI 平台：Jenkins, GitLab CI, GitHub Actions, CircleCI
- 測試框架：JUnit（Java）、pytest（Python）、Jest（JavaScript）
- 程式碼覆蓋率：JaCoCo、Coverage.py、Istanbul
實踐 3：程式碼審查（Code Review）
有效的 Code Review 檢查點：
- 程式碼是否符合團隊的 Coding Standards
- 是否有明顯的邏輯錯誤或潛在 Bug
- 是否有適當的錯誤處理
- 是否有足夠的單元測試
- 是否有安全性漏洞（SQL Injection、XSS 等）
- 是否有效能問題（N+1 查詢、記憶體洩漏等）
Code Review 最佳實踐：
- 每次 Pull Request 不超過 400 行程式碼（超過則難以仔細審查）
- 審查時間控制在 60 分鐘內
- 使用 Checklist 確保審查完整性
- 自動化檢查（Linter、靜態分析）輔助人工審查
3. RD 常見問題與解決方案
問題 1：「寫測試太花時間，影響開發進度」
解決方案：
- 短期：確實會多花 20-30% 時間
- 長期：減少 50-70% 的除錯與修正時間
- 策略：優先為核心邏輯與容易出錯的部分寫測試
問題 2：「測試環境不穩定，測試常常失敗」
解決方案：
- 使用 Docker 容器化測試環境，確保一致性
- Mock 外部依賴（API、資料庫），減少環境因素影響
- 建立專屬的測試資料庫，避免與開發環境衝突
問題 3：「舊程式碼沒有測試，難以重構」
解決方案：
- 採用「童子軍規則」：每次修改時，為該區域增加測試
- 優先為高風險、高變動的模組補測試
- 使用「黃金路徑測試」：先測主要流程，再逐步補充邊界案例
QA 工程師視角：測試策略與最佳實踐
1. Scrum 中的 QA 角色定位
傳統瀑布式 vs. Scrum 中的 QA：
| 比較面向 | 傳統瀑布式 | Scrum 敏捷 |
|---|---|---|
| 參與時機 | 開發完成後 | 從 Sprint Planning 開始 |
| 測試週期 | 專案後期集中測試 | 每個 Sprint 持續測試 |
| 與開發關係 | 獨立部門，交接式 | 同一團隊，協作式 |
| 責任範圍 | 找出缺陷 | 預防缺陷 + 找出缺陷 |
Scrum QA 的核心職責：
- 協助定義「完成的定義」（DoD）
- 參與需求澄清，確保可測試性
- 設計測試策略與測試案例
- 執行測試（手動 + 自動化）
- 追蹤缺陷並驗證修正
- 提供品質報告與改善建議
2. 測試策略：測試金字塔
測試金字塔原則：
/
/ E2E 測試（10%）
/----
/ 整合測試（20%）
/--------
/ 單元測試（70%）
/-----------為什麼這樣分配？
- 單元測試：快速、穩定、易維護，應佔大部分
- 整合測試：驗證模組間互動，適度使用
- E2E 測試：涵蓋關鍵業務流程，但執行慢且脆弱，少量使用
3. 每個 Sprint 的測試活動
Sprint Planning（Sprint 第 1 天）
QA 應完成的工作：
- 審查 User Stories 的 Acceptance Criteria
- 識別測試範圍與風險
- 評估測試工作量並納入 Sprint 規劃
- 確定需要哪些測試環境與測試資料
Sprint 執行期間（第 2-9 天）
QA 應進行的活動：
- 測試案例設計：依據 User Stories 設計測試案例
- 測試資料準備：建立測試所需的資料
- 自動化測試撰寫：為新功能撰寫自動化測試
- 持續測試：開發人員完成功能後立即測試
- 缺陷追蹤：記錄缺陷並驗證修正
Sprint Review（Sprint 最後一天）
QA 應提供的資訊：
- 測試執行結果摘要
- 測試覆蓋率報告
- 缺陷統計與趨勢分析
- 風險評估與建議
Sprint Retrospective
QA 應反思的問題：
- 測試活動是否及時完成？
- 是否有測試遺漏？
- 自動化測試覆蓋率是否足夠？
- 團隊協作是否順暢？
- 下個 Sprint 如何改善？
4. 自動化測試實踐
何時應該自動化？
適合自動化的測試：
- 重複執行的測試（如回歸測試）
- 資料驅動的測試（多組輸入驗證）
- 跨瀏覽器/跨平台測試
- 效能測試與壓力測試
不適合自動化的測試：
- 一次性測試
- 需要人工判斷的測試（UX、視覺設計）
- 自動化成本大於手動測試成本的情況
自動化測試工具選擇
Web 應用測試：
- Selenium：最廣泛使用，支援多語言
- Playwright：新興工具，速度快且穩定
- Cypress：開發者友善，適合前端測試
API 測試：
- Postman：易用，支援自動化
- Rest Assured：Java 生態系統
- pytest + requests：Python 生態系統
行動應用測試：
- Appium：跨平台支援
- Espresso：Android 原生
- XCUITest：iOS 原生
5. QA 工作流程範例
完整的測試工作流程：
1. 接收 User Story
- User Story: 用戶可以重設密碼
- Acceptance Criteria:
* 輸入 Email 後收到重設連結
* 連結 24 小時內有效
* 新密碼需符合安全規則（8 字元以上、含大小寫）
2. 設計測試案例
- 正常流程測試
- 邊界值測試（密碼長度）
- 負面測試（錯誤 Email、過期連結）
- 安全性測試（CSRF、XSS）
3. 準備測試資料
- 建立測試用戶帳號
- 設定測試 Email 收件匣
4. 執行測試
- 手動測試新功能
- 執行自動化回歸測試
- 記錄測試結果
5. 缺陷管理
- 發現缺陷 → 記錄到 Jira
- RD 修正 → 驗證修正
- 驗證通過 → 關閉缺陷
6. 測試報告
- 測試案例執行率：95%
- 測試通過率：92%
- 缺陷數量：3 個（已修正）
- 風險評估：低風險，可上線
6. QA 常見挑戰與解決方案
挑戰 1：時間不足，測試被壓縮
解決策略：
- 在 Sprint Planning 時就將測試工作納入估算
- 建立「DoD」要求所有功能必須通過測試才算完成
- 提升自動化測試比例，加快回歸測試速度
- 採用風險導向測試，優先測試高風險功能
挑戰 2：需求變更頻繁，測試案例需常更新
解決策略：
- 採用 BDD（Behavior-Driven Development）風格撰寫測試
- 測試案例與 User Story 連結，需求變更時同步更新
- 使用參數化測試，減少測試案例數量
挑戰 3：自動化測試維護成本高
解決策略：
- 採用 Page Object Model 設計模式，提升可維護性
- 建立共用函式庫，避免重複程式碼
- 定期重構測試程式碼，刪除過時測試
- 使用穩定的 Locator 策略（優先使用 ID、data-testid）
實際案例：成功的 Scrum QA/QC 實踐
案例 1：金融科技公司的品質轉型
背景：某金融科技公司在導入 Scrum 前，上線後缺陷率高達每月 50+ 個，客戶投訴頻繁。
實施的 QA/QC 改善：
- 建立「完成的定義」：所有功能必須通過單元測試、整合測試、Code Review
- 導入 TDD：核心金融邏輯採用 TDD 開發
- 建立 CI/CD Pipeline：每次提交自動執行 1000+ 測試案例
- QA 提前介入：從 Sprint Planning 開始參與需求澄清
成果：
- 上線後缺陷率降至每月 5 個以下（降低 90%）
- 測試覆蓋率從 30% 提升至 85%
- 客戶滿意度從 6.5 分提升至 8.8 分（滿分 10 分）
- 開發速度反而提升 20%（因為減少了修 Bug 的時間）
案例 2：電商平台的自動化測試實踐
背景：電商平台需要頻繁更新功能，但回歸測試耗時過長（3 天）。
實施策略：
- 建立自動化測試框架（Selenium + Python）
- 優先自動化高頻功能：登入、搜尋、加入購物車、結帳
- 建立測試資料工廠，快速產生測試資料
- 整合到 CI Pipeline，每次部署前自動執行
成果：
- 回歸測試時間從 3 天縮短至 2 小時
- 測試案例數量從 200 個增加至 800 個
- 發現缺陷的時間點提前（從測試階段提前到開發階段）
常見問題（FAQ）
Q1: Scrum 團隊是否需要專職的 QA 工程師？
A: 取決於團隊規模與產品複雜度：
- 小型團隊（5 人以下）：可由開發人員兼任 QA，但需建立明確的測試規範
- 中型團隊（6-9 人）：建議至少 1 名專職 QA
- 大型團隊（10 人以上）：建議 QA 與 RD 比例為 1:3 至 1:4
無論團隊大小，品質是整個團隊的責任，而非只是 QA 的責任。
Q2: 如何在快速迭代的 Scrum 中保持測試品質？
A: 關鍵策略：
- 測試左移：在需求階段就開始設計測試
- 自動化優先：將重複性測試自動化
- 風險導向測試：優先測試高風險功能
- 持續整合：每次程式碼變更都觸發自動測試
Q3: 自動化測試的覆蓋率應該達到多少？
A: 沒有絕對標準，但業界常見目標：
- 單元測試：70-80%
- 整合測試：40-60%
- E2E 測試：涵蓋關鍵業務流程（約 20-30 個主要場景）
重點不是追求 100% 覆蓋率，而是覆蓋關鍵路徑與高風險區域。
Q4: 如何說服管理層投資在 QA/QC？
A: 使用數據說話：
- 計算「缺陷修正成本」：需求階段 vs. 上線後的成本差異（可達 100 倍）
- 展示「品質指標趨勢」：缺陷數量、測試覆蓋率、上線事故
- 引用業界數據：軟體專案失敗的 60% 原因與品質相關
- 提供 ROI 試算：投資 X 元在自動化測試，可節省 Y 元的手動測試成本
Q5: RD 與 QA 如何更好地協作？
A: 建立協作文化：
- 共同目標：品質是共同責任，而非對立關係
- 早期溝通：QA 在開發開始前就介入需求討論
- Pair Testing：RD 與 QA 一起設計測試案例
- 知識分享：定期舉辦測試技術分享會
- 工具共用：RD 與 QA 使用相同的測試框架
結論：從品質到卓越的實踐路徑
在 Scrum 敏捷開發中，QA 與 QC 不是開發流程的「最後防線」，而是「全程夥伴」。成功的關鍵在於：
對專案經理與客戶：
- 將 QA/QC 視為降低風險、提升 ROI 的投資，而非成本
- 在 Sprint Planning 中預留充足的測試時間
- 建立品質儀表板，即時追蹤品質趨勢
對研發人員：
- 採用 TDD、持續整合、程式碼審查等實踐
- 將測試視為開發的一部分，而非額外負擔
- 與 QA 緊密協作，共同提升產品品質
對 QA 工程師：
- 從測試執行者轉型為品質推動者
- 提早介入需求階段，預防缺陷產生
- 建立自動化測試，提升測試效率
- 持續學習新技術與測試方法
最終目標：建立一個「品質內建」（Built-in Quality）的文化，讓品質成為每個人的責任，而非只是 QA 的工作。
透過本文介紹的策略與實踐，無論您是 PM、RD 或 QA，都能在 Scrum 團隊中更有效地推動品質改善，最終交付出讓客戶滿意的高品質產品。