Why is Behavior Driven Development (BDD) not used by most agile teams?

My journey in Agile software development began in 2004 and has been a testament to the evolution of testing methodologies. Before BDD, I navigated through FIT (Framework for Integrated Test) using Fitnesse as the tool. This era was marked by peculiar tables like Column Fixtures, which posed a challenge. Fitnesse, in particular, was a poorly developed and unreliable tool. However, these obstacles didn't discourage us from creating thousands of Fitnesse tests at Ultimate Software, a testament to our resilience and commitment to improving our testing practices.

BDD Arrives

I was thrilled when BDD arrived. I love the Gherkin DSL (Domain-Specific Language). Dan North created JBehave (Java) as the first implementation of BDD. Interestingly enough, the Ruby community initially embraced BDD faster than anyone else. Instead of creating weird tables, we can now express our tests in English, obviously, within the constraints of the Gherkin DSL. If you are unfamiliar with BDD, all scenarios follow this basic structure:

• “Given” describes the preconditions for the scenario.
• “When” describes the action under test.
• “Then” describes the expected outcomes.

You can also use And and But keywords to join Given, When, or Then steps together more readably.

Here is an example:

Given I have a current account with $1,000.00

And I have a savings account with $2,000.00

When I transfer $500.00 from my current account to my savings account

Then I should have $500.00 in my current account

And I should have $2,500.00 in my savings account

That is a BDD scenario. You can group several scenarios into a single feature file. I am not going to explain all the aspects of BDD. Instead, I will provide you with some useful links:

• BDD in Action book: https://www.amazon.com/Action-Second-John-Ferguson-Smart/dp/1617297534
• The SpecFlow Gherkin reference: https://docs.specflow.org/projects/specflow/en/latest/Gherkin/Gherkin-Reference.html
• The Cucumber Gherkin reference: https://cucumber.io/docs/gherkin/reference/

Early Days

However, the early days of BDD were challenging. The only frameworks available were for Java and Ruby programming languages, which posed a problem for our Microsoft.NET shop. We could experiment with BDD, but our options were limited. The lack of comprehensive tooling and resources for BDD in different programming languages was a significant hurdle. Finally, we could fully leverage BDD in our product development when Cucumber was ported to .NET (SpecFlow), which opened up new possibilities for us.

A few years back, I was the co-founder of ArgusQ. We built a crowdsourcing platform to test ideas and specifications. While our customers enjoyed the product, we did not make any money. Eventually, we started discussing a pivot. Much discussion focused on BDD and how to build a tool to help its adoption. My co-founder, Fernando, loves BDD. I do, too. We used BDD to build ArgusQ, but the data kept pointing to a tiny market.

At some point, we decided not to work on the pivot and instead dissolved the company. Still, I kept teaching BDD everywhere I went. I always looked for indications of how BDD was progressing in the marketplace. Everything I found indicated that our first observations were correct: low adoption.

BDD Adoption

For example, VersionOne, a provider of Agile software development tools, has published a 'State of Agile' annual report for some time. In their 13th edition, published in 2019, you can find this chart:

SOURCE: Dux Diligens. (2019, May 7). 13th Annual State of Agile Report (p. 10). Retrieved from http://www.duxdiligens.com/wp-content/uploads/2019/09/13th-annual-state-of-agile-report_7_May_2019.pdf

BDD is second to last, just above emergent design. I do not know if you mentioned “emergent design” before your development team. I had, and you get back blank faces with no idea what you are talking about. In other words, BDD was doing a little better than a deer in the headlights practice.

Are things any better now? Maybe. The software application tools vendor SmartBear has been publishing an annual report called 'State of Software Quality/Testing' for some time. In their 2022 edition, you can find this chart about BDD adoption:

SOURCE: SmartBear. (2022). The State of Quality Testing 2022 [Ebook] (p. 25). Retrieved from https://smartbear.com/resources/ebooks/state-of-quality-testing/

The message from SmartBear is that BDD is found in larger organizations, but the percentage is 24%. Also, the report only has two years of data.

Besides, most of the expansion in the use of BDD is for GUI test automation with Selenium. This is one of the 'mutations' of BDD, where it is used in a way it was not originally intended for. That is a terrible use of BDD. Harmful mutations in the world of practices and processes do not cause something to die out like in biology. Agile has several of those ugly mutations. [There is no other way to explain SAFe and its adoption. By the way, SAFe is not Agile. Never let anyone tell you otherwise.]

BDD is Hard

While I am a staunch advocate of BDD and believe in its excellence, I have witnessed teams struggle with its adoption. I have often questioned my teaching methods, thinking I was doing a poor job. However, while watching a BDD video recording of Liz Keogh explaining BDD and the Cynefin framework, I realized that BDD is indeed challenging and supposed to be. Acknowledging this difficulty is the first step towards overcoming it.

Cynefin (pronounced kuh-nev-in – do not ask me why; I do not speak Welsh) is a decision-making framework. Cynefin means habitat. Dave Snowden created Cynefin in 1999. Cynefin offers five decision-making domains. The following diagram describes the domains:

SOURCE: Agility11. (2020, January 7). Understanding Complexity to Make Better Decisions: Cynefin Demystified. Retrieved from https://www.agility11.com/blog/2020/1/7/understanding-complexity-to-make-better-decisions-cynefin-demystified

As Liz explains in this short video, BDD is for complicated stuff. To paraphrase Liz, if you try to write a BDD scenario and cannot finish it, that is complicated. The only choice is to have a conversation with your teammates and figure out how to get the answers you need so you can complete your BDD scenario. That means embracing uncertainty. Most people feel very uncomfortable with uncertainty. That is why we have these BDD mutations, like using it to drive your Selenium scripts.

I have two reasons BDD has been on my mind in the last few weeks. While discussing the Testaify roadmap, we discussed implementing use case testing by capturing requirements using NLP (Natural Language Processing). One idea was to focus on BDD for the first iteration. The other reason was the emergence of a new AI startup called purgo.ai. Their offering depends on BDD.

Maybe the time for BDD is finally here. I hope that is the case.