探索性測試 Playbook — 半小時找出 5 個 bug 的系統化方法

「探索性測試」常被誤解成「亂點看會不會壞」。真正的探索性測試是有方法、有時限、有產出的。這篇給你一份能立刻套用的 playbook。

Scripted test case 的盲點：

• 寫好的 case 只測你「想得到」的情境
• 重複跑 → 麻木 → 看不到表面以外的問題
• 對「奇怪的使用者行為」毫無覆蓋

探索性測試補的位：

• 在固定時間內找新 bug（不是驗證已知）
• 結合「使用者直覺」找到 case 寫不出的問題
• 對「不會寫測試的 PM / 設計師」也容易上手

最強組合：scripted test 跑 80% → 探索性測試補剩下 20% 的長尾。

SBTM 是 James Bach 提出的探索性測試框架。核心 = 固定時段 × 明確 charter × 結構化筆記。

一個 session 長什麼樣

時長: 60 / 90 / 120 分鐘（建議 90 min）
Charter: 一句話描述「這 session 要探索什麼」
Notes: 邊測邊記錄
產出: bugs / questions / new cases / risks

禁忌：開放式「我來測測看 app」不算 session。必須有 charter。

Charter 設計

公式：探索 <目標>，使用 <資源/工具>，發現 <類型> 的問題

爛例子：

• 「測試登入」（已被 case 覆蓋了）
• 「找 bug」（沒方向）

好例子：

• 「探索『會員等級』升級邏輯，使用測試帳號 A 和 B，找邊界與並發問題」
• 「探索 mobile Safari 上的 checkout 流程，使用 iPhone 13 + iPad Air，找視覺與互動問題」
• 「探索 API /orders 的錯誤處理，使用 Postman 構造異常 payload，找 5xx 路徑」

標準：charter 講完別人就知道你要做什麼、要找什麼。

90 分鐘 session 建議：

不要超過 120 分鐘。注意力會崩、bug 找不到。

Heuristics = 經驗法則 = 「該往哪個方向想」。沒有 heuristics 就只能漫無目的。

經典 1：FAILURE Heuristic

Functional - 功能對嗎？ Appropriate - 對使用者合適嗎？ Inter-system - 跟其他系統互動 OK 嗎？ Logical - 邏輯合理嗎？ Usability - 易用嗎？ Resource - 資源用量合理嗎？ Error - 錯誤處理對嗎？

每個面向問自己 3 個問題，session 內可以快速涵蓋。

經典 2：CRUSSPIC STMPL（James Bach）

不用全背，記幾個強的：

• History — 過去類似 bug 的區域
• Image — 公司品牌、競品比較
• Comparable products — 別家怎麼做
• Claims — spec 怎麼寫
• User expectations — 使用者會怎麼用
• Statutes — 法規限制

經典 3：SFDPOT（測試類別）

• Structure — 程式結構（前端/後端/DB）
• Function — 功能
• Data — 資料的多樣性
• Platform — 平台
• Operation — 使用者操作
• Time — 時間相關（時區、時序）

每次 charter 之前選 1-2 個 SFDPOT 維度當焦點。

我的精簡版（記憶用）

對任何功能我問 7 件事：

1. 空 — 什麼都不輸入 / null 會怎樣？
2. 滿 — 輸入超大值 / 超長字串？
3. 錯 — 故意填錯型別 / 特殊字元？
4. 快 — 連點兩下 / race condition？
5. 慢 — 網路慢 / loading 中斷？
6. 斷 — 中途關掉 / 切換頁面？
7. 怪 — 不該按的順序 / 從 URL 直接進？

90 分鐘 session 至少各跑一輪，bug 自己跑出來。

# Charter: <主題>

<這 session 探索什麼？想找什麼類型的 bug？>

<會碰的 / 不會碰的>

• Account: [email protected]
• Browser: Chrome 124 + iOS Safari 17
• Tools: DevTools / Postman / Charles
• Reference: <spec / 競品 / 歷史 bug>

90 minutes

• FAILURE: Error handling, Resource
• 自選 7 件事: 空 / 快 / 斷

• HH:MM <觀察 / 發現>
• HH:MM <觀察 / 發現>

• [B1] <一句話>
• [B2] <一句話>

• [Q1] <要追問 PM 的事>

• [TC] <值得寫進 regression 的>

• <非 bug 但是風險>

• Coverage: <好的 / 漏的>
• 下次同主題該加: <...>

某次測「會員升級系統」我用 90 min 找到的 bug：

Setup (5 min)

• 開 3 個帳號（銅、銀、金）
• 後台調整可累積消費門檻成低數字方便測
• 開 DevTools Network 監控 API
• Loom 開錄影

Survey (15 min)

• 用銅升銀走一遍：正常
• 用銀升金走一遍：正常
• 看 UI、check「等級」「累積消費」一致

Deep dive (50 min)

Heuristic: 快

• 兩個 tab 同時下單 → Bug 1：兩單都按舊等級結帳、但實際應該升等中
• 連點下單 → Bug 2：訂單被建立兩次（防重複機制無效）

Heuristic: 斷

• 升等動畫中關掉 tab → Bug 3：升等記錄寫 DB 但通知 email 沒寄、且 UI 沒更新

Heuristic: 怪

• 從 admin 後台直接改等級 → 前端 cache 沒更新（Bug 4：等級顯示舊資料、結帳跑新折扣 → 不一致）
• 直接打 API POST /upgrade 跳過前端 → 沒驗證、可以無條件升等（Bug 5：安全漏洞）

Heuristic: 空

• 累積消費剛好等於門檻 → 升或不升？實作是 >，UI 寫「滿足」 → 不一致

Wrap up (15 min)

• 5 個 bug 寫 ticket、附 video
• 3 個 question 給 PM（門檻是 > 還 >=？跨年度怎處理？等級降級後折扣訂單怎處理？）
• 2 個 case 值得加進回歸（並發、cache 一致性）

Review (5 min)

• Coverage 好：邊界、並發、安全
• 漏：i18n、accessibility、不同瀏覽器 → 列下次 charter

1.5 小時 5 個 bug + 3 個 question + 2 個 case + 風險清單。比跑 30 個 regression 還有價值。

互補不對立：

比例建議：CI 上 70% 自動化 + sprint 內 1-2 個 SBTM session × 90 min。

1. 沒 charter 就開始 — 變成「漫遊」、產出低
2. 無時限 — 「我再測一下」變 3 小時、注意力崩
3. 不做 notes — bug 找到但寫 ticket 時想不起重現 step
4. 每次都同主題 — 同個區域重複找、漏掉其他模組
5. 單獨一人做 — 找 dev / PM / 設計師 pair → 對方提的方向你想不到

兩個人一台機，駕駛 + 副駕：

• 駕駛操作 + 講出來「我現在試 X 想看 Y」
• 副駕記 notes、提建議「試試看 Z？」
• 30 分鐘互換

1 + 1 > 2：兩人視角互補、講出來的過程會自我發現問題。

每季至少跟每個角色 pair 一次，QA 視角會被打破。

每個 session 結束後：

1. Bugs → 開 ticket（用 [[bug-report-sop]]）
2. New cases → 加進 regression suite
3. Questions → 帶到 spec review / refinement
4. Risks → retro 提
5. Coverage gaps → 下次 charter 補

不留產出的 session = 浪費時間。

探索性測試是 QA 最有「個人色彩」的工作 — 別人寫的 case 你照跑、但探索性測試是你的腦在轉。練越熟、bug 嗅覺越敏銳，這是 AI 短期內取代不了的能力。每週留出 4-8 小時做這個，你的 QA 直覺會穩定升級。