What is Behavior-Driven Development?

Simply stated, Behavior-Driven Development (BDD) is a practice of specifying software behaviors before development starts. In other words, no code is created until the behavioral specification for the software has been created.

So, what is behavior and why is this important?

The first thing to understand is that all software is behavior.

Software developers ultimately program software systems to behave in specific ways in the different scenarios that the software needs to support, and tests verify that the software it is behaving as expected. On the surface, this sounds simple and straightforward.

Unbeknownst to most people who do not write software code or test software systems, developers and testers spend a lot of time during the development phase (e.g. Sprints or Iterations) to analyze the requirements and extract and understanding of what the behaviors should be.

Even then, this is not always clear at first and may result in a few attempts before they feel they have a good understanding of the expected behaviors.

However, because this is done during development instead of before coding and testing starts, this opens the door to misunderstanding and rework.

We see three types of cases where this happens:

Misunderstanding between the implementers (the people coding and testing the software), whether they're all on one team or on different teams
Misunderstanding between the implementers and their stakeholder or stakeholder representative(s) (e.g. PM, PO, TPO)
Misunderstanding between the product representative and the stakeholder

Case 1

If the developer interprets the behavior differently from what the tester interprets it to be, the tests will fail, but who is to blame? The work won't be done until the misunderstanding has been resolved. This scenario occurs even when companies don't have testers and their developers do all the testing because many such development teams adopt the policy that a developer should not test their own code because of the potential issue of bias and false-positives.

Case 2

If the developer and the tester interpret the behavior the same way (whether from the start or as a result of their work during the development phase) but this differs from what the stakeholder expects, the work will have gone all the way through the development and testing only to be rejected by the stakeholder. Worse if that behavior has been released into production. Obviously, this can occur even when the developer is also the tester.

Case 3

If the product representative misunderstands the stakeholder's expectations, it's most likely that this won't be caught until the stakeholder discovers this misunderstanding. Some teams have post-development reviews with their stakeholders before the codes is placed into production and will likely be caught then, resulting in rework.

However, this doesn't always happen and instead the misunderstanding might not be discovered until it's in use.

If it's discovered while in use, at the very least there will be defects reported that must then be analyzed and potentially fixed. In more extreme cases, it can result in severe impacts to the business, such as financial loss and legal action.

Root Cause: Late Discovery of Misunderstanding on Requirements

In all the cases mentioned above, the root cause is the late discovery of the misunderstanding.

This misunderstanding on requirements also happens to be the root cause for:

Inaccurate estimates
Missed deadlines
Defects and other quality issues

Solution: Shift Discovery of Misunderstandings to Before Development Starts

As stated above, BDD is a practice for turning software requirements into precise and unambiguously specifications of behavior.

This is done before development starts and allows the stakeholders, product people (PMs, POs, TPOs, UX), developers, and testers to collaboratively create agreement on how the software should behave.

This removes ambiguity and removes the waste that results from that ambiguity. It allows you to bake quality into the requirements.

It results in software specifications that document the business requirements in a way that it can be used directly as the specifications for development and testing.

It also turns out to be the most effective way for requirements to be broken into the smallest pieces that will result in working software, as expected from Agile software development.

I've written more about why software requirements, in general, is the most important aspect of software development, and about my work in this field on my page about Software Requirements.