在快速迭代的開發環境中，探索性測試常被誤解為隨興、無計畫的試誤。然而，缺乏方向的探索往往會演變成一場災難：測試員在細節中迷失，產出大量無關緊要的 Bug，卻漏掉了關鍵的架構風險。

測試章程（Test Charter） 的核心價值就在於此：它不是僵化的操作指令，而是一份導航工具。章程的存在是為了在「完全自由」與「嚴格規範」之間找到平衡點，將盲目的行為轉化為有目標的資訊獲取，確保測試資源精確投放於最有價值的地方。

探索性測試並非只是為了「找 Bug」，其真正的價值在於為團隊獲取「相關、有趣且有用」的資訊。

這些資訊不應只存在於測試員的腦中，而是必須具備影響開發方向的力量，進而驅動以下關鍵決策：

• 程式碼決策 (Code Decisions)： 協助工程師判斷是否需要進行重構、優化效能或修正邏輯漏洞。
• 設計決策 (Design Decisions)： 提供實測反饋，評估目前的產品設計是否真的解決了用戶痛點，或是否需要調整交互邏輯。

關鍵在於區分「驗證（Checking）」與「探索（Exploring）」。驗證是確認我們「已知」的事實，而透過章程引導的探索，則是為了揭示我們「未知」的領域，將潛在的風險具象化為可供團隊討論的資訊。

為了讓章程具備結構化且易於溝通，我們介紹Elizabeth Hendrickson的測試章程格式：

Explore [Scope] 
With [Resources] 
To discover [Risk/Information]

• Scope (範圍)
  測試的主體。你想要測試的東西、產品功能、或是一個特定的概念與想法。

這裡是用來確立測試邊界。若範圍不明，測試會變得過於發散（Scope Creep），導致資源浪費在邊緣情境。

• Resources (資源)
  測試的工具與手段。包含所需的測試數據 (Data)、工具 (Tools)、特定的技術或測試方法。

利用不同的數據組合或工具，能讓測試員從不同維度切入。缺乏適當資源的章程，往往只能觸及表層。

• Risk (風險/資訊)
  測試的目的 (Why) 。章程的靈魂。指你想發現的特定資訊，通常直接對應到潛在的業務或技術風險。

這是最關鍵的一環。我們應將「發現資訊」與「風險揭示」掛鉤。沒有明確目標（Why）的測試僅是漫無目的的點擊，而與風險掛鉤的章程，則能直接回饋商業價值，為團隊節省後續修正的時間成本。

測試章程就像是一個「有圍欄的遊樂場」。這不僅是一種限制，更是一種保護：

章程設定了範圍，確保測試員在正確的區域活動。它防止了測試變成隨機且低效的動作，確保產出的資訊對團隊是有意義的。

在圍欄之內，測試員擁有絕對的自由。你可以自由決定要用什麼姿勢玩滑梯、實驗各種操作組合或模擬極端場景，而不必受限於死板的測試步驟（Test Case）。

測試章程的作用是確保「有目標的探索」。它賦予測試員在特定邊界內自由發揮的空間，同時確保測試成果具備高度的專注度與團隊價值。

我以「高鐵早鳥票」功能為核心，為您撰寫了三個結構化的測試章程：

章程 1：探索折扣切換的時機點
Test [Scope]： 早鳥優惠價格階梯的動態切換機制。
With [Resources]： 開賣邊界時間（如 23:59 vs 00:01）、各級距（65/80/90）剩餘票數極少的測試數據。
To discover [Risk/Information]： 揭露系統在配額耗盡瞬間，價格顯示是否會產生延遲或不一致，確保業務風險中的「獲益損失」降到最低。

章程 2：壓力下的資源競爭行為
Test [Scope]： 高併發環境下的訂位鎖定機制。
With [Resources]： 自動化負載工具、多個同時嘗試預訂最後一組配額的虛擬使用者。
To discover [Risk/Information]： 發現是否存在競爭條件（Race Condition），導致系統狀態不穩或資料庫死鎖，這比單純測試功能對錯更具資訊價值。

