在這第二十四天，我想再次談談另一種測試類型。到目前為止我建立的所有東西，都依賴於事先知道要檢查什麼：測試案例、API 契約、評估集、迴歸套件，以及品質關卡——每一個都是先寫下一個問題，再開始跑測試。但真實的缺陷不總是遵守我想到要問的那些問題。它們可能出現在兩個功能被一起使用時、出現在某個動作為下一步留下殘留狀態時，或是出現在使用者走了一條完全合理、卻沒有任何人事先寫進測試計畫的路徑時。

探索性測試正是在這裡派上用場。難題在於如何讓探索不淪為「我隨手點了一個小時、發現一些奇怪的東西」。探索需要足夠的結構，讓它的發現有用，卻又不能把它變成一條寫死腳本的測試案例。我想要知道的是：我原本打算調查什麼、我實際探索了什麼、我發現了什麼，以及這些發現之後該去哪裡。目標不是消滅探索本身，而是讓探索變得可追溯。

1. 探索是有章程的調查，不是亂點一通

一次探索性測試始於一份章程（charter）：一段簡短的陳述，說明我想回答的問題、調查的範圍，以及我能投入的時間。目標應該是一個可以被回答的問題，而不是「測試 chatbot」這種空泛的東西。例如，Aurora Shop 的助手可以有這樣一份章程：「在一段連續對話中橫跨退款、換貨與訂單查詢三種意圖，助手是否正確地重用了上一個任務的上下文？」 這讓我有具體的東西可以調查，同時保留決定「怎麼到達那裡」的空間。

範圍同樣重要。如果我把退款 → 換貨 → 訂單查詢列為預定路徑，我就可以刻意變化輸入、重複某些轉換、或故意留下殘留狀態來看看會發生什麼。但金流整合或後台退款審核畫面，可以明確排除在這次測試之外。**時間盒（time box）**則畫出另一個邊界。九十分鐘不代表我一發現有趣的東西就必須立刻停下，但它防止探索變成對「更多問題」的無止境搜尋。在結束時，我可以明確說出自己在這個邊界內檢視了什麼，而不是暗示我測完了整個功能。

2. 用一張人家回頭看得到的測試紀錄表來記錄

一次探索性測試留下的東西，不應該只有一個結論。測試紀錄表（session sheet）記下章程、日期、測試者、起訖時間、實際走過的路徑、發現，以及偏離原計畫之處。這很重要，因為計畫中的路徑與實際走過的路徑往往不同。我可能一開始要測退款 → 換貨 → 訂單查詢，卻發現換貨的回應留下了意外的殘留狀態，於是接下來三十分鐘都循著那個行為追下去。這種偏離本身就是有用的證據，因為它解釋了為什麼這次測試看起來不像原始章程。

像**「測了助手」**這樣一條紀錄，對另一位 QA 幾乎毫無資訊量。有用的紀錄會說明：測過哪些意圖組合、試過哪些輸入形態、重複了幾次、調查在哪裡變得有趣、哪些區域完全沒碰。它也在探索與後續的結構化測試之間搭起橋樑：一個可疑行為可以變成一個缺陷候選，一個漏掉的場景可以變成一個新的評估案例，一個有用的觀察可以變成一條固定的迴歸測試。探索因此成為測試設計的來源，而不是一個測試一結束發現就消失的獨立活動。

3. AI 功能的探索需要刻意設計

AI 功能讓探索性測試格外有價值，因為它們的行為會隨輸入與對話而變化。第一個挑戰是非確定性：同一個問題問三次，可能得到三種不同的回應。這不代表每個變體都是缺陷，但確實代表重複必須是刻意的。如果我在調查 Aurora Shop 的助手是否一致地遵循退款政策，我可能會重複同一個請求數次，並記錄不只是「答案有差異」，而是它們如何不同——僅措辭不同、漏了資訊、政策矛盾，還是做了未經授權的承諾。

第二個挑戰是輸入的長尾。真實使用者不總是產出乾淨的測試案例。他們會打錯字、在一句話講到一半時切換語言、貼上大段文字、送出未完成的訊息，或只回了像「嗯」這麼短的一個字。我也想在更長的對話中探索語氣與上下文：助手會不會逐漸變得不一致、重用了錯誤任務的資訊、宣稱自己已經執行了某個動作，或開始暴露內部措辭？這些都很難用預先定義的案例完全涵蓋，而這正是探索有用的地方。但一旦有意義的行為被發現，它就應該不再只是一個觀察，而要進入對應的結構化產物——無論那是缺陷報告、對抗性案例、評估案例，還是一條固定的迴歸測試。

探索章程

章程編號：EX-024
目標（一句話）：在一段連續的跨意圖對話中，助手是否重用了上一個任務的上下文？
範圍內：退款 -> 換貨 -> 訂單查詢，以連續意圖串接
範圍外：金流整合、後台退款審核畫面
時間盒：90 分鐘
環境與資料：預發佈環境；演練帳號；三筆已出貨訂單（合成資料）
記錄方式：測試紀錄表（逐行筆記 + 對話編號 + 截圖）
產出：缺陷候選、新案例候選、仍待觀察的點
停止條件：時間盒用盡，或同一類問題第三次出現

上面的範例把探索性測試的想法，變成一份可重複使用的工作文件。範例章程 EX-024 問一個具體的問題：在連續的跨意圖對話中，助手是否重用了上一個任務的上下文。它定義了預定路徑——退款 → 換貨 → 訂單查詢——同時明確排除金流整合與後台退款審核。它也建立了 90 分鐘的時間盒、要使用的環境與合成資料，以及以逐行筆記、對話編號與截圖為基礎的記錄方式。

測試紀錄表的這些欄位，讓探索在測試結束之後仍然可以被稽核。它們記下章程與日期、實際起訖時間、走過的路徑、發現、對預定路徑的偏離，以及沒有涵蓋到的區域。這對探索性工作特別重要，因為當證據改變了調查方向，路徑是被允許改變的。如果測試者發現換貨的回應意外地影響了後續的訂單查詢，這個偏離應該被記錄下來，而不是被藏起來。這樣做出來的，是一次另一位測試者看得懂、甚至可以接著繼續的測試，而不是一句「有人花了時間去探索」。

探索找到了腳本漏掉的問題

探索性測試的結果高度依賴測試者的經驗、注意力與當天的狀態（最重要!!），同一份章程換一個人執行，可能發現完全不同的行為。它也不是涵蓋率的良好代理指標，因為探索性測試無法簡單地把次數相加——五次測試不等於五倍的涵蓋。章程透過定義問題、範圍與時間邊界改善了責任歸屬，但它並不保證一定會挖出有價值的東西。它真正的價值是替意外行為安排了去處：一個奇怪的觀察可以變成一個缺陷，一個漏掉的場景可以變成一個新案例，一個被確認的失敗可以變成一條固定的迴歸測試。 因此，探索並不是結構化測試的對立面；它是結構化測試「發現自己一開始就該問什麼」的途徑之一。