「探索性測試（Exploratory Testing, ET）」在軟體測試實務中經常被提及，卻也最常被誤解。有些團隊把它當成沒有測試案例時的臨時補救手段，有些人以為只要自由地操作系統，就算是在做探索性測試。

回到最初提出這些觀點的測試專家原文，可以清楚看出：探索性測試並非隨意亂測，它高度依賴專業判斷與即時學習。

本文將先說明探索性測試的核心定義，接著結合三位關鍵人物的觀點，並透過實際專案情境，具體說明這些定義在現實工作中是如何被實踐的。

探索性測試的基本定義

(1) Wikipedia

根據 Wikipedia 對 Exploratory Testing 的整理，探索性測試是一種測試設計、測試執行與系統學習同時進行的測試方法。

Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution.
https://en.wikipedia.org/wiki/Exploratory_testing?

這個定義本身並未否定測試計畫或測試案例的價值，而是指出，在真實專案中，測試人員往往無法在一開始就掌握完整的系統行為。

實務上，這種情境並不少見。舉例來說，在一個新上線的金流模組中，即使需求文件已經描述了付款流程，測試人員在實際操作時，仍可能發現第三方支付回傳的錯誤碼、延遲行為或例外流程，並未完整出現在文件中。此時，測試人員若能根據這些即時觀察調整測試方向，持續深入驗證相關情境，正是探索性測試的核心精神。

(2) James Whittaker

James A. Whittaker 曾在 Microsoft、Google 等大型科技公司負責測試相關工作，並出版《Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design》（2009），用「Testing Tours」等心智模型推廣探索性測試。

Whittaker 在其書籍《Exploratory Software Testing》的脈絡中，提出了一個非常「操作性」的界定方式：

“When the scripts are removed entirely (or … their rigidness relaxed), the process is called exploratory testing.”
當你把測試腳本拿掉（或把腳本的僵硬度放鬆），你就進入探索性測試的狀態。

例如在實際專案中，企業內部權限系統本週連續改了三次規則，你如果硬要維持完整腳本，腳本本身會比系統更快腐化。此時比較合理的做法是：保留最低限度的「檢核點」（例如關鍵角色、關鍵資源、關鍵狀態轉換），然後允許測試過程根據觀察到的快取、權限更新延遲、或跨角色切換的殘留狀態去延伸測試。

Whittaker 的定義在實務上等於在說：當你把測試活動從腳本束縛中解放出來，讓測試可以回應現場資訊，你就在做探索性測試。

(3) Cem Kaner

Cem Kaner 是軟體測試領域的學者與教育者，長期推動探索性測試與脈絡導向測試（Context-Driven Testing）。「exploratory testing」這個詞正是由他提出（Wikipedia 記為 1984 年），並首次發表於他的著作中《Testing Computer Software》。

定義（原始來源）

Kaner 在自己的網站文章〈Defining Exploratory Testing〉給出一個比 Wikipedia 更「規範性」且更強調責任的定義：

Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester … by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.
https://kaner.com/?p=46

這個定義有三個重點：
• 探索性測試是一種風格（style）：測試人員擁有自由，但必須為「價值最大化」負責。
• 活動除了學習、設計、執行，還包含結果解讀（interpretation）。
• 這些活動互相支援、並行發生，貫穿整個專案。

我們來看看電商訂單系統中，初階測試人員可能會把時間花在頁面每個按鈕都點過一遍；資深測試人員會先把風險排序：折扣疊加、免運門檻、四捨五入、退款、訂單狀態與對帳。

這種取捨不是「自由點點看」，而是以責任驅動的探索：你自由，但你要能說清楚你為何把時間投在這裡，以及你如何根據新資訊調整下一步。這就是 Kaner 定義裡「freedom and responsibility」的精神。

(4) James Bach

James Bach 是 Satisfice 的測試顧問，亦是Context Driven Testing社群的重要倡議者之一，對探索性測試的定義與教學影響深遠。

在〈Exploratory Testing Explained〉中，Bach 給出非常經典、被大量引用的定義：

Exploratory testing is simultaneous learning, test design, and test execution.
https://satisfice.us/articles/et-article.pdf

他認為探索性測試之所以是探索性，是因為測試者在測試進行時主動控制測試設計，並用測試中獲得的資訊設計更好的測試。

這裡 Bach 的關鍵是認為控制權在測試者身上：你不是根據別人寫好的東西來執行測試，而是在跑測試的當下，基於證據去改寫你的下一步。

在進行探索性測試過程中，Bach 會不斷詢問自己：這個結果對使用者有意義嗎？這個流程合理嗎？我現在看到的線索，應該引導我設計什麼新實驗來證明它是設計缺陷而非個案？這種「把觀察轉成下一個更尖銳的測試」就是他定義中「用新資訊設計更好測試」的落地方式。

將定義與實務對照後的理解

看完 Wiki 的定義，與 Whittaker、Kaner、Bach 的觀點，可以發現探索性測試並不是對傳統測試的否定，而是一種補足。它特別適合用來處理那些無法在一開始就被完整描述、或在實際使用中才會浮現的問題。下面我們用個表格來比較他們四個的差異。

探索性測試（Exploratory Testing）定義比較表

從比較表看出來的三個關鍵差異

第一，關注層次不同。
Wikipedia 描述的是「測試活動的樣態」，Whittaker 關心的是「測試設計的時點」，Kaner 強調「專業風格與責任」，而 Bach 則回到「測試作為一種思考與證據生成活動的本質」。它們並不是彼此否定，而是在不同高度補齊同一件事。

第二，對測試專業的要求逐步提高。
從 Wikipedia 的中性描述，到 Whittaker 對即時決策的期待，再到 Kaner 對自由與責任並存的要求，最後到 Bach 對判斷、推理與證據品質的重視，可以清楚看到：探索性測試並非低門檻方法，而是高度依賴專業能力的實務。

第三，適用情境並非互斥，而是疊加。
在真實專案中，團隊往往同時處於這四種視角之中：測試活動自然是邊學邊測（Wikipedia），腳本不可避免地被打破（Whittaker），測試人員必須為風險取捨負責（Kaner），而真正有價值的缺陷，往往來自對系統行為「是否合理」的質疑（Bach）。

探索性測試並非對傳統測試的否定，它是一種補足，特別適合處理那些無法在一開始就被完整描述、或在實際使用中才會浮現的問題。它的門檻不在於「敢不敢自由操作」，在於測試人員能否邊測邊學、為風險取捨負責，並把每一次觀察轉化成下一個更好的測試。