章程 3：非常規的路徑變更與補償邏輯
Test [Scope]： 早鳥票生命週期中的異常變更流程。
With [Resources]： 過期訂單、已部分退款的紀錄、多種班次組合（熱門轉冷門、冷門轉熱門）。
To discover [Risk/Information]： 探索是否存在「未預期」的改票路徑，讓測試員能像在遊樂場一樣隨意組合操作，找出邏輯漏洞。

接下來我以說故事的方式，呈現在一個專案中，如何利用測試章程來討論如何測試 Google 首頁的過程：

「欸，你們不覺得每天在那邊寫『輸入 A，預期出現 B』的 Test Case 真的很像機器人嗎？」QA 邊攪動咖啡邊起頭。

「確實啊，」RD 點點頭，「而且很多 Bug 根本不是照著步驟走會發現的，通常是那種『手殘多按了一下』或是『網路突然斷掉』才噴出來。那種死板腳本根本抓不到。」

於是，大家決定放下厚厚的 Excel，改用 Elizabeth Hendrickson 推薦的 Test Charter，來一場更有靈魂的探索。

第一階段：定調——什麼是「有圍欄的遊樂場」？

QA 在白板上寫下那個經典句型：

Test [Scope] With [Resources] To discover [Risk/Information]

PM： 「所以這意思不是要限制測試員，而是幫他們蓋一個『圍欄』對吧？」

QA： 「沒錯！為什麼要這樣做？因為如果範圍不明，測試會變得太發散，導致資源浪費在邊緣情境。但有了圍欄，測試員在裡面就有絕對的自由，隨便你要用什麼姿勢玩滑梯、挖沙坑都可以。這種隨意組合操作產出的資訊，對團隊來說才是最有意義的。」

第二階段：實戰拆解——Google 首頁的 4 個關卡

大家開始對著 Google 那個極簡的首頁，按照「如果這壞了，老闆會不會瘋掉」的優先順序來拆解：

【最優先 P0】生命線：搜尋框的極限壓力
Explore [搜尋輸入框] 
With [貼上一萬字長文、亂碼、特殊符號] 
To discover [前端會不會崩潰，或請求會不會莫名失蹤]。

我們與其測「能不能搜尋」，不如去探查「輸入什麼會讓它掛掉」。這種「發現資訊」與「風險揭示」掛鉤的做法，才能直接回饋商業價值。

【重要 P1】門面：搜尋建議（Autocomplete）
Explore [自動完成清單] 
With [熱搜字、拼錯字、瘋狂連按鍵盤] 
To discover [API 回傳建議的延遲感，或是否出現不合政策的敏感詞]。

我們需要利用不同的數據組合從不同維度切入，因為缺乏適當資源的章程，往往只能觸及表層。

【次要 P2】國際觀：在地化排版（L10N）
Explore [不同國家的首頁] 
With [由右至左語言 (RTL)、不同時區] 
To discover [排版有沒有噴掉，或是該反向顯示的 UI 有沒有乖乖聽話]。

Google 必須確保在特殊語言（如阿拉伯文）下，搜尋按鈕的位置不會跑版，這就是所謂的「特定概念與想法」的測試主體。

【合規 P3】貼心感：無障礙（Accessibility）
Explore [全鍵盤操作] 
With [只按 Tab 鍵、螢幕閱讀器] 
To discover [身障朋友能不能順利完成搜尋]。

沒有明確目標的測試僅是漫無目的的點擊，而與風險掛鉤的章程，則能為團隊節省後續修正的時間成本。

最後，PM 指著白板問：「那所以這跟以前的 Test Case 到底差在哪？我們以後不寫 Case 了嗎？」

QA 整理出這張對照表，強調「靈魂」的不同：

