Test Strategy vs Test Plan vs Test Case — 三層計畫的差別與寫法

「我們有 test plan 嗎？」「你說的是 plan 還是 strategy？」是中型公司常見的對話災難。Strategy 是公司級、Plan 是專案級、Case 是執行級 — 用錯詞 = 溝通成本爆掉。

一張圖看懂三層關係

flowchart TB
    S[Test Strategy<br>公司 / 部門級<br>Why & How]
    P[Test Plan<br>專案 / Release 級<br>What & When]
    C[Test Case<br>執行級<br>Steps]

    S --> P
    P --> C

    S --> SD["長期、變更慢<br>1-2 年 review 一次"]
    P --> PD["專案 / sprint 起點<br>每次 release 寫"]
    C --> CD["每個功能<br>持續寫 + 維護"]

    style S fill:#06b6d4,color:#fff
    style P fill:#a855f7,color:#fff
    style C fill:#10b981,color:#fff

Test Strategy — 公司級的 Why & How

內容

mindmap
  root((Test Strategy))
    為什麼測 - 目標
      Quality vision
      可接受 bug 等級
      Trade-off 哲學
    測什麼 - 範圍
      Product scope
      Quality attributes
      Out of scope
    怎麼測 - 方法
      Test pyramid
      Shift-left vs shift-right
      Manual vs automation 比例
    用什麼 - 工具
      自動化框架
      CI/CD
      Bug tracker
    什麼角色 - 組織
      Team 結構
      Dev vs QA 分工
      跨部門關係
    什麼指標 - 量化
      KPI / OKR
      SLA
      Quality gate
    什麼風險 - Risk
      Top 3 風險
      Mitigation

寫範本（一頁開頭）

# [Company] QA Strategy 2026-2028

## Quality Vision
我們相信 quality 是團隊全員責任、不是 QA 獨佔。
QA 的角色是 quality coach、不是 gatekeeper。

## Quality Goals
- Production P0 incident: < 1 / month
- Customer satisfaction (CSAT) on quality: > 4.5/5
- Test cycle time: 從 PR 到 merge < 4 hr

## Test Approach
- Test Pyramid: 70% unit / 25% integration / 5% E2E
- Automation 優先：所有 happy path 自動化
- Exploratory testing 補強：每 sprint 4 hr session
- Shift-left：QA 從 grooming 介入

## Tools
- Automation: Playwright (web), Detox (mobile), pytest (API)
- CI: GitHub Actions
- Bug: Linear
- Test mgmt: 自建 dashboard

## Team Structure
- Embedded QA model：每 product team 1 QA
- 平台 QA team：建框架、跨團隊推 process
- Quality champion：每 dev team 1 人輪流當

## KPIs
[參考 OKR 文章]

## Out of Scope
- Performance optimization → SRE 負責
- Security pentest → Security team
- Mobile native 自動化 → Phase 2

## Review Cycle
每年 H1 review 一次。

Strategy 文件壽命

1-2 年改一次。不應該每 sprint 改。改太頻繁代表沒抓到原則。

Strategy 反例

❌ 「我們會用 Selenium 寫 100 個 case」
   → 這是 plan、不是 strategy

❌ 「我們很重視品質」
   → 沒方向、空話

❌ 30 頁細節到「每個按鈕都要測 click」
   → 變 case，不是 strategy

Test Plan — 專案 / Release 級的 What & When

內容

1. Project Overview（這次 release 是什麼）
2. Scope & Out of scope
3. Test approach（用什麼 type 的測試）
4. Resources（誰測、用多少時間）
5. Schedule（什麼時候測完）
6. Deliverables（產出什麼）
7. Entry criteria（什麼時候可以開始測）
8. Exit criteria（什麼時候算測完）
9. Risk & Mitigation
10. Test environment

寫範本

# Test Plan: User Profile v2.0 Release

## 1. Project Overview
新增 User Profile：頭像、bio、隱私設定、social link。
預計影響：登入後 user、20+ API endpoints。

