探索性測試（Exploratory Testing, ET）大概是測試領域中最常被誤解的一種方法。有人以為它就是「隨便亂點」，有人以為它是沒時間寫腳本時的備案，也有人認為自動化普及之後它就沒有存在的必要。

本文將常見的問題整理成三大類：基礎概念、常見迷思破解與實務做法，希望幫助你建立對探索性測試的完整理解。

一、基礎概念

Q1：什麼是探索性測試的核心定義？

它是一種「同時性」的過程。

探索性測試並非預先寫好步驟再執行，而是在測試的過程中，同時進行「學習、測試設計與執行」。測試員根據上一步的結果，即時決定下一步該測什麼。

這種「觀察 → 思考 → 調整計畫 → 執行」的循環（類似 OODA Loop），正是探索性測試的精髓。

Q2：為什麼我們需要探索性測試？它有哪些主要優點？

它能彌補腳本測試（Scripted Testing）的盲點，主要優點包括：

(1) 發現隱藏 Bug：能找出那些預設腳本未涵蓋的極端案例（Edge Cases）。
(2) 更貼近真實用戶：模擬用戶隨意操作產品的真實行為，而非機械式的路徑。
(3) 效率高：減少撰寫大量前期文件的時間，能快速對新功能進行評估。
(4) 智力挑戰：提升測試員的參與感，鼓勵主動思考而非被動執行。

另外值得一提的是，過度依賴預寫腳本反而有害——腳本會造成「注意力盲區」。當測試員只專注於執行腳本上的步驟時，往往會忽略掉那些腳本沒寫到、但顯而易見的嚴重問題。

Q3：探索性測試適合在什麼時候執行？

它在以下場景特別有效：

(1) 開發早期：當需求仍在變動，還沒時間寫詳細腳本時。
(2) 快速迭代：在敏捷開發（Agile）中，需要快速回饋時。
(3) 遇到複雜 Bug 時：需要深入追蹤問題根源（Root Cause）時。
(4) 腳本測試完成後：作為最後一道防線，檢查是否有遺漏的邏輯漏洞。

Q4：探索性測試在敏捷開發中扮演什麼角色？

它是快速回饋的關鍵。

在敏捷開發中，需求變動極快。探索性測試允許測試員在沒有正式文件的情況下立即開始測試新功能，為開發者提供即時的回饋循環（Feedback Loop），這比等待撰寫完詳細測試用例要高效得多。

二、常見迷思破解

迷思 1：探索性測試就是「隨機測試」（Ad-hoc Testing）？

不是。這是最常見的誤解。

隨機測試通常是無計畫、無記錄且不可重複的；而探索性測試是有目標、有結構的過程。它強調一邊學習、一邊設計測試並同時執行。雖然它賦予測試人員自由度，但專業的探索性測試會使用「測試章程」（Test Charters）來定義範圍，並詳細記錄過程。

迷思 2：探索性測試不需要計畫、缺乏結構？

完全錯誤。它不是「無計畫」，而是「邊做邊計畫」。

傳統測試是「先計畫再執行」，兩者完全分離；而探索性測試中，計畫是一個連續且即時的過程。測試員會根據目前的發現，隨時調整接下來的測試方向。

兩者的本質差異在於「指令」與「策略」的區別：

• 傳統計畫：像是一份詳盡的「遺囑」，在事情發生前就寫死，難以應對突發狀況。

• 探索性計畫：更像是一場「對話」或「偵查行動」，定義「我們要探索什麼」和「怎麼探討」，但保留實行細節的靈活性。

James Bach 強調，專業的探索性測試包含以下計畫元素：

• 明確的目標：知道為何而測（如：穩定性、安全性、邊界條件）。
• 資源配置：決定投入多少時間與人力。
• 風險評估：優先測試最容易崩潰或最重要的模組。
• 任務拆解：將測試拆成多個小的「會話」（Sessions）。

所以探索性測試絕不是「隨心所欲」——它受限於Charter（規定測試的邊界，例如只測購物車的結帳邏輯）與 Timebox（限制在固定時間內完成，確保進度可控）。這種「有約束的自由」才是專業的探索性測試。

而「邊做邊計畫」之所以比「預先計畫」更有效率，是因為它減少了「維護過時文件」的成本。在軟體快速變動的環境中，預寫的腳本很快就會失效；探索性測試讓計畫保持最新狀態，讓測試員能將精力專注在「發現新資訊」上，而非盲目地完成已過時的待辦清單。

迷思 3：探索性測試就是「不寫文件」的測試？

絕對不是。差別在於文件記錄的「時間點」與「目的」不同。

很多人混淆了「預先定義的腳本」與「記錄」，認為只有測試前寫好的步驟才叫文件。事實上，傳統測試是在測試前寫好「腳本」；探索性測試則是在測試過程中（或之後）進行「記錄」，而且產出的文件往往更豐富。

兩者本質上的區別在於「指令」vs.「紀錄」：

• 傳統腳本：像是「食譜」，要求測試員照著做，限制了思考。
• 探索性紀錄：像是「航海日誌」，記錄了探險家在未知海域看到了什麼、做了什麼決策。它更具動態性，能反映出測試員的專業思考過程。

迷思 4：只有新手、或沒時間寫腳本時，才用探索性測試？