當測試不再是單調的勾選 Checkbox，大家反而更有動力去找出那些連 RD 都沒想過的 Bug。這就是測試章程的魔力：給予絕對自由，但保留專業的專注。

當你面對一個功能卻不知道該測什麼時，可以利用 SFDPOT 的六個維度來強制自己切換視角，從而挖掘出被忽略的測試區域。

SFDPOT源自於 James Bach所開發的 HTSM（Heuristic Test Strategy Model，啟發式測試策略模型）。在 1990 年代末期，James Bach 為了幫助測試人員在極短時間內掃描產品的覆蓋維度，將「產品元素」提煉成了這組助記符。它最初是為了 Rapid Software Testing (RST) 課程而生，如今已成為全球專業測試人員在撰寫 Test Charter（測試特許狀） 時的標準配備。

SFDPOT 是一組「啟發式（Heuristics）」方法。所謂啟發式，就是指「雖然不保證一定成功，但在實務上非常有用的思考捷徑」。

我們以一個真實的「電商領券功能」為例，展示如何從 SFDPOT 推導出 測試章程，再落地到具體的 Test Case 與 Data。

步驟 1：使用 SFDPOT 產出 Test Charter
我們不只是測「點擊領券」，而是利用 SFDPOT 展開廣度。根據 [P] 與 [T] 維度，我們定義出這份 Charter：

Charter 001： 「探索在極端網路環境(P)與活動啟動臨界時間(T)下，領券功能的穩定性。」

步驟 2：從 Charter 延伸出具體的測試執行
有了 Charter 後，測試人員在執行探索時，會具體測什麼？

(1) 具體測試點 (Test Case / Scenarios)
場景 A (Time + Operations)： 在活動開始前的 0.5 秒內，由 50 位用戶同時「瘋狂連點」領取按鈕。

場景 B (Platform + Data)： 用戶在領取瞬間，網路從 WiFi 切換到 4G（模擬信號不穩），觀察是否會出現「扣了額度卻沒領到券」的狀況。

(2) 關鍵測試數據 (Test Data)
時間數據： 2026-11-11 23:59:59.990（活動開始前夕）。
網絡參數： Latency = 3000ms, Packet Loss = 15%。
使用者狀態： 同一 UserID 發送併發請求 count=10。

當我們產生一些測試章程後，要如何覺得哪些要先處理呢？根據 Michael D. Kelly的建議，拇指投票法（Thumb Voting）可以幫忙，它是一種用於團隊快速達成共識，並決定測試優先順序的技巧。做法如下：

團隊快速瀏覽列表中的每一個測試章程，並對每一個章程進行投票。成員使用大拇指的方向來表達他們對該測試任務優先級的看法：

(1) 拇指向上 (高優先級)：
代表「我們必須執行這個章程。」這是核心任務，必須被納入測試範圍。

(2) 拇指橫向 (中優先級)：
代表「如果有時間，我們應該執行這個章程」。這是次要任務，屬於「做了更好 (Nice to have)」的範疇。

(3) 拇指向下 (低優先級)：
代表「這是一個測試，我們雖然可以執行它，但很可能有其他更值得花時間的地方」。這通常意味著該測試的價值較低，或者風險不高，可以被捨棄。

拇指投票法不僅僅是為了投票，更重要的是它能「識別分歧」。當你發現團隊成員投票後，這個章程的方向非常不一致，有些人覺得是高優先級，有些成員覺價值很低，這將會引導團隊進行討論與辯論。這種討論通常會帶來兩個正向結果：

• 釐清該測試的目標與範圍。
• 可能會因為討論而衍生出新的測試章程，讓測試更完善。

總結來說，拇指投票法是一個簡單但強大的工具，能幫助測試團隊在有限的時間內，將精力集中在最重要、最具風險的測試任務上。

Tips for Writing Better Charters for Exploratory Testing Sessions by Michael D Kelly
https://www.slideshare.net/slideshow/mike-kelly-euro-star-webinar/22497017