## 2. Scope
### In scope
- 新增 / 編輯 / 刪除 profile
- 上傳頭像（多格式、大小限制）
- 隱私設定（public / friends / private）
- 跨 6 個瀏覽器 + iOS / Android

### Out of scope
- Profile 推送 / 通知（v2.1）
- Profile analytics（不在 H1）

## 3. Test Approach
| Test Type | Coverage | Tool |
|-----------|----------|------|
| Unit | Dev 寫、CI gate | pytest |
| API | QA 寫、CI gate | pytest + requests |
| E2E happy path | 自動化 | Playwright |
| Edge case | 手動 | — |
| Visual regression | Playwright snapshot | Playwright |
| A11y | manual checklist | axe |
| Performance | 1000 concurrent upload | k6 |

## 4. Resources
- QA: Alice (lead), Bob (web), Carol (mobile)
- Total: 12 person-days

## 5. Schedule
| Phase | Date | Owner |
|-------|------|-------|
| Test plan review | Jun 5 | Alice |
| API test ready | Jun 8 | Alice |
| E2E test ready | Jun 10 | Bob |
| Mobile test | Jun 12-14 | Carol |
| Regression | Jun 15 | All |
| Sign-off | Jun 16 | Alice |

## 6. Entry Criteria
- All API endpoints documented
- Staging env up
- Test data ready
- No P0 spec issue open

## 7. Exit Criteria
- All P0 / P1 case pass
- Auto coverage ≥ 80% on happy path
- 0 open P0 bug、< 3 open P1 bug
- Performance pass（p95 < 500ms）
- A11y level AA

## 8. Risks
| Risk | Impact | Likelihood | Mitigation |
|------|--------|-----------|------------|
| 上傳功能跨平台問題 | High | Medium | 跨裝置真機測試 |
| Migration 影響舊資料 | Critical | Low | Staging full data backup |

## 9. Test Environment
- Web: staging.example.com
- Mobile: TestFlight / Firebase
- DB: snapshot from prod (anonymized)
- 3rd party: Stripe sandbox / SendGrid sandbox

Plan 的壽命

每次 release / 大專案寫一次。Sprint 內小功能可以不寫、用 ticket 的 acceptance criteria。

Plan 反例

❌ 一頁紙：「測試 user profile，全部跑過」
   → 不夠細，沒 entry / exit criteria

❌ 100 頁含所有 case
   → 太細，case 應該在 test management 工具

❌ 寫完不 review、不更新
   → 一週後跟現實脫節

Test Case — 執行級的 Steps

完整指南見 Test Case 撰寫範本。

ID: TC-PROFILE-001
Title: 上傳 < 5MB JPG 頭像成功
Priority: P0
Preconditions: 已登入、有 < 5MB JPG 圖檔
Test Data: profile-pic-2mb.jpg
Steps:
  1. 進 /profile
  2. 點「更換頭像」
  3. 選 profile-pic-2mb.jpg
  4. 點「儲存」
Expected:
  1-3. 略
  4. 頭像更新、看到「儲存成功」、URL 包含 CDN 路徑

三者關係實例

flowchart TB
    Strat["Strategy: 我們做 mobile-first SaaS<br>auto coverage > 70%、quality coach 模式"]
    Strat --> P1["Plan: v2.0 release 含 5 個 feature<br>2 週測試窗口、3 個 QA"]
    Strat --> P2["Plan: hotfix release<br>1 天緊急、smoke only"]

    P1 --> C1["Case: profile 編輯<br>15 個 case"]
    P1 --> C2["Case: 上傳頭像<br>22 個 case"]
    P2 --> C3["Case: smoke - 登入 / 結帳<br>10 個 case"]

    style Strat fill:#06b6d4,color:#fff
    style P1 fill:#a855f7,color:#fff
    style P2 fill:#a855f7,color:#fff
    style C1 fill:#10b981,color:#fff
    style C2 fill:#10b981,color:#fff
    style C3 fill:#10b981,color:#fff

一份 strategy → 多個 plan → 每個 plan 含多個 case。

何時用哪個

