探索性測試 Playbook — 半小時找出 5 個 bug 的系統化方法
「探索性測試」常被誤解成「亂點看會不會壞」。真正的探索性測試是有方法、有時限、有產出的。這篇給你一份能立刻套用的 playbook。
為什麼需要探索性測試
Scripted test case 的盲點：
- 寫好的 case 只測你「想得到」的情境
- 重複跑 → 麻木 → 看不到表面以外的問題
- 對「奇怪的使用者行為」毫無覆蓋
探索性測試補的位：
- 在固定時間內找新 bug（不是驗證已知）
- 結合「使用者直覺」找到 case 寫不出的問題
- 對「不會寫測試的 PM / 設計師」也容易上手
最強組合：scripted test 跑 80% → 探索性測試補剩下 20% 的長尾。
SBTM — Session-Based Test Management
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 講完別人就知道你要做什麼、要找什麼。
60 / 90 / 120 分鐘的時間分配
90 分鐘 session 建議：
| 階段 | 時間 | 動作 |
|---|---|---|
| Setup | 5 min | 準備帳號、清空 cache、開 DevTools、開錄影 |
| Survey | 15 min | 走過主要路徑「感受」一遍 |
| Deep dive | 50 min | 抓重點區域深挖 |
| Wrap up | 15 min | 整理 notes、寫 bug、補拼圖 |
| Review | 5 min | 自評：覆蓋哪、漏哪 |
不要超過 120 分鐘。注意力會崩、bug 找不到。
Heuristics — 探索的方向感
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 件事：
- 空 — 什麼都不輸入 / null 會怎樣？
- 滿 — 輸入超大值 / 超長字串？
- 錯 — 故意填錯型別 / 特殊字元？
- 快 — 連點兩下 / race condition？
- 慢 — 網路慢 / loading 中斷？
- 斷 — 中途關掉 / 切換頁面？
- 怪 — 不該按的順序 / 從 URL 直接進？
90 分鐘 session 至少各跑一輪，bug 自己跑出來。
Charter 模板（直接套）
# Charter: <主題>
## 目標
<這 session 探索什麼？想找什麼類型的 bug？>
## 範圍
<會碰的 / 不會碰的>
## 資源 / 工具
- Account: [email protected]
- Browser: Chrome 124 + iOS Safari 17
- Tools: DevTools / Postman / Charles
- Reference: <spec / 競品 / 歷史 bug>
## 時限
90 minutes
## Heuristics 焦點
- FAILURE: Error handling, Resource
- 自選 7 件事: 空 / 快 / 斷
---
## Notes（邊測邊記）
- HH:MM <觀察 / 發現>
- HH:MM <觀察 / 發現>
## Bugs found
- [B1] <一句話>
- [B2] <一句話>
## Questions
- [Q1] <要追問 PM 的事>
## New test cases
- [TC] <值得寫進 regression 的>
## Risks
- <非 bug 但是風險>
## 自評
- Coverage: <好的 / 漏的>
- 下次同主題該加: <...>
實戰範例：90 分鐘找出 5 個 bug
某次測「會員升級系統」我用 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 還有價值。
SBTM 跟自動化的關係
互補不對立：
| 自動化 | 探索性測試 |
|---|---|
| 覆蓋已知路徑 | 探索未知 |
| 重複跑 | 一次性 |
| 跑得快 | 思考密集 |
| 容易僵化 | 容易混亂 |
| 抓 regression | 抓新 bug |
比例建議：CI 上 70% 自動化 + sprint 內 1-2 個 SBTM session × 90 min。
探索性測試的反模式
- 沒 charter 就開始 — 變成「漫遊」、產出低
- 無時限 — 「我再測一下」變 3 小時、注意力崩
- 不做 notes — bug 找到但寫 ticket 時想不起重現 step
- 每次都同主題 — 同個區域重複找、漏掉其他模組
- 單獨一人做 — 找 dev / PM / 設計師 pair → 對方提的方向你想不到
多人 Pair Exploratory Testing
兩個人一台機，駕駛 + 副駕：
- 駕駛操作 + 講出來「我現在試 X 想看 Y」
- 副駕記 notes、提建議「試試看 Z？」
- 30 分鐘互換
1 + 1 > 2：兩人視角互補、講出來的過程會自我發現問題。
跟其他角色 pair
| 角色 | 一起測能發現的 |
|---|---|
| Dev | 內部實作邊界、隱藏狀態 |
| PM | 對 spec 模糊的詮釋差異 |
| Designer | 視覺、互動、accessibility |
| Support | 真實使用者抱怨點 |
| Marketing | 跨 campaign 的整合場景 |
每季至少跟每個角色 pair 一次，QA 視角會被打破。
把 SBTM 結果整合回流程
每個 session 結束後：
- Bugs → 開 ticket（用 [[bug-report-sop]]）
- New cases → 加進 regression suite
- Questions → 帶到 spec review / refinement
- Risks → retro 提
- Coverage gaps → 下次 charter 補
不留產出的 session = 浪費時間。
工具推薦
| 工具 | 用途 |
|---|---|
| Loom / CleanShot | 螢幕錄影、找 bug 後直接附 |
| Sense / Rapid Reporter | SBTM session 專用 notes app |
| Notion / Obsidian | 累積 charter 模板與歷史 |
| Mind map (Miro / Xmind) | 視覺化 charter 涵蓋 |
| Chrome DevTools Recorder | 把找到 bug 的步驟錄成可重播 |
最後
探索性測試是 QA 最有「個人色彩」的工作 — 別人寫的 case 你照跑、但探索性測試是你的腦在轉。練越熟、bug 嗅覺越敏銳，這是 AI 短期內取代不了的能力。每週留出 4-8 小時做這個，你的 QA 直覺會穩定升級。