Behavior-driven Development, BDD, software testing

Test automation

Behavior-Driven Development: The Origins

What do you remember from the 1990’s? The launch of the Hubble Space Telescope, when Dolly the Sheep was cloned, or perhaps even when Google began indexing the World Wide Web. During that decade, another term also started floating around: Specification by example.

“We use realistic examples as a single source of truth for requirements and automated tests on software projects”

– Ward Cunningham, A Pattern Language of Competitive Development (1996)

Specification by Example was a breakthrough because it allowed for a more precise method of describing and defining requirements. Testers and developers were able to extract information about requirements through concrete examples rather than abstract specifications. It also provided a new method of helping requirements seem more business readable and better defined.

As the world of software began to advance at a rapid pace and Specification by example became increasingly diffuse, Test-driven development (TDD) coined by Kent Beck was introduced. The popularity of TDD set the tone of what was missing in the marketplace. It was completely driven by technology and was more of a programmer’s discipline rather than that of a tester’s – however, it was also missing a high level and business readable aspect. In 2006, Dan North introduced Behavior-driven development (BDD) to fill this void by placing specification on a business level – not through code, but business behavior.*

Fast forward to present day: Agile teams love how BDD allows them to create living documentation that is easy to maintain and can be consumed by all team members, including testers, developers, and product owners. Moreover, tools like Cucumber can leverage BDD scenarios for automated acceptance testing. So why are 80% of BDD projects failing?

Join Tricentis Founder Wolfgang Platz’s webinar to learn more about why BDD is so easy to adopt – but tricky to scale. He will cover:

  • Why BDD is great for Agile development
  • Where purely open source BDD approaches fall short
  • New strategies for scaling BDD for the enterprise