在軟體開發的世界裡，許多團隊以為導入 BDD（Behavior Driven Development）就是學會寫 Gherkin 腳本、把測試自動化，卻忽略了真正的精髓——它其實是一套讓團隊「用對話建立共識」的思維框架。

這套框架是在 Liz Keogh 及倫敦 BDD 社群中，逐步被命名與流傳的。她於 2004 年起開始撰寫與講述 BDD 主題，並在 2011 年的文章中對 BDD 發展歷程提出一些反思，主要是澄清一些概念與實踐方式。

[1] ATDD vs. BDD, and a potted history of some related stuff
https://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/?utm_source=chatgpt.com
[2] What is behaviour driven development?
https://www.hindsightsoftware.com/about-bdd?utm_source=chatgpt.com

後續 Gáspár Nagy 和 Seb Rose 所撰寫的《The BDD Books》系列，就是以這三階段結構為基礎—其中第一本即為專門講述 Discovery 的入門書，接續有 Formulation 為主題的專書。

[3] Discovery (Explore Behaviour Using Examples): BDD Books, Book 1, Seb Rose and Gaspar Nagy, Apr 26, 2019
[4] Formulation: Document examples with Given/When/Then (BDD Books Book 2), Seb Rose and Gaspar Nagy, Apr 26, 2021

個人覺得這個框架的觀念很棒，不管你是使用 SBE、BDD、或是ATDD都可以使用，因此特別
跟大家介紹。

階段一：探索 (Discovery) – 建立共同理解

探索是 BDD 流程的起點，也是決定「應該建立什麼」最為關鍵和困難的部分 。**若此階段未能充分建立共同理解，後續的表述與自動化將缺乏堅實的基礎。 **

(1) 定義與目的：共同探索「應建構什麼」
探索階段的核心是透過結構化的對話，讓團隊成員就即將開發的功能（通常是一個使用者故事）的具體範例進行深入討論，以探索、發現並就預期完成的細節達成一致。

其主要目的在於增進團隊對使用者需求、系統運作規則以及所需工作範圍的共同理解。這個過程不僅僅是收集需求，更重要的是透過具體的例子來澄清模糊不清之處，識別潛在的理解差距，並確保所有人都朝著同一個目標前進。有效的探索能夠最大限度地減少不必要的會議時間，並提高有價值程式碼的產出 。

(2) 主要參與者：跨職能團隊的協作
探索階段的對話需要多元角色參與。通常包括產品負責人（或業務分析師）、開發人員和測試人員，有時也被稱為「三個好朋友 (Three Amigos)」。

產品負責人代表業務視角，確保功能滿足使用者需求；
開發人員從技術實現角度評估可行性與複雜性；
測試人員則關注功能的各種邊緣情況和潛在風險，確保可測試性。

這種跨職能的協作是探索階段成功的關鍵，確保從不同角度審視需求，形成更全面的理解。

(3) 核心活動：需求梳理工作坊與Example Mapping
探索階段的主要活動是進行「需求梳理工作坊」。這是一種結構化的會議，團隊成員圍繞著從使用者角度出發的真實世界系統範例進行討論。需求梳理工作坊的目標是促進對工作內容的共同理解，識別約束、驗收標準和說明這些標準的具體範例。

「Example Mapping」是需求梳理工作坊中常用的一種高效技術。它使用不同顏色的卡片來視覺化地組織討論，並產生具體的範例。

(4) 主要產出：共同理解與具體範例
探索階段的主要產出並非詳盡的規格文件，而是團隊成員間對「要做什麼」以及「為什麼這麼做」的深刻共同理解。此外，具體的、經過討論和確認的範例是這一階段的關鍵交付物。這些範例將作為下一階段「表述」的基礎，用於撰寫 Gherkin 情境。

如果探索階段做得好，往往能揭示出可以從使用者故事範圍中推遲的低優先級功能，幫助團隊以更小的增量工作，從而改善工作流程 。

對於 BDD 新手而言，探索是正確的起點；在掌握探索之前，很難從其他兩個實踐中獲得太多益處 。這強調了建立堅實共同理解的首要性。

B. 階段二：表述 (Formulation) – 將範例文件化

在探索階段就功能範例達成共識後，表述階段的任務是將這些範例以一種結構化、清晰且可被自動化工具理解的方式記錄下來。

(1) 定義與目的：將範例轉化為結構化文件
表述階段是將探索會議中確定的有價值範例，轉化為結構化文件的過程 。其主要目的是提供一種快速確認團隊是否真正對要建立的內容有共同理解的方法。與傳統文件不同，BDD 使用一種人類和電腦都可以閱讀的媒介來記錄這些範例，最常用的就是 Gherkin 語言 。這些結構化文件不僅是需求的描述，也是未來自動化測試的藍圖。

