為什麼需要了解情境導向測試
在執行探索性測試 (Exploratory Testing) 之前，了解情境導向測試 (Context-Driven Testing, 簡稱 CDT) 的核心思維是非常重要的。這是因為探索性測試並非盲目地隨意點擊軟體，而是一種高度依賴測試者判斷力的技術，而 CDT 正是賦予這種判斷力方向與深度的「大腦」。
以下是為什麼在進行探索性測試前必須先具備 CDT 思維的幾個關鍵原因：
(1) 兩者起源與本質的密切關聯
探索性測試本身就是由情境導向測試社群大力推廣的核心概念之一。探索性測試可以被視為情境導向測試方法中的一部分，但兩者並不完全等同：
(2) 提供探索的「方向」與「優先順序」
探索性測試沒有固定的腳本，這意味著測試人員擁有極大的自由度。然而，沒有情境引導的自由很容易變成毫無效率的亂測。
CDT 強調「任何實務的價值都取決於其情境」。測試人員會先評估專案的獨特情境：我們有多少時間？團隊技能如何？專案目前的需求是否不斷在變化？
了解情境後，測試人員才能決定探索的焦點在哪裡（例如：時間緊迫時，集中探索最高風險的金流功能；或者在需求頻繁變更時，維持彈性的手動探索性測試）。
(3) 幫助發掘「未寫入規格」的隱藏風險與期望
規格書往往是不完整的，不可能涵蓋所有真實世界發生的狀況。例如，規格書絕不會特別註明「這個軟體不應該讓使用者的電腦融化或房子爆炸」，但這絕對是使用者心照不宣的期望 (Desired)。
擁有 CDT 思維的測試人員，在進行探索性測試時，不會只侷限於驗證軟體是否符合規格 (Described)，而是會去探索那些規格沒寫、但使用者高度期望且可能發生衝突的灰色地帶。
(4) 賦予測試人員「意義建構 (Sense-making)」的能力
探索性測試的核心在於人類的「實驗 (Experimentation)」，它與單純依賴機器的「檢查 (Checking)」不同。
了解 CDT 可以幫助測試人員建立「強迫性的經驗主義者 (Compulsive empiricist)」的心態——永遠不要盲目相信表面事物或開發者的假設，必須親自去驗證。
機器無法理解商業邏輯與真實世界的脈絡，但人類具備獨特的「意義建構 (Sense-making)」能力。在探索的過程中，測試人員必須運用這種能力，不斷觀察軟體行為、提出假設、設計實驗並立刻驗證，這正是 CDT 賦予探索性測試的靈魂。
簡單來說，情境導向測試 (CDT) 是「戰略 (Why & When)」，而探索性測試是「戰術 (How)」。如果不了解 CDT，測試人員可能會在不適合的時機濫用探索性測試，或者把探索性測試做成毫無章法的隨意測試；而有了 CDT 思維作為基礎，測試人員就能靈活運用領域知識與創造力，針對當下專案最關鍵的風險，進行一場精準且高價值的探索性測試。
什麼是情境導向測試
在軟體開發與測試的世界裡，我們經常聽到所謂的「最佳實務」、「標準流程」或是「黃金準則」。彷彿只要買了最昂貴的測試工具、導入了最流行的自動化框架，專案就能一帆風順。然而，現實世界往往狠狠打臉這些完美計畫。
為什麼照著教科書做，軟體還是漏洞百出？為什麼在 A 公司大獲成功的測試方法，到了 B 公司卻是一場災難？
這就是為什麼我們需要探討情境導向測試 (Context-Driven Testing，簡稱 CDT)。這不是一套死板的規則，而是一種靈活、務實且充滿智慧的測試哲學。
那什麼是「情境導向測試」？簡單來說，情境導向測試的核心概念就是：「隨著問題的改變，將你的解決方案與問題進行匹配」。
傳統的軟體測試方法，往往依賴預先設定好的固定流程。他們認為世界上存在一種「放諸四海皆準」的測試方法論，只要把所有的步驟寫成詳細的測試腳本，任何人照著跑就能抓出所有的 Bug。
但情境導向測試社群（由 Cem Kaner 於 1999 年提出此名詞，並與 James Bach、Brian Marick、Bret Pettichord 等人共同推廣）認為，這種想法大錯特錯。他們主張，沒有所謂一體適用的最佳實務，所有的測試策略都必須根據當下的「情境 (Context)」來量身打造。
(1) 什麼是「情境 (Context)」？
「情境」包含了影響專案成功或失敗的每一個元素。它就像是我們對真實世界的模型與實際發生的現實之間的關係。
一個專案的情境包含了：
更重要的是，情境是會隨著時間改變的。可能明天突然有一半的團隊成員離職，或者客戶突然大幅更改了需求。當你身處於這個專案中，你的存在與行為本身也會改變這個情境。因此，情境導向測試要求測試人員必須具備高度的適應力，不斷觀察環境並調整策略。
(2) 面對情境的四種態度
為了讓非測試人員也能輕鬆理解，測試專家 James Bach 用非常生動的比喻，將人們面對「工作情境」時的態度分成了四種類型。看看你是屬於哪一種：
A. 情境漠視者 (Context-Oblivious)
這類人完全沒有意識到自己的工作方式與環境之間有什麼關聯。他們只是「照著前輩的規定做」或是「盲目跟隨慣例」，如果你問他為什麼要這樣測試，他會回答：「因為一直以來都是這樣做的。」 他們就像是工廠生產線上的機器人，不需要知道原因，只需執行命令。
B. 特定情境者 (Context-Specific)
這類人適應了某一個特定的環境，並且在那個環境中表現得非常出色。他們知道自己面臨什麼問題並能解決它，但前提是「環境不能改變」。
就像一個普通的駕駛員，知道如何在天氣晴朗的平穩道路上開車。但如果把他們丟到 Daytona 500 賽車場上，他們原有的駕駛技能就完全派不上用場了。 在軟體業，如果你只會測試某種特定的舊系統，當公司突然導入新技術或需求大改時，這類人就會不知所措。
C. 情境霸權者 (Context-Imperial)
這是我常說的「拿著鐵鎚找釘子」的人。他們堅持一套固定的解決方案，並試圖強迫周遭的環境來適應這套方案。如果方案行不通，他們會怪罪環境、怪罪團隊，卻從不檢討自己的方法。
有些測試顧問會堅持公司必須導入某個「最佳實務」，如果失敗了，他們就會推託是因為「沒有高層管理者的支持」或是「工程師缺乏紀律」。也有狂熱的敏捷開發推廣者會堅持：「所有的測試都必須 100% 自動化，否則就不是敏捷開發！」。這就像醫生連病人都還沒看過，就直接開立處方藥一樣荒謬。
D. 情境導向者 (Context-Driven)
這就是本文的主角。情境導向的實踐者認為，世界上「沒有絕對的最佳實務，只有在特定情境下的良好實務」。他們會學習各種不同的工具與技巧，然後在遇到實際情況時，將這些做法拆解、重組，以適應當下不斷變化的世界。他們不會死守規矩，而是專注於「解決真實發生的問題」。
情境導向測試的七大核心原則
情境導向測試的創始人們制定了七項基本原則，這些原則不僅適用於軟體測試，對於任何專案管理都極具啟發性。
(1) 任何實務的價值，取決於其情境 (The value of any practice depends on its context)
每一個企業、專案和軟體都是獨一無二的。即使你過去擁有豐富的手機 App 測試經驗，面對一個全新的 App 專案時，你仍必須將其視為一個具備獨特特質的新挑戰，因為過去的解法不一定適用於現在。
(2) 只有在情境下的「良好實務」，沒有所謂的「最佳實務」 (There are good practices in context, but there are no best practices)
這是情境導向測試社群最堅持的觀念。盲目相信並套用「最佳實務」，就像是矇著眼睛、吞了十幾顆安眠藥去開賽車一樣危險。 很多高階主管會在打高爾夫球時，聽信其他人的吹捧，花大錢購買昂貴的測試工具（例如 HP Quality Center），只因為它是業界宣稱的「最佳實務」。但買來後往往發現根本不符合團隊需求，最後只能硬著頭皮用，這就是掉入了最佳實務的陷阱。
(3) 專案會隨著時間以無法預測的方式發展 (Projects unfold over time in ways that are often not predictable)
軟體開發的過程是動態的，充滿未知。我們不能像傳統製造業或蓋房子那樣，制定一個死板的「五年計畫」，因為軟體開發中有太多的未知數，人類連自己五天後會遇到什麼 Bug 都不知道。因此，測試的策略必須保有彈性，能夠適應並處理環境中不可預測的變動。
(4) 良好的軟體測試是一個充滿挑戰的智力過程 (Good software testing is a challenging and intellectual process)
測試絕對不是只要會照著說明書點擊滑鼠就能做好的低階工作。它需要極高的分析思維、理性思考與創造力。優秀的測試人員必須是一個「強迫性的經驗主義者 (Compulsive empiricist)」，永遠不要盲目相信事物表面的樣子，必須親自去驗證。如果有人認為某個工程師能力太差寫不好程式，就把他調去當測試員，這簡直是不可理喻的錯誤觀念。
(5) 必須透過合作的判斷與技能，才能在對的時間做對的事 (Cooperative judgment and skills)
好的測試不是靠死板的腳本，而是靠個人的技能與判斷力。整個團隊必須一起合作，運用各自的專業來做決策。
(6) 一起工作的人是任何專案情境中最重要的部分 (People working together are crucial)
軟體開發是一個「人類與技術交織的系統」。團隊成員的合作關係深刻影響著專案成敗。如果你討厭某個同事，或是測試團隊與開發團隊水火不容（例如測試中心被隔離在另一棟建築物裡），導入再好的工具也沒有用。測試員與開發者應該像是一家人，互相合作。
(7) 產品是一種解決方案。如果問題沒解決，產品就等於無效 (The product is a solution)
產品的價值在於它是否解決了使用者的痛點。測試人員的責任不僅僅是比對「軟體是否符合規格書」，更要發掘那些沒有寫在規格書裡的隱藏風險。
從來沒有一份軟體規格書會寫上「這個軟體不應該讓使用者的房子爆炸」或是「不應該讓電腦融化」。這是使用者心照不宣的期望 (Desired)。如果一個軟體導致系統崩潰，而測試人員卻因為「規格書沒寫」就認為這不是 Bug，這就是一種僵化的殭屍思維。
真實世界中的情境導向測試
為了讓大家也能深刻體會，我們透過幾個生動的案例來比較「死板測試」與「情境導向測試」的差異。
案例一：外觀相同的金屬方塊（不要相信你的眼睛）
這是測試專家 Ilari Henrik Aegerter 提出的一個精彩實驗。 想像桌上放著兩個大小完全相同、外觀都是銀色金屬光澤的方塊。
如果你只憑視覺，甚至拿尺去量（都是一立方英吋），你會以為它們是完全一樣的東西。 如果你是個照本宣科的測試員，你會在報告上打勾：「外觀符合規格、尺寸符合規格，測試通過。」
但如果你是一個具備「情境思維」的測試員（強迫性經驗主義者），你會提出假設並親自做實驗。當你實際把兩個方塊拿起來時，你會驚訝地發現，其中一個比另一個重了將近 11 倍！ 原來，一個是極輕的鎂 (Magnesium)，另一個是極重的鎢 (Tungsten)。
永遠不要只看表面或盲信開發者給的規格書。身為測試人員，你必須懷疑一切，因為「測試員就是那些知道事情可能會有所不同的人」。
案例二：Windows 自動更新該開還是關？
這是面對「不同情境，必須給出截然不同做法」的經典例子。
情境 A：測試安裝程式 (Install Testing)
如果你正在測試一個 Windows 軟體的「安裝過程」，你必須精確知道安裝前後，系統裡的系統檔案 (DLL) 有什麼變化。在這種情境下，關閉 Windows 自動更新是正確的做法，因為你不希望系統偷偷下載更新干擾了你的觀察環境，你需要一個受控的「乾淨」狀態。
情境 B：測試一個上線的網站 (Website Testing)
如果你今天測試的是一個要給成千上萬人使用的網站，使用者的真實環境是千變萬化的。如果你為了保持測試環境「乾淨」而關閉自動更新，這就無法模擬真實世界了。在這種情境下，你反而應該知道網站在 Windows 更新前後，功能是否會受到衝擊。
同樣是「是否關閉自動更新」這個問題，在不同的情境下，答案完全相反。這就是情境導向測試的核心精髓。
案例三：手機銀行 App 的測試策略
假設你的團隊要測試一個行動銀行 App，它需要在多種設備上運行。
傳統測試做法：遵循預先寫好的龐大測試計畫，要求所有的按鈕、每個頁面都要受到同等程度的測試，且必須等工程師全部寫完程式才能開始測。
情境導向做法：首先評估當下的限制與目標。
如果時間緊迫時，立刻放棄測試那些不常使用的設定介面，將全部火力集中在最致命的功能，例如「登入認證」和「金流交易」。
會根據團隊技能分配工作，資深測試人員去處理複雜的安全漏洞測試，資淺人員則負責介面好不好用的易用性測試。
不做一體適用的計畫，而是根據時間、風險與人員技能，動態調配測試資源。
案例四：T 恤上有幾個洞？（跳脫框架的思考）
想像一張圖片上有一件 T 恤，T 恤的正中間破了兩個大洞。請問這件 T 恤上總共有幾個洞？ 一般人直覺會回答「2 個」。 但一個優秀的測試員會開始分析各種情境：
軟體系統中所謂的「正常」與「異常」，往往取決於你如何定義問題。人類大腦擅長這種「意義建構 (Sense-making)」，這是單純寫腳本的機器無法取代的價值。
如何把「情境導向」落實在日常工作中？
即使你不是專職的測試人員，身為專案經理、設計師或行銷人員，你也可以運用這些原則來提升工作品質。
(1) 勇敢且大量地提問
在開始任何工作前，先從不同角度提出問題以釐清情境。
• 我們真正的目標是什麼？這個產品的受眾是誰？
• 需求是明確的，還是會不斷變動的？
• 我們有多少時間？我們的團隊擁有什麼技能？ 不要盲目開工，先掌握全局。
(2) 把決策視為「實驗」並給予時間沉澱
情境是動態的，我們必須不斷嘗試新的做法來適應。例如，如果你覺得某個每週測試報告根本沒人看，你想做個實驗停止發送。請注意，不要因為停發的第二天沒人抱怨，就認定實驗成功。因為使用者閱讀報告的節奏可能是一週後、甚至一個月後。你必須讓實驗「沉澱」一段時間，才能真正了解環境的運作規律。
(3) 避免意識形態，保持獨立思考
如果你對某件事的看法總是可以被預測（例如：你永遠說自動化比手動好，或是敏捷比瀑布流好），那你可能已經陷入了某種意識形態的陷阱。 情境導向者會利用像 ChatGPT 這樣的工具進行反向思考。ChatGPT 給的通常是「大眾的平均觀點」。如果你看著大眾答案頻頻點頭，你就只是在順從常規。你應該問自己：「在什麼樣的情境下，這個標準答案是不適用的？」 透過這種刻意練習，可以鍛鍊我們分析真實情境的能力。
(4) 觀察專屬的「錯誤模式 (Error Patterns)」
每個團隊犯錯的習慣都有其獨特性。一個有情境思維的人，會觀察並歸納出屬於該專案的特定錯誤模式。例如：你發現工程師在處理某個系統介接時，總是習慣不寫錯誤處理代碼，直接讓系統崩潰。當你抓到了這個「團隊習慣性的壞品味」後，你就可以將這個模式推廣到其他所有的功能測試中，快速找出類似的潛在問題。這就是針對當下情境找出的最高效策略。
情境導向測試 (Context-Driven Testing) 帶給我們最大的啟發，就是「停止背誦別人告訴你的解決方案，然後在不了解問題的情況下盲目套用」。
無論是軟體開發、專案管理還是日常營運，我們都面臨著無數不可預測的變數。那些宣稱擁有「完美最佳實務」的權威，往往只是在推銷一套不合時宜的枷鎖。
真正的專業，是擁有豐富的技能儲備，並具備強大的觀察力與適應力。下一次，當你面臨一個棘手的專案，或是有人試圖強迫你導入某種「黃金標準」時，請先停下來，深吸一口氣，然後問一句：「在我們現在這個特定的情境下，怎樣做才是最合理的？」當你開始問這個問題時，你就已經踏入了情境導向測試的智慧殿堂。
iThome鐵人賽
看影片追技術