測試不該只是對答案：為什麼「探索性測試」才是抓出關鍵 Bug 的殺手鐧？

作者：柯仁傑（三叔公）

在軟體開發的現場，我們常陷入一種迷思：覺得只要測試案例寫得夠多、自動化覆蓋率夠高，系統就穩了。但現實狀況往往是，CI 跑出來一片綠燈，產品一上線還是被使用者抱怨連連。

這時候，很多人會提到「探索性測試」（Exploratory Testing）。但別誤會了，這不是那種漫無目的的「隨便點點看」，更不是因為懶得寫測試案例才做的補救。相反地，它是一場有策略的心理戰，是測試高手在面對複雜系統時，用直覺與經驗進行的「精準打擊」。

為什麼自動化測不到的，它測得到？

自動化測試本質上是在「驗證已知」，它就像導航，只能帶你去地圖上標好的地方。但使用者在操作系統時，往往是不照牌理出牌的。

想像一個情景：你在一個購物網站重複點擊結帳鈕、同時切換分頁、還順手改了瀏覽器縮放比例。這種「奇怪的互動」很難寫進固定的腳本裡。探索性測試的核心在於「邊測邊學」，測試人員不是死守著文件，而是像偵探一樣觀察系統的反應，發現一個小小的畫面閃爍或延遲，就立刻像獵犬一樣嗅出背後的邏輯破綻。

根據數據顯示，這種方式每單位時間能抓到的 Bug 數量，遠比傳統腳本測試多出不少。甚至在許多複雜的專案中，高達八成的關鍵缺陷，都是靠這種「真人對話」式的探索才被挖出來的。

業界的高手都怎麼玩？

為了不讓探索變成漫遊，業界現在流行幾種非常有感的方法：

最常見的是 「會話式探索」（Session-Based Testing）。我們不會漫無目的地測一整天，而是設定一個「黃金一小時」，定好目標（例如：專攻結帳流程的異常處理）。在這段時間內，測試人員必須像進入心流狀態一樣，全神貫注地挖掘問題並做紀錄。

另一種很有效的方式是 「雙人探索」（Pair Testing）。找一個工程師跟一個測試員坐在一起，一個了解代碼怎麼寫，一個了解使用者怎麼想。這種組合常會產生意想不到的化學反應。工程師可能會說：「這段邏輯我寫得很趕，可能會有問題。」測試員就立刻針對那裡進行各種破壞性嘗試。這種即時的反饋，比開一堆 Jira 單據還要有效率。

甚至現在還有公司會辦 Bug Bash，把行銷、設計、業務通通抓進來。雖然他們不是專業測試，但正因為他們「不懂系統」，反而能用各種正常人意想不到的方式把系統玩壞。

它是效率的救星，也是職涯的進階

很多人擔心探索性測試會讓流程變亂，或者很難追蹤。其實現在有很多工具可以輔助，甚至 AI 也能幫忙。有些工具可以一邊紀錄你的路徑，一邊幫你把這些「精華動作」轉化為未來的自動化腳本。這意味著：你今天的創意探索，會變成明天的常態防禦。

更重要的是，它讓測試變得「有趣」了。它不再是枯燥的點點點，而是一場思考遊戲。測試人員必須理解業務、預測風險、甚至要懂得一點心理學去猜使用者的習慣。這不僅提升了產品品質，也讓團隊對「品質」這件事更有使命感。

從今天開始，留一點白

如果你的團隊現在正被寫不完的測試腳本追著跑，或者發現線上問題抓不完，不妨試試看「留白」。

不需要大幅改動流程，只要在 Sprint 中抽出一兩個小時，放下那些寫死的腳本，安排一次專注的探索會話。你會發現，那些躲在角落最深、最致命的 Bug，往往就是在你放下劇本、開始真正「玩」系統的那一刻現身的。

畢竟，最好的測試員從來不是機器，而是那個對產品充滿好奇心、想方設法要找出漏洞的你。