題目寫得很清楚，但沒有人問

在公開班上我常做一個練習。我先講好角色：我當專案經理，台下所有人都是測試人員。接著把題目放上投影片：請為台灣高鐵訂票系統寫三十個測試案例，這次測試的目的，是找出最多的 bug。

這句話我會念一次，投影片上也寫得清清楚楚。但每次做這個練習，現場都沒有人追問。沒有人問為什麼是找 bug、不是驗收功能，也沒有人問什麼樣的 bug 才算重要。大家的注意力全放在「三十個測試案例」上，好像把案例寫出來，就是這個練習要做的事。

學員低頭開始寫之後，畫面很熟悉。有人從登入寫起，有人拆訂票流程，有人補上付款和取消訂單。案例寫得有條理，步驟清楚、預期結果明確、功能都有覆蓋，完全符合多數團隊心中好測試案例的樣子。

單看這段過程，看不出什麼問題，因為在大多數專案裡，這就是測試人員被期待的專業。至於「找出最多 bug」，題目裡還在，只是沒有真的影響任何一條案例的設計方向。

開始跑，才知道時間有多不夠

接著我問大家：這三十個案例真的要跑完，需要多久？有人說一小時，有人說半天，也有人覺得要一天。這些估算背後有個沒說出口的假設：案例都寫好了，接下來就是把它們跑完。

我不糾正，也不提醒目的，直接宣布開始測試，時間二十分鐘。

系統一打開，大家馬上發現不對勁。登入、查詢、選位、付款，每一步都要等系統回應，操作失誤還得重來。原本看起來簡單的案例，一條一條跑起來慢得驚人。多數人還是緊抓著清單往前推，希望至少完成一部分。

大約七分鐘後，我提醒大家時間有限，只剩五分鐘。現場開始出現變化：有人跳過部分案例，有人只挑感覺重要的跑，也有人乾脆放下案例，直接亂試各種輸入、快速切換流程，看系統會不會出狀況。測試行為開始偏離原本的計畫，但那是被時間逼出來的，稱不上策略。

案例沒跑完，bug 反而出現了

時間到，我先問有多少人跑完三十個案例。答案可以想見，大部分的人做不完，偶爾有幾個人做得完。再問有多少人找到 bug，總是有人舉手，而且是真的抓到了。

仔細聽他們描述會發現，這些 bug 多半是在臨時改變操作方式、換個順序、或快速亂點的時候冒出來的，很少是乖乖執行某一條案例時發現的。

到這裡我才請大家回頭看題目。三十個案例只是手段，題目寫的目的是找出最多的 bug。很多學員這時才意識到，整個過程中自己幾乎沒有用這個目的做過任何決策。案例怎麼設計、先跑哪一條、時間不夠時砍掉哪些，考量的都是案例能不能跑完，沒有人想過哪裡最可能藏問題。

問題不在案例，在案例服務誰

回頭看，整個練習沒有哪一步是錯的。題目交代清楚，案例寫得完整，執行也很認真，時間壓力下還會想辦法調整。問題出在整個測試活動裡，沒有任何機制讓測試人員根據當下學到的東西，重新決定下一步要測什麼。案例一寫完，就自然變成行動的中心；時間不夠時，大家取捨的是案例數量，不是風險高低。少了探索性測試，測試工作就長這個樣子：案例被執行了，風險卻沒被碰到。

探索性測試真正想做的事情，其實很具體。它並不反對寫測試案例，但它要求測試活動必須允許、甚至鼓勵三件事發生：

• 第一，測試人員在操作系統時，要隨時觀察異常與線索。
• 第二，這些線索要能即時影響接下來的測試方向。
• 第三，測試成果的價值，不是用「跑完多少案例」來衡量，而是用「是否更靠近真正的風險」。

用這個練習來對照，做法就很清楚。一開始不會急著平均寫滿三十個案例，而是先花一小段時間快速把系統摸一遍，找出最混亂、最不穩、最容易出錯的地方，再把測試火力集中過去。案例還是可以寫，但那是拿來支援探索、記錄發現用的，不會一開始就把自己的手腳綁死。

這個練習我帶過很多次，結果都差不多。只要測試流程裡沒有探索的空間，就算目的白紙黑字寫在題目上，測試最後還是會變成一份等著被跑完的清單。探索性測試，就是用來擋住這件事的。