(2) 主要參與者：團隊共同審視與確認
雖然特定角色的成員（如業務分析師或測試人員，有時甚至是開發人員）可能會主導 Gherkin 情境的初稿撰寫，但整個團隊都應該參與審視和確認這些表述的範例 。這種協作編寫可執行規範的過程，有助於團隊建立用於討論系統的共同語言，並將問題領域的術語貫徹到程式碼中 。業務人員可以確認情境是否準確反映了業務規則和期望，技術人員則可以評估其可測試性和清晰度。

(3) 核心活動：使用 Gherkin 語言撰寫可執行規範
表述階段的核心活動是使用 Gherkin 語言撰寫「情境 (Scenarios)」。Gherkin 是一種業務可讀的領域特定語言，它使用一組特殊的關鍵字來賦予可執行規格結構和意義 。

(4) 主要產出：可執行的 Gherkin 規範
表述階段的主要產出是可執行的 Gherkin 規範，即一系列的「.feature files」。這些檔案不僅是團隊對系統行為共同理解的明確記錄，也是下一階段「自動化」的直接輸入 。它們以一種業務人員易於理解的通用語言編寫，同時也為自動化測試提供了堅實的基礎。

C. 階段三：自動化 (Automation) – 以測試驅動實作

自動化階段是將表述階段產生的 Gherkin 情境轉化為可執行的自動化測試，並以此指導實際的程式碼開發。

(1) 定義與目的：實作行為並由自動化範例指導
在擁有可執行的 Gherkin 規範後，團隊便可以利用它們來指導功能的實作 。核心做法是，針對每一個 Gherkin 情境中的範例，先將其連接到系統作為一個自動化測試。由於相應的功能尚未實作，這個測試在初始運行時必然會失敗 。這正是測試驅動開發 (Test-Driven Development, TDD) 的一個核心原則，只是 BDD 將其應用在了更高層次的行為規範上。隨後，開發團隊著手編寫必要的程式碼，目標是使這個先前失敗的測試轉為通過。

(2) 主要參與者：開發團隊與持續回饋
自動化階段主要由開發人員和測試自動化工程師參與。開發人員負責編寫實現 Gherkin 情境所描述行為的產品程式碼。測試自動化工程師則可能負責建構和維護自動化測試框架，並編寫將 Gherkin 步驟翻譯成可執行程式碼的「步驟定義 (step definitions)」。整個過程中，自動化範例為團隊提供了持續且快速的回饋 。

(3) 核心活動：串接規範與程式碼，測試指導開發
此階段，開發人員會將 Gherkin 自然語言步驟編寫成對應的自動化測試程式碼，並依據失敗測試逐步開發、修改功能直到測試通過。完成後，團隊會進行重構與維護，確保所有自動化範例持續通過，這些測試如同護欄，避免後續修改導致既有功能受損，大幅減輕手動回歸測試的負擔。測試人員因此能將更多精力投入於探索性測試等更有價值的活動。

(4) 主要產出：可運作軟體與自動化測試套件
自動化階段的主要產出是符合 Gherkin 規範所描述行為的可運作軟體。同時，一個重要的副產品是一套全面的自動化測試套件。這個測試套件不僅能夠持續驗證系統行為，確保軟體品質，更重要的是，它本身就是一份「活文件 (living documentation)」。這份文件因為與實際程式碼緊密綁定並持續驗證，所以遠比傳統的靜態文件更為可靠和即時。

成功實施 BDD 的關鍵考量

(1) 順序的重要性：探索→表述→自動化
BDD 的三個實踐（探索、表述、自動化）有明確的先後關係。必須先經過充分探索，才有高品質表述，再進入自動化。順序顛倒會導致自動化錯誤需求或不明確規格，無法發揮 BDD 成效。每個步驟都在降低不確定性，累積價值。忽略前置步驟，後續成果將變得脆弱或無意義。

(2) 協作是核心
BDD 本質是協作。不同角色（業務、開發、測試等）需共同對話與驗證，單打獨鬥不算 BDD。成功 BDD 取決於團隊間是否真正協作，文化比工具更重要。探索工作坊與共同範例討論，能加強這種多元共識。

(3) 高品質 Gherkin 規範最佳實務
專注描述「行為」而非技術細節。避免規格跟著實作細節變動，提升可維護性與穩定性。採用聲明式（而非命令式）寫法，讓情境更容易閱讀和溝通。使用真實世界、具體範例，聚焦業務規則，避免抽象或過度技術化。

(4) BDD 為敏捷流程加值
BDD 補強現有敏捷方法（如 Scrum、Kanban），特別在需求澄清、驗收條件共識與自動化驗證方面，讓價值流動更順暢。BDD 實踐強調人的互動，具體落實敏捷原則「個體與互動高於流程與工具」。

成功的 BDD 關鍵在於尊重正確順序（探索→表述→自動化）、落實跨角色協作、撰寫專注業務價值的 Gherkin 規範，並將其作為敏捷團隊提升需求共識與品質保障的核心手法。只重視工具與自動化而忽略人與對話，將無法真正發揮 BDD 長期價值。