Love it or hate it—Behavior Driven Development is still widely used. And unfortunately still miss-understood.
You’ve probably heard a lot about it, both good and bad, but what do the experts have to say?
INDEX
In this post you’ll get an introduction to BDD based on the ten years of conversations I’ve had with some of the top leaders in the space.
This information is backed, attributed, and sourced from real-world experts who have appeared on my podcast.It’s real advice from real BDD practitioners.
Let’s start by answering the question, “What is Behavior Driven Development (BDD) anyway?
What Is Behavior-Driven Development?
Behavior Driven Development (BDD) is a collaborative approach to software development that aims to bridge the communication gap between business and technical teams. The core idea is to create a shared understanding of the software's intended behavior using concrete examples.
As Matt Wynne, co-author of The Cucumber Book, explains: “BDD is a way of getting teams to articulate their requirements and agree on their requirements and then express those requirements in a way that flows naturally into automated tests.”
Aslak Hellesøy, creator of Cucumber, adds, “BDD is really only about two things. The first thing is about building the right thing, making sure that various stakeholders who are involved in a software project are on the same page, and those stakeholders can often be domain experts or businesspeople.”
The process revolves around writing scenarios using the Given-When-Then format, which describes the preconditions (Given), the action or event (When), and the expected outcome (Then). These scenarios serve as executable specifications, defining how the software should behave from the user’s perspective.
Transform Your Testing in 5 Minutes a Day
What Are the Benefits of Behavior-Driven Development?
BDD offers several key advantages:
Improved communication and collaboration: By involving business stakeholders in writing human-readable scenarios, BDD fosters a shared language and understanding between technical and non-technical team members. This helps ensure everyone is on the same page about what needs to be built.
Clearer requirements: Focusing on behavior and examples helps uncover ambiguities, missing requirements, and incorrect assumptions early in the development process. This leads to building the right software and minimizes costly rework later. As John Ferguson Smart, author of BDD in Action, states: “If you get clarity on requirements across the whole team, you get a whole lot of defects that just don't exist; that don't happen that would normally have happened.”
Faster feedback: The executable nature of BDD scenarios enables quick feedback on whether the software is meeting the desired behavior. Automated tests can be run frequently, catching issues early and providing confidence in the system's functionality. Gáspár Nagy, a BDD trainer and coach, emphasizes, “The good thing is that briefness itself so that you have a concise and small scenario that fits under the screen that you can easily share with the stakeholders. That also seems to be a good principle.”
Living documentation: The scenarios serve as living documentation that is always up to date with the code. This makes it easier for new team members to understand the system and for stakeholders to verify the software meets their expectations. As Seb Rose, co-founder of Cucumber Limited, puts it, “The documentation aspect of these scenarios is massive, so it's written in business language, which means that not only do the developers and the testers understand the specification, but it means that our customers and our product owners can also understand it.”
Automation Testing Training Courses
How Is Behavior Driven Development Different from Other Methodologies?
Unlike traditional requirement documents that can be open to interpretation, BDD scenarios are concrete and unambiguous. They focus on the “what” rather than the “how,” leaving implementation details to the developers.
Compared to test-driven development (TDD) which is developer-centric, BDD is a team-wide practice. It shifts the collaboration to the start of the development process, involving business stakeholders in defining the desired behavior. As Dan North, the originator of BDD, remarks: “I teach BDD as a ‘whole team' approach. I get developers, testers and business representatives together to collaborate on what the system does.”
While BDD scenarios can be automated, the primary goal is fostering shared understanding and communication. Automation is a beneficial side effect, not the sole purpose.
Aslak Hellesøy clarifies: “BDD is about building the right thing. It's really a collaboration practice, a flow, a way of getting teams to articulate their requirements and agree on their requirements and then express those requirements in a way that flows naturally into automated tests.”
How Do I Implement Behavior Driven Development in My Organization?
Adopting BDD requires a mindset shift and some practice. Key steps include:
Educate the team: Ensure everyone understands the principles and benefits of BDD. Consider training or coaching to help the team adapt to the practices. Matt Wynne advises, “If you're a business analyst, find a developer. If you're a QA, find a developer and a business analyst. If you're a developer, find a QA and a business analyst and take one of the stories for your next sprint and sit down and spend 20 minutes, just 20 minutes before anybody writes any code, just discussing that story.”
Collaborate on scenarios: Bring business and technical people together to write scenarios collaboratively. Techniques like Example Mapping can help structure these conversations. BDD thought leader Liz Keogh suggests, “Create a scenario that describes what you want the software to do. Using that framework, it forces you to think at a higher abstract level. And that level is free from implementation.”
Automate the scenarios: Use BDD tools like Cucumber or SpecFlow to automate the execution of scenarios against the system. This provides fast feedback on the software's behavior. John Ferguson Smart notes, “Cucumber is a tool for running acceptance tests that are written in this particular style…what we need is just enough, just enough scenarios so that there can be no misunderstanding about what that rule means.”
Iterate and refactor: As with any Agile practice, BDD is an iterative process. Continuously refine the scenarios, the automation code, and the software design as you learn more. Seb Rose advises, “Refactor that documentation to ensure that you keep it in a structure that makes sense to the people that are specifying it and implementing it.”
What Challenges Should I Be Aware of When Implementing Behavior Driven Development?
Some common pitfalls to watch out for:
Scenarios that are too technical: BDD scenarios should be written in business language, focusing on behavior rather than implementation details. Avoid scenarios that mention UI specifics or technical jargon. As BDD practitioner Lance Kind warns, “I don't think there's a lot of value in talking about given when there ends with implementation details. Why do I feel like that? Because number one, the negative value is right away. You're going to have more maintenance every time those specific details change.”
Treating BDD as just automation: While automation is valuable, the real benefit of BDD lies in the shared understanding and collaboration it enables. Don't neglect the conversation part of the process. Aslak Hellesøy reminds us, “It's really a collaboration practice, a flow, a way of getting teams to articulate their requirements and agree on their requirements and then express those requirements in a way that flows naturally into automated tests.”
Trying to automate everything: Not every scenario needs to be automated. Focus on the key behaviors that are most valuable to automate for fast feedback. Some scenarios may be best executed manually. Matt Wynne suggests, “It's a matter of using a flavor of Cucumber which can actually reach directly into your code. There's no reason why (…) a Cucumber test has to integrate the entire stack of your app.”
How Do I Structure My Team for Behavior Driven Development?
BDD works best with cross-functional teams that include businesspeople, developers, and testers working closely together. Some key roles are:
Product Owner: Represents the business stakeholders and helps define the scenarios. As Lance Kind explains, “The product ownership is often used to being told to do this, so much so that they just provide that as a habit. There are a lot of habits that people have now around imperative, requirements that, when they start to go into BDD are hard to break.”
Developer: Participates in writing scenarios, implements the software, and automates the scenarios. John Ferguson Smart notes, “It's really Cucumber BDD. It works best when it's developers who write the test code. But that doesn't mean that the testers, are out of a job. It just means that their job is not automation, in my opinion. Their job is still valuable in designing the test and figuring out what tests to write.”
Tester: Collaborates on scenarios, thinks about edge cases, and explores the system beyond the defined scenarios. Gáspár Nagy advises, “You need to go through that. Think [about] which kind of business rules [you’re] validating there and maybe make many smaller scenarios out of that if it’s really what you want.”
The whole team takes collective responsibility for the software quality, with everyone contributing to the BDD process in their area of expertise. As Seb Rose puts it, “Behavior-driven development is about shared endeavor. It's about reaching a shared understanding. This means it's about collaboration.”
Summary of what IS BDD and what is NOT BDD
| Behavior Driven Development (BDD) | NOT Behavior Driven Development (BDD) |
|---|---|
| Collaborative approach involving both technical and business teams | Isolated development with little to no input from business stakeholders |
| Focus on creating a shared understanding of software's intended behavior using concrete examples | Focusing primarily on the technical implementation details without considering the end user's perspective |
| Scenarios written in a Given-When-Then format to describe preconditions, actions, and expected outcomes | Use of technical jargon or implementation-specific details in requirements |
| Scenarios serve as executable specifications and living documentation | Static documentation that becomes outdated quickly and lacks clarity on software behavior |
| Emphasis on collaboration and communication across the whole team | Reliance on automation alone without fostering shared understanding |
| Automation is a beneficial side effect, not the sole purpose | Treating BDD as just a tool for test automation |
| Continuous refinement and collaboration on scenarios and tests | Trying to automate every possible scenario, leading to maintenance overhead |
Understanding BDD Better
In summary, Behavior-driven development is a powerful practice for building shared understanding and aligning software with business needs.
By fostering collaboration and fast feedback, it helps teams deliver valuable, high-quality software more effectively. While it requires some investment to adopt, the benefits of BDD can significantly improve the outcomes of software development efforts.
As John Ferguson Smart concludes, “Focus on keeping the code clean. What I find is that simplicity and clean code go a long way, and people tend to make the code more complex [and[ complicated. Make sure your code actually does what it says and says what it does. That's kind of the art of writing simple code.”
Want More Real-World Expert Advice in Just 5 Minutes a Day
In my new book, I’ve distilled the most relevant & evergreen info I've collected from doing 600+ industry interviews over the past decade — into daily, bite-sized snippets for your QUICK & EASY consumption.
That means you're getting key insights of some of the smartest E2E testers I've had the privilege to interview on my Test Guild podcasts.
Plus, I’ve structured it in a way that you just need to read 1 page/day i.e. invest ONLY 5 mins/day to get the most out of it.
My goal is to provide you with valuable (and actionable) tips, tools, best practices, and positive mindset shifts that you can easily apply to your daily software testing efforts, career – and even life in general.
