2015 年，探索性測試領域最具代表性的兩位人物 James Bach 與 Michael Bolton，宣布棄用「Exploratory Testing」這個詞。理由聽起來很狂：所有測試本質上都是探索性的，所以「探索性測試」是贅詞，直接叫「測試」就好。

連你照著測試案例一步一步執行的那種，也算？對，也算。等一下會解釋為什麼。

這個主張聽起來像文字遊戲，但它背後是近四十年的演進。探索性測試並非一開始就被設計成一套完整方法，它更像是一群資深測試人員，在現實壓力下逐步摸索出來的工作方式，然後才慢慢被命名、被整理、被理論化。

Bach 與 Bolton 把這段歷史分成幾個階段：ET 1.0（反叛）、ET 1.5（闡明）、ET 2.0（整合）、ET 3.0（常態化）[1]。要理解為什麼他們敢說「所有測試都是探索」，得沿著這條軸線走一遍。

萌芽期：這個詞是怎麼來的

1980 年代，商業軟體規模變大、變動速度加快，「先寫完全部測試案例，再逐一執行」的做法開始出現明顯瓶頸。許多測試人員在實務上發現：真正重要的問題，往往在測試過程中「臨時想到去試一下」才被發現，既有的測試案例反而很少抓到。

Cem Kaner 在 1980 年代中期創造了「Exploratory Testing」這個詞，用來指稱腳本式測試的對立面，並在 1988 年出版的《Testing Computer Software》[2]中發表。雖然當時他沒有給出正式定義，篇幅也只有短短幾頁，但他是第一個直接談「一邊執行測試、一邊設計測試」的人。

差不多同一時期，James Bach 在 1987 年進入測試領域。他觀察實際的測試工作後發現一件事：ad hoc 的測試很會抓 bug，高度腳本化的測試反而抓不到。後來他讀到 Kaner 的書，發現自己一直在做的事，已經有人給了名字。

ET 1.0：對腳本測試的反叛

ET 1.0 可以視為一場立場鮮明的反抗運動。在這個階段，探索性測試被刻意拿來與腳本式測試對比。討論的重點不在於流程或管理，而在於否定某些當時被視為理所當然的假設：

• 測試不一定要先把所有步驟寫好；
• 測試案例不等於測試本身；
• 測試人員的判斷力，遠比文件完整度重要。

因此，ET 1.0 常被描述成一種「不寫測試案例、憑經驗與直覺進行測試」的方法。這樣的說法雖然抓住了一部分事實，卻也造成不少誤解，讓探索性測試在早期被貼上「隨意」、「不可控」、「無法管理」的標籤。

但不可否認的是，ET 1.0 成功完成了一件關鍵的事：它把測試人員的思考能力，重新拉回專業舞台的中央。

這個階段大約在 1995 年前後開始轉變。當時全世界積極想把探索性測試發展成一門專業的人，屈指可數。

ET 1.5：把「怎麼探索」講清楚

1995 年，James Bach 加入 ST Labs，開始與 Cem Kaner 展開長達十五年的合作，Rapid Software Testing 方法論也在這時成形。1996 年，第一門名為「Exploratory Testing」的課程開課。

這個階段的重點，是把原本被當成「高手直覺」的東西拆解出來：探索性測試裡到底用了哪些技能？哪些思考模型？哪些啟發法（heuristics）？講不清楚這些，探索性測試就永遠只能是少數人的私房技巧。

1999 年，Microsoft 委託 James Bach 為探索性測試定義一套正式流程。「正式的 ad hoc 流程」聽起來自相矛盾，這個矛盾引發了他與 Kaner 之間一連串的辯論，也為後來的 ET 2.0 鋪了路。

2000 年，James 與 Jon Bach 受 Microsoft 那次經驗啟發，為 HP 的一個團隊開發出 Session-Based Test Management（SBTM）[3]。SBTM 的目的很務實：回答管理者最實際的問題——「我們怎麼知道測試人員做了什麼？學到了什麼？風險被覆蓋到哪裡？」它讓管理者的態度從「不要做那種事」，轉變成「ET 的時段跟測試案例一樣，是可以規劃、可以追蹤的東西」。

ET 2.0：從對立走向整合

隨著探索性測試被更多團隊實際採用，單純的「反腳本」立場已經不足以支撐長期實務。這也促成了 ET 2.0 的出現。

ET 2.0 的核心轉變在於：
探索性測試不再被視為腳本測試的對立面，而是被放進一條連續光譜中理解。

在這個觀點下，所有測試其實都同時包含「探索」與「預先設計」的成分，只是比例不同而已。完全照表執行的測試，探索成分極低；完全即興的測試，腳本成分極低，但兩者並沒有本質上的斷裂。

