我很想多人或許聽過Behavior Driven Development (BDD, 行為驅動開發)、Acceptance Test Driven Development (ATDD, 驗收測試驅動開發) 、Specification by Example (SBE, 實例化需求)，聽起來很像，但是它們又有不同名字，並且是不同人發明的，那到底是怎麼一回事呢？

他們都是屬於「以範例驅動開發」的範疇，目的在於促進需求澄清、建立共同理解、提升系統品質。它們彼此之間有很多重疊，但也有各自的歷史背景與實踐重點。讓我們進一步來聊聊他們。

起源

(1) Behavior Driven Development (BDD, 行為驅動開發)

Dan North 在 2006 年發表的一篇名為 "Introducing BDD"[1] 的文章，詳細闡述了BDD的初衷和核心思想。BDD 的誕生是對當時Test-Driven Development (TDD) 的一種回應，主要目的是為了幫助新的敏捷開發團隊，更容易理解和實踐測試驅動的開發方法。

North 提出 BDD 的主要動機，是改進 TDD 的教學和實踐，他觀察到，通過使用更貼近業務語言的術語（例如使用“行為”而不是“測試”），可以更有效地向開發人員傳達測試的價值和意義，並將開發過程，與業務價值和用戶需求緊密聯繫起來。

[1] Introducing BDD, Dan North, March 2006.
https://dannorth.net/introducing-bdd/

(2) Acceptance Test Driven Development (ATDD)

Kent Beck 在 2003 年出版的《Test Driven Development: By Example》 一書中簡要提到了 Acceptance Test Driven Development (ATDD)，但他當時對這種方法持保留態度，認為其在實踐中可能難以應用。

圖 4-1 Test Driven Development: By Example 書籍封面

儘管如此，ATDD 的基本思想，即在編寫程式碼之前定義驗收標準，並使用這些標準來驅動開發，在當時的敏捷社群中已經開始受到關注。

儘管 Kent Beck 最初對 ATDD 持保留態度，但由於 Fit (Framework for Integrated Test) 和 FitNesse 等工具在 2003 年至 2004 年間的普及，ATDD 開始被更廣泛地接受。這些工具提供了一種以客戶可理解的方式，編寫和自動化驗收測試的方法，從而使得 ATDD 的實施變得更加可行。

Ken Pugh 的《Lean-Agile Acceptance Test-Driven Development》是另一部推廣 ATDD 的重要著作，它深入探討了如何在敏捷環境中實施 ATDD 並實現更好的團隊協作。此外，Markus Gärtner 的《ATDD by Example: A Practical Guide to Acceptance Test-Driven Development》提供了一個實用的、入門級的 ATDD 指南，通過具體的案例研究和示例，幫助讀者理解和應用 ATDD 的原則和實踐。

另一個有名的推廣者：Bas Vodde，他強調ATDD 不僅僅是“測試先行”或自動化驗收測試的技術實踐，而是一種促使業務、開發與測試團隊在早期就攜手合作建立共識的重要機制。

他通過大量的務實的做法，幫助團隊導入ATDD，並在會議、工作坊、研討會中分享實戰案例，向業界展示，如何通過 ATDD 促使需求對齊與減少重工。在他的著作中：《Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum》的測試章節，Bas 詳細論述了ATDD在大規模敏捷轉型中的作用，並以具體案例說明，如何與這方法結合，從而打造一個完整的需求與驗收流程。

(3) Specification by Example (SBE)

在2004年，Martin Fowler創造了"Specification by Example" [2]這個術語。然而，Gojko Adzic被認為是SBE的主要推廣者。

Adzic撰寫了多本關於此主題的權威書籍，包括 2011 年出版的《Specification by Example: How Successful Teams Deliver the Right Software》和 2009 年的《Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing》。

Adzic 的著作記錄了許多團隊的做法，包含使用範例來指導軟體的分析、開發和測試過程，並且還總結了SBE的核心原則和實踐模式。

[2] Specification by Example, Martin Fowler, 2004
https://martinfowler.com/bliki/SpecificationByExample.html

Specification by Example 的核心思想是一種協作方法，它強調使用真實的、具體的示例來說明軟體的需求，而不是依賴於抽象的、或模糊不清的陳述。這種方法的主要目標，是讓業務（如產品負責人、業務分析師）和軟體開發團隊（包括開發人員和測試人員）之間，能夠有好的溝通方式。

適用時機

(1) Behavior Driven Development (BDD)
適合需要高頻溝通、快速迭代的敏捷團隊，特別是想讓非技術人員參與規格定義時。打破技術與業務的語言隔閡，讓需求更貼近用戶視角。在這個過程中，要從使用者行為角度出發，描述「怎麼做」與「應該怎麼反應」時，讓所有人（包括非技術人員）透過直觀的語法（如 Given-When-Then）理解需求。

(2) Acceptance Test Driven Development (ATDD)
強調在開發前，由業務、測試與開發三方一起討論並設定明確的驗收條件，避免後期返工。
當需求需要明確界定成功與失敗的標準，也就是要有個結構化的方式驗證業務需求，以確保功能完成時，真的能符合業務的預期。

(3) Specification by Example (SBE)
適用於當需求複雜，且易產生誤解時，透過具體例子來討論和確認需求。尤其在跨部門（業務分析、開發、測試）需協同工作時，這些範例可以提供溝通橋樑。

當需要形成一份隨系統演進而持續更新的「活文件」，SBE 可將討論過程中的範例轉化為自動化驗收測試，確保需求在實作過程中不斷被驗證。

下表是他們三個方法的簡單比較：