QA 的角色再定義#
在專業開發團隊中，QA (Quality Assurance) 職責不僅是「找 Bug」，
更像是團隊中的規格定義者與系統描述者。
1. 需求規約定義者 (Specifier)#
QA 協助定義系統在各種狀況下應有的表現，特別是開發者容易忽略的角落：
| 維度 | 定義 | 範例 | 預期目的 |
|---|---|---|---|
| 極端情況 (Corner Cases) | 發生機率低且 複雜的組合情境 | 空值 (Null)、 極大/極小值、 不合法的資料類型 | 確保系統 極限狀態下 不崩潰 |
| 邊界條件 (Boundary Conditions) | 臨界數值 | 陣列的 index 0、 輸入長度的限制上限、 剛好符合條件的門檻值 | 避免「差一錯誤 (Off-by-one)」 |
| 異常路徑 (Unhappy-path) | 偏離正常預期 | 用戶輸入錯誤、 資料庫連線超時、 權限不足等失敗情境 | 驗證系統的回復力 與錯誤處理 |
2. 特性描述者 (Characterizer)#
QA 透過探索式測試，觀察並描述系統在真實運行下的實際運作情況，確保系統行為符合業務預期。
自動化測試金字塔 (The Test Pyramid)#
作者依據負責人員、目的與覆蓋範圍，將測試策略分為五個層次。
專業測試策略應呈現金字塔狀：底層數量最多，越往上越精簡。
Figure 8-1: The test automation pyramid
測試種類一覽表#
| 測試種類 | 負責人員 | 目的與定義 | 關鍵指標與備註 |
|---|---|---|---|
| 單元測試 (Unit Tests) | 程式設計師 | 在最低層次上定義系統行為。 確保個別函式或類別運作正常 | • 覆蓋率應接近 100% • 這是 TDD 的產物 |
| 元件測試 (Component Tests) | QA 與 業務人員 | 針對封裝後的系統元件進行測試， 確保業務規則被正確執行 | • 覆蓋率約達 50% • 重點在驗收功能 • 主要測試正常路徑， 測試異常路徑意義不大 （應在單元測試完成） |
| 整合測試 (Integration Tests) | 系統架構師 首席設計師 | 聚焦於編排性 (Choreography)。 測試各個元件組合在一起時是否協調運作 | • 適合較大型系統 • 通常在此階段進行性能測試 |
| 系統測試 (System Tests) | QA / 系統整合方 | 對「整合完畢的系統」 執行自動化測試 | • 確保系統構造正確 (Correct Construction) • 這不等於確保系統行為正確 (Correct Behavior) |
| 人工探索式 (Exploratory) | 人類 (QA/User) | 結合人類的直覺與創意， 驗證預期行為並挖掘非預期行為 | • 機器做不到的測試 • 探索系統預期之外的缺陷 |
策略細節解析#
為什麼元件測試不測異常路徑？#
在元件測試層級（通常對應到驗收測試），重點在於驗證「業務邏輯是否如預期運作」。
至於輸入驗證、錯誤捕捉等底層的異常處理，
應該在成本較低、回饋較快的單元測試層級就已經被攔截並驗證完畢。
Figure 8-2: Component acceptance test
整合測試 vs. 系統測試#
這兩者常被混淆，區別在於關注點不同：
| 類別 | 關注核心 | 範例 | 目標 |
|---|---|---|---|
| 整合測試 (Integration) | 通訊與協作 | 資料庫連線是否成功、 Microservices 接口格式是否對齊 | 組件間交互正確性 |
| 系統測試 (System) | 整體組裝 | 系統是否能正確啟動、 各模組與環境變數是否部署於正確位置 | 軟體交付完整性 |
Figure 8-3: Integration test
專業的測試策略不是「所有測試都混在一起」，而是各司其職。
程式設計師顧好單元邏輯，架構師顧好元件連接，QA 顧好業務規則與系統全貌。
不要讓人類去做電腦能做的事（如回歸測試）。
人類智慧應用於探索式測試，發現那些自動化腳本想像不到的邊緣問題。