flowchart TD
    Question[QA 工作問題] --> Q1{範圍多大?}

    Q1 -->|公司方向| Strat[寫 / 更新 Strategy]
    Q1 -->|某個 release| Plan[寫 Test Plan]
    Q1 -->|某個功能 / scenario| Case[寫 Test Cases]
    Q1 -->|某個 sprint story| Q2{有沒有大改變?}

    Q2 -->|有，影響跨 team| Plan
    Q2 -->|小、單 team| AC["寫 Acceptance Criteria<br>不用 plan"]

    style Strat fill:#06b6d4,color:#fff
    style Plan fill:#a855f7,color:#fff
    style Case fill:#10b981,color:#fff
    style AC fill:#f59e0b,color:#fff

簡化版（給小團隊）

5 人以下小團隊不一定需要全部三層：

Strategy：1 頁的 README.md 寫原則就夠
Plan：跳過、直接用 Linear / Jira issue 的 acceptance
Case：寫在 spreadsheet 或 testing tool（不用 word）

過度文檔化 = 沒人讀 = 等於沒寫。

給 QA Lead 的建議

flowchart TB
    Stage{你的公司階段} --> S1[早期 / 新創<br>< 10 人]
    Stage --> S2[成長期<br>10-50 人]
    Stage --> S3[成熟期<br>50+ 人]

    S1 --> A1[只需 1 頁 Strategy<br>跳過 Plan<br>Case 用 spreadsheet]
    S2 --> A2[Strategy 一份<br>每 release 寫 Plan<br>Case 進 test mgmt tool]
    S3 --> A3[完整三層<br>含跨 team strategy<br>process 自動化]

    style S1 fill:#06b6d4,color:#fff
    style S2 fill:#a855f7,color:#fff
    style S3 fill:#10b981,color:#fff

反模式

flowchart TD
    Anti[三層計畫反模式] --> A1["把 strategy 寫成 case 清單"]
    Anti --> A2["plan 寫了沒人 follow"]
    Anti --> A3["case 寫完不 maintain"]
    Anti --> A4["strategy 每 sprint 改"]
    Anti --> A5["小團隊強推 100 頁 plan"]
    Anti --> A6["寫 plan 不寫 exit criteria"]
    Anti --> A7["寫 case 跳過 expected result"]

    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

面試題目（這個常考）

Q: Test Strategy 跟 Test Plan 差在哪？

好答案：

Strategy 是公司 / 部門級的 Why 與 How，1-2 年才改一次，內容講 quality vision、test pyramid 比例、工具選型、組織結構。Plan 是專案 / release 級的 What 與 When，每次發版寫，含 scope、schedule、entry / exit criteria、risk。

簡單講：Strategy 是「我們怎麼測這家公司」、Plan 是「這次發版怎麼測」。

Q: 你在以前公司寫過 Test Strategy 嗎？

如果你是 Senior +，答得出來 = 加分。Junior 答「沒寫過、但讀過」也 OK。

範本下載

Minimal Strategy（1 頁）

# QA Strategy

## Vision
[Quality 是什麼、誰負責]

## Goals
- [Bug metric]
- [Cycle time]
- [User satisfaction]

## Approach
- Test pyramid: X% / Y% / Z%
- Manual vs Auto: ...
- Shift-left: ...

## Tools
- Auto: ...
- CI: ...

## Out of scope
- ...

Minimal Plan（半頁）

# Test Plan: [Feature/Release Name]

**Scope:** ...
**Out of scope:** ...
**Owner:** [Name]
**Timeline:** [Date] ~ [Date]

## Test approach
- [Type 1]: ...
- [Type 2]: ...

## Entry criteria
- [ ] ...

## Exit criteria
- [ ] All P0 case pass
- [ ] < 3 open P1 bug

## Risks
- [Risk 1]: [Mitigation]

最後

三層計畫的核心：Strategy 是相信什麼、Plan 是這次怎麼做、Case 是步驟。中型團隊以上這三層都要有。新公司可以從簡化版開始 — 一頁 strategy + 半頁 plan + spreadsheet case，逐步成長。混為一談 = 沒人知道你在說哪一層 = 溝通成本翻倍。