為了有效地管理測試，測試領導需要評估測試團隊的生存力、當前測試的進度、測試覆蓋的范圍、已經暴露的風險、測試人員是否需要幫助等因素。一個好的測試流程可以幫助測試領導和測試團隊了解這些因素，並實施積極的管理。為了使探索式測試滿足軟件開發團隊對可管理性的要求，Jonathan Bach和James Bach提出了基於測程的測試管理（Session-Based Test Management，簡稱SBTM）[Bach2000]。本文將介紹SBTM的概念與方法。
Session的翻譯：測程
在翻譯Session時，我遇到了困難，因為現有的中文表達難以傳遞出SBTM中Session的兩層含義：
- Session是一段不受打擾的測試時間（通常是90分鍾），是測試管理的最小單元。
- 一系列Session相互支持，有機地組合在一起，周密地測試了整個產品。
在如此語境下，Session的同義詞是Term（學期、會期）、Period（時段、課時）、Semester（學期），但是直接使用這些同義詞的中譯並不適當。進過反復考慮，我將Session翻譯為“測程”，原因有三點：
- 用專用術語“測程”指代SBTM的Session，與Session的其他含義或中譯（如“會話”）做明顯的區分，這有利於快速、清晰地傳達語義。
- “測程”表達出Session的基本語義：一段專注於測試的過程。
- “測程”與“課程”有相似的詞匯結構，暗示了一系列測程組合在一起研究了整個產品，正如課程通過一系列課時討論了一個完整的領域。
測程的四個要點
測試專家Michael Bolton用一頁幻燈片總結了SBTM的特征與內容[Bolton2006]。
如幻燈片的標題和右側的圖畫所示，SBTM的重要特征是將測試過程分解為一組測程，從而提高整個測試項目的可說明性（Accountability）。為此，一個測程包含四個要點：主題（Charter）、時間盒（Time Box）、可評審的結果（Reviewable Results）和簡報（Debriefing）[Bach2004]。
主題（Charter）是一個測程需要完成的任務。該任務應該是清晰且具體的，可以在90分鍾的時間內完成，並提供有價值的簡報。主題通常用一段簡練的文字描述，其內容可以是測試一個功能、檢查一個風險、測試一組用戶情景（User Scenario）等。以下是兩個實例[Michael2007]：
- Create a test coverage outline and risk list for DecideRight. （為產品DecideRight生成測試覆蓋大綱和風險列表）
- Explore a decision created with QuickBuild – the wizard that guides the user through the options, criteria, and weights needed to calculate the best decision. （探索QuickBuild如何產生一個決策——用戶向導應該引導用戶使用選項、標准和權重來計算最佳決策）
時間盒（Time Box）是一段不受打擾的測試時間，其長度一般在60~120分鍾，以90分鍾較為常見。在此期間，測試人員不回答問題、不回復郵件、不應答即時消息，只專注地實施測試。從工程師的角度，時間盒使測試人員能排除干擾，全力應對測試的智力挑戰。從測試團隊的角度，固定且專屬的時間盒使得測試規划和進度追蹤變得更容易。
可評審的結果（Reviewable Results）是測程的產出，常見的形式是測程表（Session Sheet），其內容可以包括：
- 主題（Charter）
- 測試人員
- 測試所覆蓋的區域
- 測試設計和測試發現
- 測試所發現的缺陷（Bugs）
- 測試所發現的問題（Issues）
- 測試所使用的數據文件
- 測試活動的時間統計：在產品安裝、測試設計與執行、缺陷調查與報告、非測試活動中各花費了多少時間。
簡報（Debriefing）通過面對面的交流將測試情況傳遞給測試領導。在一天的測程結束后，測試人員向測試領導當面匯報測試情況。領導查看測程表，提出一些問題，測試人員解釋測試結果，並回答疑問。測試領導也可以召開小組會議，讓測試人員輪流報告當天的測試結果，使測試團隊對當前產品的質量形成較完整的認識。
測程表（Session Sheet）
傳統上，測程表是一個文本文件，擁有固定的格式。這樣，測試領導可以用一個文本處理程序從多個測程表中提取信息，形成聚合的測試報告。測試人員也可以用程序讀取測程表，將其中的缺陷記錄自動提交到缺陷管理系統。Michael Bolton曾經分享過兩個測程表的實例[Bolton2007]，本文摘錄一個實例如下。
該實例反映了測程表的幾個特點：
- 測程表記錄了一些任務分解（Task Breakdown）數據，如在測試設計和執行（Test Design and Execution）、缺陷調查和匯報（Bug Investigation and Reporting）、測程建立（Session Setup）等活動上花費的時間。這些數據配合簡報有助於測試領導估算測試速度、評估測試效率。
- 測程表擁有固定的格式，該實例用特殊符號“#”標記了文本處理程序可以提取的數據。測試人員只要遵循簡單的格式，就可以產生易於自動分析的測程表。一個簡單的文本處理程序（或腳本）能夠批量地處理測程表，產生測試報告和圖表，並完成自動化任務（如提交缺陷記錄到缺陷管理系統）。
- 測程表列舉了測試所使用的數據文件（Data Files），為測試數據復用提供了基礎。
- 測程表的核心是測試筆記（Test Notes），它簡略地敘述了測試故事（Testing Story）：為什么測試，如何測試，為什么認為我們的測試是足夠好的。
- 測程表記錄了缺陷（Bugs）和問題（Issues），它們不但是測程的直接產出，還是規划未來測試的參考資料。
近年來，出現了更多的SBTM支持工具[Carvalho2011]，能夠支持更富表現力的測程表。例如，RapidReporter可以方便的生成CSV和HTML格式的測程表，CSV格式便於進一步地自動處理，HTML格式則支持較復雜的排版和屏幕截圖。
聚合測程表收集的數據，測試領導可以評估團隊的測試速度。下圖顯示了已執行測程的總時間隨日期的變化趨勢，這有助於測試領導評估在項目結束前還可以執行多少測程[Jonathon2004]。如果余下的測試時間不足以完成測試使命，他需要采取措施，以避免項目失敗。
SBTM是動態管理
在項目之初，測試團隊對產品還不夠了解，測試領導可以安排一些“偵查型”的測程去學習產品的各個區域。例如，上文提到的“為產品DecideRight生成測試覆蓋大綱和風險列表”就偵查了產品的主要功能和風險。基於這些測程的測程表和簡報，測試領導可以擬定測試項目的總體計划，並大致規划出測程的數目與主題。
在項目過程中，好的測試領導會通過測程表和每日簡報，積極發現產品或測試的問題，實施有針對性的解決方案。例如，測試領導老王通過閱讀測程表，發現測試人員小張常常花費過多的時間在缺陷調查上，他會與小張交談以了解情況。面對面的交流使信息得到高效地傳遞，並有助於消除統計數據的誤導和書面文字的歧義。如果小張是喜歡打破沙鍋、追根究底，老王會告訴他：在調查缺陷時，可以設定一個最長用時（如15分鍾），當時間用盡，應該停止調查，根據已知情況提交缺陷報告。此外，他還會安排一些有技術挑戰的任務給小張，以幫助他的技術成長。如果小張是不了解產品而花費了過多的調查時間，老王會安排有經驗的員工指導小張，或親自傳授一些知識和技能，以幫助他渡過難關。如果是糟糕的可測試性導致了過長的調查時間，老王會和開發團隊聯系，提出改進意見，以推動產品可測性的提高。
隨着產品和項目環境的變化，測試內容與策略也要做相應的調整。測試領導會根據測程的結果來調整下一步的測試計划。他可以新增幾個測程，以調查最新發現的風險；他也可以合並幾個測程，將省下的時間分配給更重要的測程。一切調整的目標都是為了優化測試的價值。
由以上論述不難看出，SBTM與敏捷開發宣言[Agile01]是高度一致的。在原則上，他們都認同：
- 個體和互動高於流程和工具
- 響應變化高於遵循計划
在實踐上，他們都認可：
- 圍繞被激勵起來的個人來構建項目。提供他們所需的環境和支持，並且信任他們能夠完成工作。
- 在團隊內部，最有效率與效果的傳遞信息的方法，就是面對面的交流。
可見，SBTM和敏捷開發雖然來自於不同的專家、實踐和社區，但是他們擁有相似的核心，其思想和方法可以相互借鑒與補充。
SBTM是管理框架
測試專家Paul Carvalho指出SBTM一個管理框架（Management Framework），其基本元素是：設定清晰的主題、固定長度且不受打擾的工作時間、產生可檢查的結果、利用評審和簡報來驅動未來的Session [Carvalho2010]。該框架的合理名詞也許不是Session-Based Test Management，而是Session-Based Task Management。個人或團隊可以用它管理各種類型的（創造性）活動，如編程、寫作、鍛煉身體、整理房間等。
從這個角度，SBTM與SMART 原則（Specific, Measurable, Achievable, Relevant, Time-boxed）和番茄工作法有異曲同工之妙。
- Specific（具體的）：一個測程需要一個具體的主題，一個番茄鍾需要一個具體的目標。
- Measurable（可度量的）：測程產出測程表以反映測試進展。番茄鍾關注當前任務是否完成，並收集過程指標。
- Achievable（可實現的）：對於測程和番茄鍾，主題和目標應該是可實現的。這潛在地要求將一個大目標分解為多個小目標，且每個小目標也是具體的、可度量的、可實現的。而且，追蹤小目標的完成情況提供了整體進度的可度量性。
- Relevant（相關的）：測程要為測試項目服務，要切合當前情況，並優化產品價值。番茄鍾要針對最重要的任務，以實現自我承諾。
- Time-box（有時間限制的）：測程和番茄鍾都提供了一個固定的時間段以一心一意的工作。
參考文獻
- [Agile01] The Agile Manifesto. Manifesto for Agile Software Development. http://www.agilemanifesto.org/, 2001.
- [Bach2000] Jonathan Bach. Session Based Test Management. http://www.satisfice.com/articles/sbtm.pdf, 2000.
- [Bach2004] Jonathan Bach. Testing in Session - How to measure exploratory testing. http://www.sasqag.org/pastmeetings/ExploratoryTesting_SessionBasedTestManagement.pdf, 2004.
- [Bolton2006] Michael Bolton. Two Future of Software Testing. http://www.developsense.com/presentations/e2008twofutures.pdf, 2006.
- [Bolton2007] Michael Bolton. An Exploratory Tester’s Notebook. http://www.evelopsense.com/presentations/etnotebook.pdf, 2007.
- [Carvalho2010] Paul Carvalho. SBTM is not ET. http://swtester.blogspot.com/2010/2/sbtm-et.html, 2010.
- [Carvalho2011] Paul Carvalho, Lessons Learned in Session-Based Exploratory Testing. http://staqs.com/docs/sbtm/, 2011.
注：如果您想快速理解SBTM創建者的觀點請參考[Bach2004]。如果您想獲得SBTM的實踐經驗請參考[Carvalho2011] 。