Toggle Menu

Blog > Agile > BDD (Behavior-Driven Development), Is it for me?

BDD (Behavior-Driven Development), Is it for me?

Would you like to develop products in a way that helps you discover users’ real needs? In a way that focuses your effort on what really matters? Would you like users and technologists to speak a common language? Would you like to reduce waste, accelerates product delivery, and cuts costs? Behavior-Driven Development (BDD) can do […]

By Brian Sjoberg

August 26, 2021

Would you like to develop products in a way that helps you discover users’ real needs? In a way that focuses your effort on what really matters? Would you like users and technologists to speak a common language? Would you like to reduce waste, accelerates product delivery, and cuts costs?

Behavior-Driven Development (BDD) can do that for you!

What is BDD?

Behavior-Driven Development, or BDD, uses upfront collaboration to define concrete examples of user behavior prior to development. BDD provides a common language, based on simple, well-structured sentences, that facilitates communication between engineers and stakeholders. It enables the ongoing discovery of user needs throughout the product life cycle.

For example, let’s say we are building an online banking interface. Rather than defining detailed requirements that specify the user interface, business logic, and other details, BDD emphasizes collaboration across a diverse set of perspectives (e.g., product, technical, quality). With BDD, we start by defining an initial set of business goals and work together to develop concrete examples of behaviors that will achieve those goals. In our banking example, we will start with the feature we expect users to use the most, viewing their account balances.

That means we have to allow them to log in and access their accounts. We initially define a “happy path,” with things working as they should. For example:

Given an existing account owner with a balance
When I log in with valid credentials
And view my account
Then displayed is my balance

This plain English is easily understood by all. It is known as Gherkin, where Given is the setup/precondition, When is the user action, and Then is the expected outcome. BDD requires a conversation to generate this information, which can then be used in tools that run automated tests.

Benefits (Why BDD?)

Now that we have a general understanding of BDD, let’s go over some of its major benefits.

Reduced waste

BDD reduces waste by focusing on the most important features and defining examples that help to discover the real needs of users. With the behavior written first (behavior drives development), the team can concentrate on doing just enough work to satisfy the criteria and then getting feedback to learn more. This will reduce time and effort by ensuring regular and frequent collaboration throughout the development process. Because we are delivering to the users regularly, we will not waste time building the wrong thing.

Reduced cost

With reduced waste comes reduced cost. Regular feedback will help reduce the complexity of the product development effort and focus it on the right features. Teams will spend less time—and therefore less money—building unneeded functionality. Additionally, when BDD is used to create automated tests, defects can be identified more rapidly. That will make them faster (and cheaper) to fix because the code causing the problem can be more easily identified.

Easier and safer changes (with automation)

When the examples are documented in plain English and are regularly run as automated tests, both the business people and developers can easily understand what the product is intended to do and what it does not do. Developers will have a high degree of confidence (and therefore feel safer) when they update the code because the automated tests will catch any errors they inadvertently introduce.

Faster releases (with automation)

Examples turned into automated tests and run regularly (e.g. nightly) speeds up the release cycle considerably. Testers will no longer need to perform time-intensive manual testing sessions before each new release. Instead, the automated tests will do the bulk of the repeatable and rote acceptance testing. Teams will spend more time on more valuable efforts, like exploratory tests and other nontrivial manual tests.

So, is BDD for you? We believe so! And we hope you have enough information to try it out or learn more. Stay tuned for an upcoming article where we will do a deeper dive into how to get the most out of your BDD approach.

You Might Also Like