有了光譜的概念之後，探索性測試的定位也跟著改變：它從一種「技巧」，變成一種可以套用在各種技巧上的「approach」，或者用 Kaner 的說法，一種測試的「風格」（style）。

在這個階段，像 Session-Based Test Management（SBTM） 這類做法開始成形。它不是要把探索性測試變回制式流程，而是嘗試回答管理者最實際的問題：
「我們怎麼知道測試人員做了什麼？學到了什麼？風險被覆蓋到哪裡？」

ET 2.0 強調的是 可溝通性與可理解性。探索性測試不再只是高手的私房技巧，而是一種可以被教、被學、被討論的專業實務。

ET 3.0：重新定義「什麼叫測試」

現在可以回到開頭那個宣告了。2015 年，Bach 與 Bolton 發表〈Exploratory Testing 3.0〉[1]，正式棄用這個他們自己推廣了二十多年的詞，因為所有測試本質上都是探索性的。既然如此，「探索性測試」這四個字就成了贅詞。

走過前面三個階段，這個結論其實水到渠成：

• ET 1.0 證明了探索抓得到腳本抓不到的問題；
• ET 1.5 把探索拆解成可以教的技能；
• ET 2.0 發現探索與腳本位在同一條光譜上，從來沒有分開過。
• 剩下的最後一步，就是承認探索是測試的本體。

真正需要被解釋的問題換了方向。以前要解釋「為什麼要做探索性測試」；現在要解釋的是「為什麼有人會以為測試可以完全不探索」。

這也回答了開頭那個問題：照著測試案例執行，為什麼也算探索？因為只要你在執行時做了任何判斷——覺得畫面怪怪的、多點了一下、回報了步驟裡沒寫的問題——你就在探索。反過來說，如果你完全不做判斷、純機械地照步驟走，Bach 與 Bolton 會說那甚至稱不上測試，只是無意識的檢查（checking）[4]。

值得注意的是，ET 3.0 對「腳本」的定義也比一般人想的寬很多。腳本指的是任何影響你的測試、而且在你選擇範圍之外的控制因素——白紙黑字的測試步驟是腳本，你的偏見是腳本，你的無知是腳本，組織文化也是腳本。

在這個觀點下，腳本被降格為眾多測試技巧之一，用來降低認知負擔、支援重複執行；只要系統行為仍然存在未知、不確定與變動，測試就必然包含探索。用他們自己的總結來說：ET 3.0 把 scripting 降格為一種技巧，把 exploratory testing 升格為測試本身。

ET 1.0、2.0、3.0 的差異

如果把三個階段放在一起比較，差異其實不只是做法，而是測試世界觀的不同：

• ET 1.0 關注的是「對抗什麼」——對抗過度依賴腳本、忽略人腦判斷的測試文化。
• ET 1.5 和2.0 關注的是「怎麼共存」——探索與腳本如何在實務中形成合理分工。
• ET 3.0 關注的是「測試是什麼」——測試本質上就是一個持續探索、持續學習的活動。

這也是為什麼，當你真正理解 ET 3.0 後，往往不再糾結「要不要做探索性測試」，而是開始反問：「在這個情境下，我們的探索做得夠不夠？」

結語：探索性測試不是趨勢，而是成熟的必然結果

想像一個今天很常見的場景：你請 AI 產出一段程式碼，然後打開畫面操作幾下，試幾個邊界值，皺著眉頭想「這邊怪怪的，再多試一下」。這個當下，你在學習系統的行為、設計下一步要試什麼、同時動手執行——這正是 2006 年那個定義描述的活動。

探索性測試能從邊緣走向主流，原因很單純：它忠實反映了軟體系統的現實樣貌——高度複雜、快速變動、充滿未知。在 GenAI 大量產出程式碼、需求持續變動的環境裡做測試，探索的比重只會更高。

參考資料

[1] James Bach & Michael Bolton, Exploratory Testing 3.0, 2015. 本文的階段分期（ET 1.0 / 1.5 / 2.0 / 3.0）與各時期史實均出自此文。 https://www.satisfice.com/blog/archives/1509

[2] Cem Kaner, Testing Computer Software, 1988(初版). 「Exploratory Testing」一詞首次公開發表之處。

[3] Jon Bach, Session-Based Test Management, 2000. SBTM 的原始文章，記錄了在 HP 開發此方法的過程。
https://www.satisfice.com/download/session-based-test-management

[4] James Bach & Michael Bolton, Testing and Checking Refined, 2013. Testing 與 Checking 的區分即出自此文。
https://www.satisfice.com/blog/archives/856