結論先講
大多數開發者不需要死背這些標準，但應該知道它們在講什麼。 ISTQB 給你測試的共通語言，ISO 29119 給你測試的流程框架，TMMi 告訴你組織的測試成熟度在哪裡。新創公司不需要全套導入，但從這些標準裡挑幾個實用的概念（例如測試計劃模板、缺陷分類），能讓你的測試流程從「隨性」進化到「有系統」。
真實場景：接案時客戶要求「符合 ISTQB 標準的測試報告」。如果你完全不知道 ISTQB 在講什麼，光是理解需求就要花一天。但如果你知道它的基本框架，其實就是把你已經在做的事情用標準化的格式描述出來。
ISTQB：測試的共通語言
什麼是 ISTQB
ISTQB（International Software Testing Qualifications Board）是全球最知名的軟體測試認證組織。它定義了一套測試的術語、概念和流程，被業界廣泛使用。
ISTQB 的核心概念
你可能已經在用這些概念了，只是不知道它們有「官方名稱」：
| ISTQB 術語 | 你平常怎麼說 | 意思 |
|---|---|---|
| Test Basis | 需求文件 | 用來設計測試的依據 |
| Test Condition | 要測的點 | 可以被驗證的面向 |
| Test Case | 測試案例 | 具體的測試步驟 + 預期結果 |
| Test Oracle | 正確答案 | 判斷測試結果對不對的依據 |
| Defect | Bug | 實際結果跟預期不符 |
| Test Level | 測試層次 | Unit → Integration → System → Acceptance |
| Test Type | 測試類型 | 功能 / 效能 / 安全 / 易用性 |
| Regression Testing | 回歸測試 | 確認修改沒有破壞既有功能 |
ISTQB 的七大測試原則
- 測試能顯示缺陷的存在，但不能證明沒有缺陷
- 窮盡測試是不可能的——要用風險分析決定測試範圍
- 及早測試——越早發現 bug，修復成本越低
- 缺陷群集——大部分 bug 集中在少數模組
- 殺蟲劑悖論——同樣的測試重複跑，找到的新 bug 會越來越少
- 測試取決於上下文——不同的系統需要不同的測試策略
- 沒有缺陷的謬論——沒有 bug 不代表系統好用
這七個原則聽起來像常識，但很多團隊會違反。例如違反第 2 條（試圖測所有情況）、違反第 5 條（永遠跑同一套測試但不更新）。
ISTQB 的測試流程
1. 測試計劃 → 決定測什麼、怎麼測、誰來測
2. 測試監控 → 追蹤進度、調整計劃
3. 測試分析 → 從需求中找出要測的點
4. 測試設計 → 設計測試案例
5. 測試實作 → 寫測試腳本、準備資料
6. 測試執行 → 跑測試
7. 測試完成 → 整理報告、歸檔
在敏捷開發中，這七個步驟不是線性的，而是在每個 sprint 裡循環執行。
ISO 29119：測試的流程標準
什麼是 ISO 29119
ISO/IEC/IEEE 29119 是國際標準組織發布的軟體測試標準，分為五個部分：
| 部分 | 名稱 | 內容 |
|---|---|---|
| Part 1 | 概念與定義 | 測試的基本詞彙和概念模型 |
| Part 2 | 測試流程 | 組織層、管理層、動態測試的流程定義 |
| Part 3 | 測試文件 | 測試計劃、測試報告、缺陷報告的模板 |
| Part 4 | 測試技術 | 黑箱、白箱、經驗型測試技術 |
| Part 5 | 關鍵字驅動測試 | 用關鍵字定義測試案例（自動化相關） |
ISO 29119 的爭議
ISO 29119 在測試社群中是有爭議的。2014 年發布時，很多知名測試專家公開反對，原因包括：
- 太重流程——對敏捷團隊來說太官僚
- 成本高——標準文件要付費購買
- 不實用——很多規定脫離實際開發現場
但它在某些場景確實有用：
- 合規需求——金融、醫療、航空等受管制產業
- 大型組織——需要跨團隊統一測試流程
- 客戶要求——外包或接案時客戶指定標準
從 ISO 29119 裡拿走什麼
即使不打算導入整套 ISO 29119，Part 3 的文件模板很實用：
# 測試計劃模板（簡化版）
## 1. 測試範圍
- 要測的功能：[列表]
- 不測的功能：[列表]
## 2. 測試策略
- Unit Test: 覆蓋率目標 80%
- Integration Test: 關鍵 API 路徑
- E2E Test: 核心使用者流程
## 3. 環境需求
- 測試環境：staging.example.com
- 資料庫：PostgreSQL 16（獨立測試 DB）
- 外部服務：全部 mock
## 4. 進入/退出標準
- 進入：開發完成 + code review 通過
- 退出：所有 P0/P1 bug 修復 + 覆蓋率達標
## 5. 風險
- 金流 API 可能不穩定 → 準備 mock 方案
- 測試環境記憶體不足 → 備用方案
## 6. 時程
- Sprint 1: 測試分析 + 設計
- Sprint 2: 測試實作 + 執行IEEE 829：測試文件標準
IEEE 829 是比 ISO 29119 更早的測試文件標準（1998 年發布，2008 年更新）。它定義了八種測試文件：
| 文件 | 用途 | 你可能在用的等價物 |
|---|---|---|
| 測試計劃 | 整體測試策略 | Confluence 上的測試頁面 |
| 測試設計規格 | 測試邏輯的設計 | 測試案例的分類和設計原則 |
| 測試案例規格 | 具體的測試步驟 | TestRail 上的 test case |
| 測試程序規格 | 測試的執行順序 | CI/CD pipeline |
| 測試傳送記錄 | 測試環境和版本 | CI 的 build log |
| 測試日誌 | 測試執行的詳細記錄 | Test runner 的輸出 |
| 測試事件報告 | 缺陷報告 | Jira 的 bug ticket |
| 測試摘要報告 | 測試結果總結 | Sprint review 的測試報告 |
實話： 大部分團隊不需要全部八種文件。但如果你至少有「測試計劃」和「缺陷報告」的標準格式，你的測試流程就已經超越 80% 的團隊了。
TMMi：測試成熟度模型
什麼是 TMMi
TMMi（Test Maturity Model integration）是借鑑 CMMI 的概念，把組織的測試能力分成五個等級：
| Level | 名稱 | 特徵 |
|---|---|---|
| Level 1 | Initial | 測試靠個人經驗，沒有流程 |
| Level 2 | Managed | 有測試計劃和基本流程 |
| Level 3 | Defined | 測試流程標準化，跨團隊一致 |
| Level 4 | Measured | 用量化指標管理測試品質 |
| Level 5 | Optimization | 持續改善測試流程 |
你的團隊在哪裡？
Level 1 的特徵：
✗ 測試是「開發完再說」
✗ 沒有測試計劃
✗ Bug 用 Slack 回報，沒有追蹤
Level 2 的特徵：
✓ 有 CI/CD 跑測試
✓ PR 需要測試通過才能 merge
✓ Bug 用 issue tracker 追蹤
Level 3 的特徵：
✓ 全公司統一的測試策略
✓ 測試設計有標準流程
✓ 新人有測試 onboarding
Level 4 的特徵：
✓ 追蹤 coverage、defect density 等指標
✓ 用數據決定測試投入
✓ 預測性的品質管理
Level 5 的特徵：
✓ 測試流程的自動化改善
✓ 根因分析 → 預防缺陷
✓ 跨專案的最佳實務分享
大多數中小型公司在 Level 1-2 之間。能做到 Level 3 就已經很好了。Level 4-5 通常是大型企業或受管制產業才會追求。
完整比較
| 維度 | ISTQB | ISO 29119 | IEEE 829 | TMMi |
|---|---|---|---|---|
| 性質 | 認證體系 | 國際標準 | 文件標準 | 成熟度模型 |
| 焦點 | 測試知識 | 測試流程 | 測試文件 | 組織能力 |
| 成本 | 考試 ~$250 | 文件 ~$200 | 文件 ~$100 | 評估 $$$$ |
| 適合誰 | 個人（QA） | 組織（合規需求） | 團隊（文件需求） | 大型組織 |
| 新創需要嗎 | 可選 | 不需要 | 參考就好 | 不需要 |
| 企業需要嗎 | 建議 | 看產業 | 參考就好 | 大型企業建議 |
| 學習曲線 | 中 | 高 | 低 | 高 |
實務建議：什麼情況下需要這些標準
一定需要的場景
- 受管制產業（金融、醫療、航空）——法規可能要求 ISO 29119 合規
- 外包/接案——客戶指定 ISTQB 標準或 IEEE 829 文件格式
- 大型組織轉型——TMMi 評估有助於找出改善方向
不需要的場景
- 早期新創——先把自動化測試跑起來比什麼標準都重要
- 小團隊——直接用 ISTQB 的概念就好，不需要完整的 ISO 流程
- 已經有良好測試文化的團隊——不需要用標準來「證明」你在做對的事
不管什麼情況都值得採用的概念
- ISTQB 的七大原則——這是測試的基本思維框架
- 測試計劃模板——即使簡化版也比沒有好
- 缺陷分類（Severity vs Priority）——不是所有 bug 都一樣重要
- 測試層次的概念——Unit → Integration → System → Acceptance
- 進入/退出標準——什麼時候開始測、什麼時候算測完
常見問題
ISTQB 認證對找工作有幫助嗎？
看目標職位。如果你要應徵 QA Engineer 或 Test Manager，ISTQB Foundation 是加分項（尤其是外商和大企業）。如果你是 Software Engineer 寫自己的測試，不需要考。下一篇會詳細講認證的 ROI。
ISO 29119 要付費才能看到完整內容嗎？
是的，ISO 標準文件要付費購買。但 ISTQB 的教學大綱（Syllabus）是免費的，裡面涵蓋了大部分實用概念。
敏捷團隊適合 ISO 29119 嗎？
ISO 29119 本身是流程導向的，跟敏捷有衝突。但 Part 4 的測試技術部分跟流程無關，任何團隊都能用。實務上，敏捷團隊通常只取 ISO 29119 的概念，不會照搬整套流程。
TMMi 評估要花多少錢？
正式的 TMMi 評估需要認證的評估師，費用通常在幾十萬到幾百萬台幣，取決於組織規模。但你可以用 TMMi 的框架做自我評估，完全免費。
本系列文章
- 測試策略（一）：測試金字塔
- 測試策略（二）：Unit vs Integration
- 測試策略（三）：E2E + 壓力測試
- CD 整合
- API 契約測試
- 安全測試
- Smoke + 回歸測試
- 測試資料管理
- 視覺回歸測試
- AI 輔助測試
- 測試規範（ISTQB/ISO 29119）（本篇）
- 測試相關憑證與學習路徑