There is an undeniable allure to the concept of Behaviorial Driven Design (BDD). In theory, different organizational groups will be able to use a unified, English-like, language to bridge communication barriers. Business analysts, developers, quality assurance and product can all work together using the same specification language and therefore eliminate misunderstandings between different factions of an organization.

In practice, however, quality assurance generally ends up spending more time building and maintaining automation written using BDD. In every company that I have worked for, business analysts, developers and product almost never participate. It’s too difficult to enforce. Even if it comes from the company executives, BDD inevitable becomes something only quality assurance uses. And without the participation of the rest of the company, most of the advantages of BDD are lost. It becomes just an another layer of abstraction which requires more boiler plate code to create and maintain.

BDD is definitely a nice to have feature if your organization has the resources and capacity. But unfortunately, regardless of how beautifully descriptive and well maintained your BDD scripts are, the BDD aspects of those scripts will rarely be read by the business or other factions of your organization. This ultimately hinders the primary objective of software quality assurance and the organization as a whole: to ship software and make money.