Session Based Test Management（基於 Session 的測試管理，簡稱 SBTM） 是探索式測試領域中最具結構化且廣泛應用的管理框架之一，它讓測試團隊在高度動態的軟體開發環境中，能夠同時維持探索的靈活性、測試的可追蹤性，以及向利害關係人提供可靠的品質資訊。

相較於傳統腳本式測試的預先規劃大量測試案例，SBTM 強調以「時間盒」（time-boxed）的方式組織測試活動，讓測試師在有限且不受干擾的時間內，專注於發現風險、學習產品行為，並快速產出有價值的測試洞察，這種方法特別適合敏捷開發、持續整合、以及需求頻繁變動的專案環境。

歷史背景：從 HP 的實驗室說起

SBTM 最早是在 2000 年 由 James Bach 與 Jon Bach 提出。當時他們在 Hewlett-Packard (HP) 帶領測試團隊，遇到一個難題：如何管理一群高度專業、使用探索性測試的成員？

傳統的測試管理依賴測試案例，但對於快速變動的軟體，寫測試案例太慢，且會限制測試者的思維。Bach 兄弟開發了 SBTM，將「測程」定義為基本工作單位。這篇文章 《Session-Based Test Management》 於 2000 年 11 月正式發表，成為軟體測試史上的重要里程碑。

原始論文參考： Satisfice, Inc. - Session-Based Test Management (Official Download)
https://www.satisfice.com/download/session-based-test-management

SBTM 核心流程：讓探索變得「可管理」

SBTM 的運作並非隨意亂測，它有一套嚴謹的節奏：

Step 1: 制定章程 (The Charter)
這是測試的「地圖」。章程會定義這一個小時內要測試什麼。

例子： 「測試登入模組在連續輸入錯誤密碼時的帳號鎖定機制與錯誤訊息準確度。」

Step 2: 定時執行 (Time-Boxing)
一個標準的 Session 持續 60 到 90 分鐘（Bach 建議不應超過 120 分鐘）。這段時間內「禁止中斷」，這意味著測試者不能回郵件、不能接電話，必須完全進入心流狀態。

Step 3: 紀錄 TBS 指標
這是 SBTM 的科學所在。測試者在結束後需填寫 Session Sheet，紀錄時間分配：

T (Testing): 實際設計與執行測試的時間。
B (Bug Investigation): 發現問題後，花在重現、抓 Log、填報 Bug 的時間。
S (Setup): 準備環境、生成測試資料的時間。

Step 4: 匯報 (Debriefing)
Session 結束後，測試者與經理進行短暫的面談，檢視發現的風險，並決定下一個 Session 的方向。

下面我們使用高鐵訂票系統來當範例，來看看如何使用 SBTM 來進行測試。

一、任務地圖：制定測試章程 (The Charter)

在 SBTM 中，我們不規定步驟，只給定「狩獵範圍」。這份章程可能是這樣的：

章程編號：#HSR-2026-FESTIVAL-001
主題：探索極限併發狀態下的「配位鎖定」與「支付跳轉」穩定性。
任務指引：專注於剩餘票數少於 5 張的熱門車次，模擬使用者在選位後、付款前的各種「猶豫」與「異常」行為。

二、測程執行 (The Session)
作為測試者，你必須切斷所有通訊軟體，進入「心流模式」。這 90 分鐘的過程不會像機器人一樣按表操課，而是一場心理博弈：

(1) 前 20 分鐘 (環境熱身)：
你快速生成 10 組虛擬帳號與信用卡資料。這在 SBTM 紀錄中屬於 S (Setup) 時間。

(2) 中場 40 分鐘 (深度探索)：
你同時開啟兩個瀏覽器，模擬「最後一張票」的爭奪戰。你發現：當兩個人同時進入付款頁面，A 完成付款後，B 的畫面竟然卡死在轉圈圈，而不是優雅地彈出「位子已售罄」。這是一個關鍵的 User Experience 缺陷。

(3) 後 30 分鐘 (極端壓力)：
你嘗試在點擊「確認付款」的瞬間切換飛航模式。你發現系統在網路重連後，沒有保留原始訂單，強迫使用者必須從搜尋頁面重頭來過。

三、 數據回饋
任務結束後，不需要寫幾百頁的報告，重點是產出一份極具價值的 Session Sheet。這份文件對管理層來說，比 Bug 數量更有意義：

在這個過程中，以下有些事情需要注意：

1. 守住時間盒的限制
   SBTM 的靈魂在於 Time-boxing。這不是為了限制產出，而是為了創造一種「必要的緊迫感」。

