概念地圖・敏捷測試四象限
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：管理
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
敏捷測試四象限：這一項測試該擺哪一格
一份出貨前的測試清單有十四項，工程師照著從上到下打勾，打到最後一項才發現，沒有人問過這一項是要給誰看的。清單長度看起來像盡責，實際上只證明了有人很勤勞。敏捷測試四象限（Agile Testing Quadrants）處理的正是這件事——它不排先後，只問兩個問題：這次測試的結果要交給誰看，它是在替團隊鋪路，還是在替做好的東西挑毛病。兩個答案交叉，就長出四個格子。
四格，測什麼、給誰看
四個格子的座標是框架本身釘死的，照著看就好，不必自己重排。
| 格 | 兩條軸的座標 | 測什麼 | 怎麼跑 |
|---|---|---|---|
| Q1 | 右下：面向技術、支持團隊 | 單元測試、元件測試 | 自動 |
| Q2 | 左下：面向業務、支持團隊 | 功能測試、範例、原型 | 自動加手動 |
| Q3 | 左上：面向業務、批判產品 | 探索性測試、可用性測試、使用者驗收 | 手動 |
| Q4 | 右上：面向技術、批判產品 | 效能、負載、安全、相容性 | 工具 |
Q1 落在右下角這件事，是兩條軸的座標決定的：它面向技術，同時站在支持團隊那一側——跟它排第幾個跑毫無關係。編號從 Q1 數到 Q4，只是四個位置的代號。橫著看，左邊兩格說的是業務聽得懂的話（感應距離幾公分、按下去會不會關機），右邊兩格說的是工程師之間的話（暫存器、負載曲線、記憶體洩漏）。直著看，下半邊兩格是在鋪路，讓團隊敢改下一段程式；上半邊兩格是在對已經做出來的東西動手，帶回來的常常是壞消息。至於「怎麼跑」那一欄，它跟著座標走——先定出位置，執行方式才長出來。
一項測試該進哪一格，先問三件事
一、結果最後攤在誰面前。一家做烘手機的工廠，清單上有一項「感應距離的功能驗證」，它的結果最後會變成通路型錄上那句「手伸進去十公分即啟動」——讀它的是業務、經銷商、最後是消費者，所以它靠左。同一份清單上的「電源模組自檢」，輸出是一串十六進位的暫存器值，全公司只有兩個韌體工程師會打開來看，所以它靠右。左右分的是讀者，跟技術難度無關；把難的往右擺，是這條軸最常被誤讀的一次。自問：這一項測試的結果，最後要拿給誰看？
二、它在鋪路，還是在挑毛病。「風速三檔切換」這一項，在機構定案前就寫好了。寫它的人真正想確認的是「需求有沒有講清楚」——跑綠了，大家才敢動手改下一段。它站在團隊這一邊。反過來，「公廁現場觀察一個上午」只能等機器鎖上牆才做得成，做完帶回來的多半是難聽的話：清潔人員嫌濾網卡榫太緊、身高一百五的人得踮腳。這條軸量的是時機與心態——前者讓人往前，後者讓人停下來看清楚。自問：它是在讓團隊敢往前走，還是在把已經做出來的東西挑出問題？
三、自動化的答案會把它往下拉。「自動關機計時」寫成腳本之後，跑一萬次也不喊累，它自然沉進每天早上那批回歸測試裡。「找八位不同身高的人各用一次」永遠自動不了——它要的是八雙不同的手、八種猶豫、八次沒讀說明書的第一次伸手。這一問的作用是替時間排序：自動得了的往下沉、變成每天跑的底盤，自動不了的往上浮、變成有節奏的專門場次。人的時間有限，這條線幫你決定它花在哪裡。自問：這一項能不能自動化？答案會把它推向不同的格子。
一家烘手機廠的十四項測試，四格各分一次
底下這家台灣中部的烘手機工廠，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。開頭那份十四項的清單，就是它出貨前要打的勾。
- Q1，三項：感應器驅動的單元測試、電源模組自檢、韌體開機序列測試。每次提交程式碼就自動觸發，八分鐘內回報。壞了當天就知道
- Q2，四項：感應距離的功能驗證、風速三檔切換、自動關機計時、防呆重按。這四項的驗收條件是在規格會議上跟業務一起寫出來的，寫完才開工。需求含糊的地方當場現形
- Q3，三項：找八位不同身高的人各用一次、公廁現場觀察一個上午、清潔人員試拆濾網。三項都得有人親自站在那裡。最容易在趕出貨時被劃掉
- Q4，四項：連續運轉一千小時、耐濕測試、噪音量測、電磁相容。要儀器、要恆溫箱、要排隊等實驗室。周期最長，所以永遠來不及重測第二次
三加四加三加四，十四項剛好分完，沒有一項落在格子外面。分完之後才看得出真正的形狀：十四項裡有七項落在下半邊，那是在幫團隊往前走；另外七項落在上半邊，那是在挑已經做出來的東西的毛病。上下剛好對半——聽起來很健康，但七項裡有三項要人親自站到公廁去、四項要等實驗室排隊，真正的產能壓力全壓在上半邊。這家工廠後來的調整跟加測試無關：他們把 Q3 那三項從「出貨前」往前搬到「第一台試產機出爐的那一週」，讓難聽的話早三個月講出口。以上為說明結構用的示意情境，僅供理解框架之用。
這四格什麼時候會騙你
- 四格都填得滿，只證明種類齊全。這張圖量的是覆蓋的種類，量不到每一格的厚度。Q1 有八百個單元測試、Q3 只有一次十分鐘的隨手點按，畫在圖上一樣是「兩格都有」。更麻煩的是它們的分佈通常是歷史造成的：哪一格好寫就長得快，哪一格要協調人就永遠只有一項。看這張圖的時候，順手在每一格旁邊寫上它實際吃掉多少人天，形狀才會誠實起來。
- 編號很容易被讀成階梯。Q1 到 Q4 是座標代號，可是排會議、排 sprint 的時候，人腦會自動把它讀成一到四的順序。結果就是每次都從 Q1 開始加、Q4 躺在「下一個版本再說」。實務上的順序常常反過來：Q2 的驗收條件要在動工前寫，Q4 的一千小時要在最早的試產機上就開始跑，否則排到最後就只剩下「來不及了先出貨」。
- 它回答不了一項測試值不值得留著。格子只判斷「這一項屬於哪一類」，判斷不了「這一項還有沒有在保護誰」。三年前為某個已經下架的機種寫的一百二十個單元測試，照樣穩穩坐在 Q1，每天跑、每天綠、每天多花四分鐘。分類做得越漂亮，這種殭屍測試越不容易被看見——因為它們讓格子看起來很飽滿。
用痛點的眼光拆那兩條軸
兩條軸問到底，問的都是「誰」。
橫軸問結果交給誰讀，縱軸問這一次動手是替誰服務——替團隊的信心，還是替產品的品質防線。兩個問題都圍著人打轉，可是四個格子裡沒有一格問到《痛點》最在意的那個 P：誰在痛。一項測試可以完美地落在 Q2，驗收條件寫得漂亮、自動跑得又快，測的卻是一個沒人在乎的功能。這張圖畫得出每一項測試要對誰交代，畫不出那個人到底痛不痛。它是一張分類尺，優先序得另外找地方決定——把這張圖當成優先序尺，就會出現「四格都綠、客訴照舊」的季度。今晚可以做的小事：打開你那份跑最久的測試清單，挑出耗時前三名，在每一項後面寫一個真實的人名或角色——這一項壞掉的時候，誰會第一個打電話進來。名字補上去之後再看那三項一次，明天早上該先擋下誰的電話，順序自己就浮出來了。
常見問題
Q1 到 Q4 是執行順序嗎？
編號只是四個座標的代號。Q1 落在右下角，是因為它同時面向技術、又站在支持團隊那一側，跟「第一個跑」沒有關係。實務上真正的時間順序往往是 Q2 最早（驗收條件在動工前就要跟業務談定）、Q1 緊接著隨程式碼長出來、Q4 因為周期長要提早開跑、Q3 則貼著使用者能摸到實體的時間點安排。把編號當成排程順序，最常見的後果是 Q4 永遠排在下一個版本。
敏捷測試四象限是誰提出的？
最早的雛形出自 Brian Marick 二〇〇三年的一系列部落格文章，他用「面向業務／面向技術」與「支持團隊／批判產品」兩組詞把測試分開談。後來 Lisa Crispin 與 Janet Gregory 在《Agile Testing》裡把它整理成現在流通的四格版本，並補上每一格典型的測試型態與執行方式。兩位作者後續也一再強調，這張圖的用途是打開討論，照格子平均分配資源從來不在它的設計意圖裡。
每一格都一定要有測試嗎？
不必平均，但每一格空著都要說得出理由。內部工具沒有外部使用者，Q3 的可用性測試可以很薄；一次性的活動網站不必扛一千小時的耐久，Q4 只留安全掃描也合理。危險的是「沒想過」跟「想過後決定不做」被混為一談——前者會在出事那天才被發現。把每一格空白的理由寫成一行字貼在看板上，下一季回頭看，理由還站不站得住通常一眼就知道。
這張圖跟測試金字塔要怎麼一起用？
測試金字塔管的是數量比例：底層的單元測試要多、上層的端對端測試要少，講的是成本與速度。四象限管的是種類覆蓋：這四種視角有沒有人負責。兩張圖疊起來看最省事——金字塔幾乎整個活在 Q1 與 Q2 這半邊，它對 Q3 的探索性測試、Q4 的效能與安全幾乎沒有意見。所以團隊常見的狀況是金字塔畫得很標準，圖的上半邊卻整片空白。
對著手上那份測試清單，替每一項填上它面向誰。填完通常會看到某一格特別擠、某一格只剩一行字，而空的那一格往往就是上次客訴發生的地方。想再往下算一層「這些測試花的錢花得值不值」，接著看品質成本模型，它把品質的錢分成預防、鑑定、失敗三種；如果卡住的是「問題到底從哪裡冒出來」，那要換一張圖——品質管理七大工具處理的是找原因，這一張處理的是安排測試。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。