About airfocus

Try for free

Behavior-Driven Development


What is behavior-driven development?


Behavior-driven development definition

Behavior-Driven Development (BDD) is an agile software testing strategy that emphasizes creating acceptable outputs for end-users. Acceptable behavior is written out in natural language and agreed upon before development begins.

Benefits of BDD for product management

Crucially, for product teams, BDD focuses on making sure the product behaves in such a way that the user is satisfied. We’ll look at how that differs from test-driven development later.

BDD is a collaboration between product managers, developers, and test engineers. Each stakeholder represents areas of development: the reason for the product to exist; the way the project exists; and the verification that the right product exists. 

So that all these parties can be fully involved, and so that the verification process is more closely aligned with users, the BDD acceptance criteria are written in natural language that is discussed, agreed upon, and shared between the three parties.

The process of discussing, writing, approving, and recording these tests is iterative and helps product owners better understand how their product should behave under different circumstances. 

Talking through behavior-based test cases will often bring to light edge cases or previously unforeseen situations that then need their own acceptable behavior to be established.

The tests are written and approved before any development takes place so that success is a known target. 

Following the BDD strategy, the acceptance criteria are agreed upon, then the developers will write code that fails the test. They will then write code that passes the test according to the test criteria. Test engineers verify that the code passes the test, and in the best-case scenario, create automated tests that will be run at each following stage of development so that the system is consistently verified.


Agile: Best Practices and Methodologies

Read now
CTA eBook image background
airfocus eBook Agile: Best Practices and Methodologies

An example of behavior-driven development acceptance criteria

Let’s take a look at an example of BDD, as explained by a simple user story with acceptable behavior criteria.

User Story:

  • As a bank customer

  • I want my account to log out automatically after 5 minutes of inactivity

  • So that my account is not vulnerable if I cannot log out or forget to log out.

BDD Acceptance Criteria: The account logs out on both the client page and the server and redirects the client page back to the login page.

A behavior-driven development framework example

There are various frameworks or acceptable templates to create BDD scenarios. They all use natural language to communicate, which must be an agreed shared language so that all members of the team, product managers, developers, and testers have complete clarity.

One of the most common frameworks to communicate BDD acceptance criteria is the Given, When, Then structure. Continuing our banking customer example, the acceptance criteria would then be written as follows:

  • Given the customer is logged in

  • When the customer has not performed any action for 5 minutes

  • Then the customer is logged out of the system

  • … And redirected to the login page

These frameworks are useful because they clearly give the preconditions where the test is relevant, the triggers for acceptable behavior, and the expected behavior. They are also useful because they help product managers identify gaps. 

In the above example, talking through the scenario a product manager would probably realize there needs to be a warning period. Another behavior definition could be added before the test above as follows:

  • Given the customer is logged in

  • When the customer has not performed any action for 4 minutes

  • Then the customer is warned that they will be logged out of the system in 1 minute

  • … And the warning will count down from 59 seconds to zero seconds

The difference between BDD and TDD

BDD evolved from TDD, bringing product managers and developers together with test engineers to collaborate on concrete examples of acceptable behavior. This ‘acceptable’ behavior is defined according to the user stories that drive the project forward.

Where test-driven development (TDD) focuses on getting correct outputs according to the inputs to smaller software components, behavior-driven development (BDD) focuses on acceptable behavior from the software system from the end-user standpoint.


Agile: Best Practices and Methodologies

Read now
CTA eBook image background
airfocus eBook Agile: Best Practices and Methodologies

General FAQ

What is behavior-driven development?
Behavior-driven development (BDD) is an agile software development strategy to bring product owners, developers, and testers together to discuss, approve and record acceptable behavior of a system from an end-user’s point of view.
What is the difference between BDD and TDD?
Behavior-driven development (BDD) tests a product based on the desired user behavior. Test-driven development (TDD) focuses instead on features and test cases.
airfocus eBook Agile: Best Practices and Methodologies
Agile: Best Practices and Methodologies
Read now

Experience the new
way of doing product

Try for free

Book a demo

airfocus modular platform
Top rated
on major review platforms
g2 badge users love us
g2 badge leader fall
GetApp badge category leader
software advice badge
capterra shortlist badge
proddy badge roadmapping
crozdesk badge
All rights reserved.