What is BDD?

Behavior-Driven Development (BDD), simply put, is a framework for software development that encourages better communication between all team members and stakeholders to achieve more effective results. Since the focus is on the behavior of a product, the entire team can more easily understand, in the simplest terms, what the expected results of these defined behaviors should be. 

In BDD, team members across all stages of a development lifecycle strive to speak the same language–a more “common code,” so that both highly technical stakeholders and non-technical team members can more clearly understand one another. Since effective communication is the main goal of BDD, the team is able to more intimately understand the desired behavior of a feature, the results all stakeholders are invested in, and how to achieve those results.

behavior driven development process chart

A comprehensive understanding between all members of the team also helps bridge the gaps between stages of a development cycle; by speaking the same, common language, the development team can more clearly establish the desired outcomes of a product or service to the quality assurance team, so that they can they more effectively test the product for bugs or defects.

Some major benefits of a behavior-driven development model include:

  1. Accessibility: Since the main drive of BDD is collaboration between all members of a team, anyone is able to engage with the process and bring specific knowledge to the table
  2. Automation: A behavior-driven approach makes the process of developing automation much more streamlined; since the desired steps and outcomes are already plainly defined, writing code to automate is simplified
  3. Adaptability: BDD allows a development team to easily edit or modify along the development cycle to address changes in features/desired outcomes for the customer

What does BDD look like?

The greatest benefit of BDD implementation is that it describes, in an unambiguous way, the exact set of behaviors and desired outcomes of a product or application. From start to finish, this model allows all members of the team to utilize their specific knowledge more effectively, since they clearly understand each set of behaviors that are expected.

Let’s take a look at how BDD “common language” is established and structured, to more or less be in plain English among the team members. BDD helps to facilitate this communication to your testing team so that they clearly know what the desired outcomes are, and what defects to look out for.

BDD cases are written in three main sections, forming a Given-When-Then structure:

behavior driven development venn diagram

Context: The beginning or starting state (“Given” statements)

Event: What the user does (“When” statements)

Outcomes: What results are desired (“Then” statements)

Given a user is on the login screen

           And they enter a valid username

           And they enter a valid password

When they press the login button

Then they should see the login successful page

Since a BDD approach allows for this style of communication, business people can focus on describing the issues and things that matter most to their customers in such a way that developers and quality assurance testers fully understand what is expected. 

When should BDD be used?

Approaching testing with BDD in mind allows for developing tests at any stage in the development cycle, making it much easier to address last-minute changes or bumps in the road along the way.

From the beginning of the entire development lifecycle these behavioral benchmarks have been established, so developers have a framework for writing code and what will be the expected outcomes all along the way. A problem can arise, however, in behavioral testing versus unit testing, in that behavioral tests may not always indicate what, exactly, the problem is. 

In our above example of a behavioral test case, our behavioral test would only fail if the user was not shown the login successful page after completing the needed functions. In this event, the behavioral test would only indicate that there was a problem, whereas a unit test in isolation would identify exactly why the user was not shown the successful login page. While behavior-driven development models may function in much more plain terms with an end goal in mind, unit testing and testing in isolation may be needed to identify the specifics of any bugs found.

Comparing BDD and TDD

BDD can differ from traditional unit testing, in that it may take a longer period of time to truly complete an entire behavioral test, so careful attention to planning the lifecycle of a project is important. Unit testing is, by and far, much faster to complete than BDD testing, but a “shift left” (that is, beginning testing early on in the development process) can also be a benefit in finding more bugs early on with the plain English cases.

In unit testing, where most tests are written in technical language and code, the developer is responsible for writing cases that ensure the code simply functions. In a BDD model, however, behavioral test cases are best written by the team members who likely understand their customer the best–usually the product owner and business/development team. Further, since behavioral testing is driven by the end goal for the user, the quality of testing can benefit greatly from a slightly longer timeframe. 

Another difference between behavior-driven development and test-driven development is the accessibility of information to all members working on a project. In a traditional test-driven development format, it is likely that only the developers and testers will be reading and working with the test cases; in behavioral-driven development, on the other hand, most anyone can read, understand, and give feedback on development and testing-–from the product owner, the business owner, or any other outside stakeholders.

Finally, since BDD focuses on specific sets of behaviors, it is much more well-suited for functional and black box tests such as APIs and webUIs. On the other hand, performance testing–where very specific, detailed information is needed–may be better accomplished with traditional TDD testing.

Behavior-driven development and test-driven development both have their benefits when it comes to QA testing. Our experience with both frameworks allows us to provide guidance on what works best for you. At PLUS QA, we’re here to help, regardless of your testing needs. Please feel free to reach out to us with questions and inquiries!

Smartphones face up on a table next to a laptop keyboard.A laptop open next to an iMac, with an iPhone on the desk as well.