管理者必須意識到，保護測試員不被打擾，比要求他們找 Bug 更重要。如果一個 Session 被中斷超過三次，這個 Session 就該直接報廢，因為它已經失去了深度探索的連貫性。

2. 匯報（Debrief）是交流，不是審訊
   這是 SBTM 最容易崩壞的環節。當測試員結束 Session 後，主管與他們的 5 分鐘面談應該是：「嘿，你這 90 分鐘觀察到了什麼有趣的現象？」而不是「你怎麼才找兩個 Bug？」

一旦匯報變成了一種「績效考核」，測試員就會開始規避風險。他們會專挑容易找 Bug 的地方測，而那些真正幽暗、危險、可能藏有毀滅性漏洞的邊角邏輯，將永遠沒人敢去碰。

3. 紀錄的溫度：Session Report的質與量
   別讓測試員花半小時寫報告。一個好的 Session Report 應該像是一份偵探筆記——簡潔、有力、充滿疑點。它應該紀錄的是「我做了什麼假設」、「我遇到了什麼困惑」以及「我建議接下來該測什麼」。

SBTM是一場關於紀律的修煉。 當團隊能純熟地在章程邊界內，專注地燃燒那 90 分鐘，你所獲得的不僅僅是 Bug 列表，更是一份關於產品健康狀況的深刻洞察。

從認知科學與心理學的角度來看，SBTM (Session-Based Test Management) 之所以能大幅提升測試品質，並非只是流程設計得好，而是因為它完美契合了人類大腦處理複雜問題的生理機制。

如果我們將測試視為一場「智力狩獵」，SBTM 正是透過以下四個科學維度，將測試者的大腦效能推向極致：

1. 啟動「心流狀態」的環境保護
   
   心理學提出的「心流」，是指一個人完全沈浸在活動中，失去時間感並獲得極大成就感的狀態。

在SBTM 中透過 60-120 分鐘的 Time-boxing（時間盒），SBTM 強制建立了一個「認知保護區」，讓大腦可以維持極高的「工作記憶」（Working Memory）。

否則頻繁的切換任務會產生「轉換耗損」。研究指出，大腦重新進入深度專注狀態平均需要 23 分鐘。SBTM 拒絕中斷，讓測試員的認知資源能全力集中於邏輯推理，而非處理分心雜訊。

2. 章程引導下的「啟發式搜索」（Heuristic Search）
   認知科學研究顯示，人類大腦在解決問題時，並非像電腦一樣進行窮舉搜索，而是依賴「啟發式（Heuristics）」，也就是基於經驗的簡便法則。

在SBTM 中Charter（章程） 扮演了「認知引導」的角色。它不給指令，而是給一個「目標邊界」。這能激發大腦的「選擇性注意」（Selective Attention）。

當大腦知道目標是「找出支付系統的漏洞」時，它會自動過濾無關的 UI 細節，強化對異常訊號的敏感度。這比照著腳本點擊（Scripted Testing）更能啟動大腦的「發散性思維」，從而發現那些預期之外的 Bug。

3. TBS 指標帶來的「認知負荷」視覺化
   SBTM 要求紀錄 TBS (Testing, Bug, Setup) 時間比例，這在心理學上具有極強的反饋意義。

當測試員發現自己的 S (Setup) 時間過高時，他們會感受到一種「效率焦慮」。

這種數據化讓「無形的工作」變得「有形」。這不僅是給主管看的，更是給測試員自己的反饋。根據「自我效能理論」，當測試員能看見自己投入在核心測試（T）的時間比例提升時，會增強其專業認同感與成就感，進而形成良性循環。

4. 匯報機制（Debriefing）與「社會助長」效應
   心理學中的「社會助長」（Social Facilitation）指出，當個人知道自己的表現會被觀察或討論時，在熟練任務上的表現會提升。

Session 結束後的簡短面談，創造了一個專業對話空間。測試員不再是孤島，他們知道自己的發現將在 90 分鐘後與另一位專業人士（主管或同儕）分享。這種心理預期會促使大腦在執行過程中保持更高的警覺性與邏輯自洽，避免「認知怠惰」。

傳統測試把人當成執行腳本的 CPU，但 CPU 不具備直覺。SBTM 的科學基礎在於尊重人類的認知限制，同時極大化人類的聯想能力。它利用時間壓力來對抗拖延，利用目標邊界來聚焦能量，最終讓測試變成一種高效的智力活動。

這也是為什麼SBTM 常被視為「人性化管理」在技術領域的具體實踐，它讓測試員重新找回了思考的主動權。