本節用對話的形式討論探索式測試的概念與實踐。提問者是本書的一位虛擬讀者，回答者是本書的作者們。
問：探索式測試中的“探索”該如何理解？
答：所謂探索是指有目的的漫游，即帶著使命在某個空間中漫游，但沒有預先確定的路線。探索包括對產品與技術的深入研究和基于研究成果的實踐應用。
問：如何實施探索式測試？
答：本書第3部分將專門討論該問題。這里先介紹一種可行的探索式測試實施方法，其靈感來源是基于測程的測試管理（Session-Based Test Management）。
探索式測試鼓勵測試人員依據當前語境選擇合適的測試流程與技術。在測試過程中，SMART原則 為測試者提供了很好的指導。
Specific（具體的）：測試需要一個具體的目標。
Measurable（可度量的）：有明確的指標可以評估目標是否達成。
Achievable（可實現的）：目標應該是可實現的。這潛在地要求將一個大目標分解為多個小目標，且每個小目標也是具體的、可度量的、可實現的。而且，追蹤小目標的完成情況提供了整體進度的可度量性。
Relevant（相關的）：目標要切合當前語境，符合團隊利益，且不忘企業愿景。
Time-boxed（有時間限制的）：為每個目標設定一個合理的最后期限。這可以幫助測試人員在固定的時間窗口（Time Window）中排除不相關干擾，專注地工作。
依據SMART原則，測試人員可按如下描述展開探索式測試。
（1）測試人員制訂測試計劃。分析被測試應用，確立若干個具體的測試使命（Mission），每個使命針對一個可能的產品風險。
（2）測試人員將測試使命分解為一系列測試任務（Charter），每個任務都有明確的退出條件和時間限制。
（3）在短暫的測試計劃之后，測試人員根據優先級選擇一個任務，在一個固定的時間窗口中執行探索式測試（窗口的長度是60~120分鐘，以90分鐘為宜）。這樣一個時間窗口被稱為一個測程（Session）。在該測程中，測試人員設計測試、執行測試、評估測試結果。他會根據獲得的知識和發現的疑問再設計測試用例，以拓展測試的廣度和深度。
（4）在測程結束后，測試人員適當休息，放松思維。
（5）隨后，他會反思當前的測試進展，并優化測試計劃。也許他會為當前任務追加一個測程；也許他會再增加一個新的任務以彌補先前測試計劃的不足；也許他會刪除一些任務以反映他對測試對象的最新認知。
（6）這時，他會更有自信地開始新一輪探索式測試。
以上只是一種可能的探索式測試實施方法。負責任的測試人員一定會選擇他自己的方式展開測試，因為只有作為領域專家的他，才能做出最符合語境的決策。此外，集合整個團隊的力量，進行同行評審、頭腦風暴、結對測試等活動，有助于產生更好的測試結果。
問：探索式測試與即興測試（Ad-hoc Testing）有何區別？
答：探索式測試與即興測試都強調“即興發揮”，即利用直覺和經驗，快速地測試軟件，并不停地調整測試策略。軟件專家Andrew Hunt指出，直覺是非顯性知識的代名詞，是大腦富（Rich）模式的杰出能力。如果人類只使用大腦的線性模式（包括語言可表達的顯性知識、抽象能力、邏輯能力等），而漠視富模式的能量，我們將浪費自身的巨大潛力。
然而人是不完美的，某些直覺可能是認知偏見或錯誤。這就引出了探索式測試與即興測試的關鍵不同：探索式測試是帶著“反思”的測試。在探索式測試中，測試人員不斷地提出假設，用測試去檢驗假設，并分析測試結果來證實或推翻假設。在此過程中，測試人員持續完善頭腦中的產品模型和測試模型，然后利用模型、技能、經驗去驅動進一步的測試。通過將測試學習、設計、執行和結果分析作為相互支持的活動并行展開，探索式測試總是在不停地優化測試模型、測試設計和測試價值。因為測試設計和測試執行的切換速度很快，許多人誤以為探索式測試沒有計劃和設計。實際上，這些活動被劃分到細微的時間片中，被反復執行。
即興測試往往利用錯誤猜測、典型風險和常見攻擊來快速地試探軟件，可以在短時間內發現許多軟件錯誤。但是即興測試不強調測試的系統性和完整性，測試遺漏的風險很高，也難以發現一些需要深入研究才能發現缺陷。探索性測試通過測試來透徹地理解被測試產品，從而拓展測試的廣度與深度，以持續優化測試的價值。
問：如果探索式測試是硬幣的正面，那么硬幣的反面是什么？
答：探索式測試的對立面是腳本測試（Scripted Testing）。腳本測試要求預先編寫好測試腳本（Script），腳本規定了如何配置被測試軟件、如何輸入、如何判斷軟件輸出了正確的結果。編寫詳細的腳本往往需要大量的測試資源。
如果運用得當，腳本測試可能有如下收益：
測試人員可以仔細地思考被測試軟件。
測試腳本可以被項目關系人（Stakeholder）評審。
測試腳本可以被復用。
測試團隊可以評估測試腳本集的完備性。
測試團隊可以度量測試腳本的執行情況，以評估測試進度。
問：本書為什么反對腳本測試？
答：筆者不反對任何測試思想或方法，但是反對不分語境地濫用某一種測試思想或方法。例如，苛刻地要求編寫詳細的測試腳本可能會導致如下測試風險。
在測試執行前，大量的測試資源被用于測試設計。但是，產品的發展往往難以預料，早期的預先設計不能有效地處理動態變化的情況。有可能花費了大量的時間，卻獲得了一批充滿缺點的測試腳本。
過于詳細的測試腳本壓抑了測試執行的靈活性，使得測試執行變成單調的過程。這可能導致測試人員對一些明顯的錯誤視而不見，因為它們不在測試腳本的檢查范圍之內。此外，運行測試是觀察軟件行為、獲得測試靈感、設計新測試用例的極佳時刻，這要求測試人員在測試執行時全神貫注、頭腦靈活、反應敏捷。但是，枯燥的測試執行將使這些目標難以實現。
大量的詳細測試腳本導致了沉重的維護代價。在進度壓力下，測試人員可能沒有時間更新測試腳本，這使得測試腳本不能隨需求和產品一同演化。隨著時間的推移，大量的測試腳本成為過時的、無人問津的“擺設”，原先投入大量資源所獲得的測試資產幾乎消耗殆盡。
要求測試人員編寫求全責備的測試腳本，很可能帶來不良的心理暗示：測試人員在不知不覺中將編寫腳本看做測試的目的，而不是輔助測試的工具。他們會盲目追求腳本的數量，而很少關注產品和項目的風險，用看似“完備”的腳本集提供虛假的安全感。更糟糕的是，醉心于腳本數量的測試領導很可能會鼓勵這種以“文案工作”為核心的測試流程，使測試的價值進一步流失。
相比“硬幣”的比喻，筆者更喜歡Cem Kaner的觀點：“純粹的探索式測試和純粹的腳本測試好似區間的兩個端點。在實踐中，大多數測試者位于這兩者之間。然而，大多數好的測試非常接近探索式測試的一端。”
此外，根據語境驅動測試的基本原則，測試人員需要經常反思：根據當前語境，測試策略是應該偏向探索式測試，還是腳本測試？如何綜合它們的優勢，以獲得更好的測試結果？
問：探索式測試編寫測試文檔嗎？
答：探索式測試者創建任何有助于實現其目標的文檔，他會撰寫并維護符合語境的測試文檔。這里提出一種可能的測試計劃編寫方法，供讀者參考。
在不同的開發組織，測試計劃有不同的名稱：測試計劃、測試規格說明和測試設計文檔等。但是，大多數測試計劃會涵蓋產品概述、測試范圍、測試風險、測試策略、部分詳細測試用例、資源分配和日程安排。
與腳本測試在測試執行前編寫大量文檔不同，探索式測試在整個測試過程中持續編寫、修改、優化測試計劃。測試計劃的內容、格式、詳略是由項目語境決定的。
在項目計劃階段，測試計劃可以包含產品概述、測試范圍、測試風險、測試策略、資源分配和進度安排。編寫文檔的目的是建立對產品的整體認知，根據風險提出相應的測試策略，并安排測試任務和日程。測試計劃不必面面俱到，用精簡的格式記錄必要的內容即可。此時項目的不確定性較大，未知因素較多，很可能不適合做出詳細的測試決策。
在項目計劃階段，應該邀請項目關系人對測試計劃進行評審。評審的形式可以多種多樣，會議評審、桌面走查、郵件評審、在線文檔批注、頭腦風暴皆可。評審的目的是發現“大圖景”上的缺陷，并豐富測試策略。眼界開闊的項目經理、負責任的開發人員、經驗豐富的測試同事能夠提供很好的建議。
在測試階段，測試人員需要根據測試進展持續更新測試計劃，內容可能包括產品模型、檢查列表、測試策略、覆蓋大綱和風險列表等。測試計劃應該是“活”的文檔，能夠反映測試人員對產品和項目的最新認識。對測試范圍、測試風險、測試策略和進度安排的重大變化應該寫入測試計劃，重要的測試用例（如發現嚴重缺陷的測試用例）也應該及時融入測試策略。測試計劃應該盡可能地精簡，這有助于文檔的持續更新，而冗長的文檔將不利于閱讀、增刪和修訂。
當測試人員認為測試計劃相對完整之后，他還應該邀請項目關系人對測試計劃進行評審。評審的目的是發現測試遺漏，補充測試策略，提高測試覆蓋率。
以上方法有三個重要的特點。
測試計劃的編寫與改進貫穿整個測試過程。在測試執行之前，對測試計劃不必求全責備。在測試執行中，測試人員根據測試反饋，動態地調整測試范圍、項目風險和測試策略，生成新的測試用例，并對測試計劃做必要的更新。
測試人員持續地收集對測試計劃的意見，并將改進意見納入測試實踐。正式和非正式的測試計劃評審可以識別潛在風險，豐富測試策略。在一些測試流程中，測試計劃評審只發生在測試開始之前。但是，筆者建議在測試流程的中期再次評審測試計劃，目的是進一步豐富測試策略的多樣性，并發掘可能的測試遺漏。這時，測試團隊對產品與風險擁有更深刻的理解，能夠提出更具針對性和多樣性的測試策略，也可以幫助測試人員發現測試盲點，從而提高測試覆蓋率。
測試計劃側重測試規劃（一組指導測試過程的想法）和測試策略（一組指導測試設計的想法）[Kaner01]，而不是腳本化（Scripted）的測試用例，即測試計劃用精簡的格式表達測試人員的測試想法，而不必詳細記錄測試用例的設置、步驟和預期結果。測試人員可以用文字、列表、表格、思維導圖等任何合適的方式表達想法，目的是激發測試靈感，并促進測試思想的交流。此外，他會利用發現缺陷的測試用例來完善測試策略，而不是讓過去的測試用例控制未來的測試。
關于其他形式和內容的測試文檔，測試專家Michael Bolton的文章What Exploratory Testing Is Not：Undocumented Testing提出了很好的建議。
問：探索式測試的核心優勢是什么？
答：探索式測試的核心優勢是有助于“學習”。此處的學習是指學（獲取知識）與習（應用知識）的持續過程。
對于測試人員，軟件測試是一個持續學習并實踐的過程。他的學習范圍如下。
行業知識：為什么需要這個軟件？軟件如何幫助使用它的人和團體去獲得成功？
用戶角色：目標用戶是誰？他們有什么特點，有什么期望？軟件如何幫助他們去獲得個人成就？
軟件產品：產品是一種解決方案，它解決了行業和用戶所面臨的問題嗎？
計算平臺：只有深刻理解軟件所依賴的計算平臺（如操作系統、中間件和網絡協議等），才能更好地進行測試。
開發技能：理解項目所使用的具體技術，知曉典型的技術缺陷，具備測試開發的能力。
測試技術：針對當前項目，選擇合適的測試技術，并能夠熟練地應用。
程序缺陷：研究已知的軟件缺陷，提煉錯誤模式，制訂緩解或預防方案。
開發團隊：語境決定策略和實踐。在一起工作的人，是所有項目語境中最重要的組成部分。
測試人員不需要在項目之初就掌握所有知識，他可以通過每天的工作去逐步理解用戶、項目、技術和團隊。更重要的是，他需要在每天的工作中實踐所學的內容：規劃測試方案、創建并執行測試用例、分析測試結果和編寫測試報告。實踐是練習，是“學”的自然延伸。知行合一才構成“學習”的完整內核。
學習的一個重要成果是成為更優秀的測試人員。他們可以根據項目語境，選擇合適的流程、技術和工具來高效地測試，以推動軟件質量的提高。