完全相反。

探索性測試需要豐富的經驗、領域知識（Domain Knowledge）以及強大的批判性思考能力與觀察力。新手往往只能看到表面，而資深測試員能利用經驗，從微小的異常（Hints）中察覺潛在風險，發現隱藏在複雜邊界條件下的深度缺陷。

雖然每個人都能「探索」軟體，但探索性測試的成效高度依賴測試員的技能（Skill-dependent），並非每個人隨便玩玩就能達到同樣的效果。它是指令式腳本測試的重要補充，而非「最後一刻」的備案。

測試員在測試時究竟在想什麼？他們在進行「即時建模」——一邊操作軟體，一邊在腦中構建軟體的運作模型（Mental Model）。當實際行為與模型不符時，計畫就會立刻轉向，深入挖掘該異常點。

迷思 5：探索性測試只是為了找 Bug？

不只是找 Bug，更多是為了「學習」。

探索性測試的核心在於對產品的深入理解。透過探索，團隊可以發現需求中的矛盾、易用性問題，或是產品在極端情境下的行為。它能提供關於產品「品質狀態」的深度洞察，而不僅僅是一張 Bug 清單。

迷思 6：探索性測試無法衡量進度或覆蓋率？

可以衡量。

透過「基於會話的測試管理」（Session-Based Test Management, SBTM），管理者可以追蹤測試人員在特定時間塊（Sessions）內的工作內容。覆蓋率則可以透過「測試章程」所涵蓋的功能模組或風險區域來評估。

迷思 7：探索性測試缺乏「可重複性」？

這取決於記錄的品質。

雖然探索性測試不像腳本測試那樣每次都走「完全相同」的路徑，但透過詳細的測試日誌（Test Logs）、截圖與錄影，發現的 Bug 是完全可以重現的。更重要的是，它能重複「探索的精神」——在不同的測試會話中，從不同角度切入系統。

迷思 8：有了自動化測試，就不需要探索性測試了？

兩者互補，缺一不可，甚至可以說是最佳拍檔。

關鍵區別在於：自動化測試是「檢查（Checking）」，而探索性測試是「探索（Exploring）」。

• 自動化測試：擅長執行「已知的已知」——驗證預期行為、確認已知功能沒有壞掉（回歸測試），處理重複性、可預測的檢查。
• 探索性測試：擅長挖掘「未知的未知」——發現預期外的問題，處理自動化腳本無法預見的複雜情境，以及只有人類感官才能察覺的體驗問題。

自動化將測試員從繁瑣的重複工作中解放出來，讓他們有更多時間專注於「人類更擅長」的領域——也就是更高價值的探索性工作。

三、實務做法

Q1：探索性測試的標準流程是什麼？

雖然靈活，但通常遵循以下五個步驟：

• 分類（Classify）：識別軟體中的常見錯誤類型，找出風險區域。
• 建立測試章程（Create a Charter）：定義測試的目標（測什麼）、範圍（界限在哪）與方法。
• 時間箱管理（Time-boxing）：設定一個專注的時段（通常為 60–120 分鐘），期間不受干擾。
• 審查結果（Review Results）：分析發現的 Bug，評估是否需要進一步探索。
• 彙報（Debriefing）：將結果與開發團隊分享，比較預期與實際表現。

Q2：執行探索性測試時需要記錄哪些內容？

重點在於「重現問題」的能力，以及記錄「我們做了什麼」和「我們發現了什麼」。與其照著舊腳本勾選「通過／失敗」，探索性測試更像是一場科學實驗或調查。記錄的內容通常包括：

• 測試章程（Charters）：我們要探索什麼？
• 測試路徑與筆記（Notes）：使用了什麼數據、點了哪些按鈕、嘗試了哪些路徑、發生了什麼異常。
• 異常證據：系統異常反應的截圖或錄影。
• 發現（Discoveries）：新的 Bug、新的風險、對需求的新理解，以及產生的新想法（例如：測完 A 發現 B 可能也有問題）。
• 覆蓋範圍（Coverage）：實際上測到了哪些邏輯分支或數據組合。

Q3：如果沒有預寫腳本，如何證明測試已經完成了？

專業的探索性測試員會提供詳盡的活動記錄（如 SBTM）。這份記錄能告訴利害關係人：測試員投入了多少時間、測試了哪些區域、發現了哪些問題。這比單純勾選「已執行」的腳本，更能體現測試的價值。

Q4：進行探索性測試需要特定的工具嗎？

工具是輔助，思維才是核心。

雖然探索性測試主要依賴大腦思考，但好的工具可以幫助記錄，例如：

• 瀏覽器擴充功能：快速截圖與標註。
• 測試管理工具（如 Xray、Zephyr）：管理測試章程與紀錄。
• 錄屏軟體：記錄複雜的操作路徑以便重現。

結語

探索性測試不是隨機亂測，不是不寫文件，更不是自動化的替代品或備案。它是一種需要高度技能、有章程約束、有紀錄可循的專業測試方法。自動化負責守住「已知的已知」，探索性測試負責挖掘「未知的未知」——兩者搭配，才能真正建立對產品品質的完整信心。而它最珍貴的產出，往往不是那張 Bug 清單，而是團隊對產品更深一層的理解。