---
title: 探索性測試 Playbook — 半小時找出 5 個 bug 的系統化方法
description: 探索性測試不是「亂玩」。SBTM session、Heuristics（FAILURE、CRUSSPIC）、Charter 設計、結果記錄完整指南。
category: manual
tags: [exploratory-testing, sbtm, heuristics, 手動測試, charter]
date: 2026-06-10
---

# 探索性測試 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

**F**unctional - 功能對嗎？
**A**ppropriate - 對使用者合適嗎？
**I**nter-system - 跟其他系統互動 OK 嗎？
**L**ogical - 邏輯合理嗎？
**U**sability - 易用嗎？
**R**esource - 資源用量合理嗎？
**E**rror - 錯誤處理對嗎？

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

### 經典 2：CRUSSPIC STMPL（James Bach）

不用全背，記幾個強的：

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

### 經典 3：SFDPOT（測試類別）

- **S**tructure — 程式結構（前端/後端/DB）
- **F**unction — 功能
- **D**ata — 資料的多樣性
- **P**latform — 平台
- **O**peration — 使用者操作
- **T**ime — 時間相關（時區、時序）

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

### 我的精簡版（記憶用）

對任何功能我問 7 件事：

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

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

## Charter 模板（直接套）

```markdown
# Charter: <主題>

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

## 範圍
<會碰的 / 不會碰的>

## 資源 / 工具
- Account: qa-test-007@example.com
- 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。

## 探索性測試的反模式

1. **沒 charter 就開始** — 變成「漫遊」、產出低
2. **無時限** — 「我再測一下」變 3 小時、注意力崩
3. **不做 notes** — bug 找到但寫 ticket 時想不起重現 step
4. **每次都同主題** — 同個區域重複找、漏掉其他模組
5. **單獨一人做** — 找 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 結束後：

1. **Bugs** → 開 ticket（用 [[bug-report-sop]]）
2. **New cases** → 加進 regression suite
3. **Questions** → 帶到 spec review / refinement
4. **Risks** → retro 提
5. **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 直覺會穩定升級。