How To Master Real-World BDD
And Deliver Higher Quality Features With Confidence
Ever wondered how high performing agile teams consistently outpace their competition delivering groundbreaking features sprint after sprint?
Behaviour Driven Development (BDD) is by far the fastest way I know to consistently get high quality features that will delight your users into production sooner.
But what does it really involve? Read on to find out!
Beyond the buzzwords - Unpacking The Essence Of BDD
Behaviour Driven Development (or BDD) has become increasingly popular over the past few years. Many organisations see it as a key factor to making agile deliver. And it's true that teams who do BDD well can get a significant competitive edge, streamlining their processes and aligning closely with user needs.
But, like many things in agile, BDD can be tricky to implement effectively.
So, what exactly is BDD? Is it merely about framing requirements in the "Given..When..Then" format, or using tools like Cucumber for test automation? The reality is much more nuanced.
I'm John Ferguson Smart, author of "BDD in Action" and a veteran in the realm of BDD and agile practices. Over nearly two decades, I've witnessed the evolution and impact of BDD firsthand
Interestingly, despite my deep involvement, I seldom use the term "BDD" in casual discussions.
Why? Because BDD, to me, isn't just a label or a set of practices. It's about fostering effective collaboration and zeroing in on high-value features, delivering them at a pace that meets today's ever-accelerating demands. But let's face it, that's quite a mouthful! So, for simplicity, we stick with 'BDD'
On this page, my goal is to demystify BDD. I'll delve into what BDD truly entails and highlight the core practices that are essential for harnessing its full potential and achieving tangible results.
So What Is BDD, Anyway?
BDD stands for Behaviour Driven Development.
It has been around for a while, and like a good wine, it has matured with age. Originally designed as an improvement on Test Driven Development (TDD), BDD has evolved to include a range of powerful requirements discovery practices that help teams get more clarity around the requirements they need to deliver, reducing defects, avoid misunderstandings and improving the value of the features they deliver.
In its simplest form, the BDD process looks something like this:
Let's walk through each step.
Step 1) Illustrate (or Discover)
Before you start work on a feature, you get together as a team and have a conversation where you explore the goals and motivations of the user: why does the user need this feature, what value does it provide, and how do we expect it to deliver this value. You talk about user journeys, constraints and business rules, and use concrete examples and counter-examples. You see what other rules and constraints these examples lead to, and write them down.
This step sound's easy but it actually takes a fair bit of practice and technique to run these conversations effectively. That's why the BDD community over the years has come up with practices like Example Mapping and Feature Mapping (see diagram) to help guide and structure the conversations, that make sure everyone stays focused and help record the examples and rules in a systematic way.
Another key point from this step is that, in BDD, the acceptance criteria are written not by the BA or the product owner, but by the whole team. There's a lot of subtle agile phsycology that goes into this little detail, but take my word for it, it's super important.
Step 2) Formulate
Next, you record these rules and examples in a structured, actionable format. We call these "executable specifications", because they are requirements that can be executed. We also call these "living documentation", because they document exactly what the system currently does.
👉 Order is important. We have found that this process generally works better when you do it after the Illustrate phase, in a separate session.
👉 Format is less important. Gherkin (the Given..When..Then notation you can see further down) is a popular format to do this in, but there are other options too.
Whatever format you use, it is important to remember that structured executable specifications are an output of the conversations, not an input to be provided to the team.
Cucumber is a commonly-used tool to collaborate around and automate specifications written in Gherkin, but it isn't the only one. In fact the actual format you use doesn't matter so much. The key idea is that you are expressing the requirements in a structured format that is both business readable and that can be executed.
Step 3) Automate (optional-but-recommended)
Now write some code to make these executable specifications run.
The automation bit is actually optional: you can get lots of value out of BDD just from having the conversations. So especially when you start out with BDD, don't get too worried if you don't automate all your scenarios.
But if you do it right, and if you make sure your application has testability built in, this can really help streamline the development process.
There are two ways you can do this. Firstly, you can automate before you write the application. Obviously, the test will fail - that's how you know you haven't already built the feature (and that your tests work). Then build enough of the feature to make the executable specification pass.
This approach works really well when you have (or create) a well-defined API layer. The automation coding flows smoothly into a TDD process, resulting in very tight feedback loops.
We call this "outside-in development", and it's by far the fastest way of coding large projects that I know. But it does take skill and practice, and involves a lot more collaboration between developers and testers to make it work.
The second way is to automate the skeleton code, and fill in the gaps as you implement the feature. This is easier when you start out, and it works, but it doesn't give quite the spectacular results you get with the first approach.
Step 4) Validate (easier if you did step 3)
A key part of BDD is that, if you are doing the automation part, then your fully automated executable specifications are part of your definition of done, and that become part of your product documentation.
Because that's (in part at least) how you demonstrate that a feature does what it is supposed to do. If the executable specifications run, the feature is good to go.
Of course there is exploratory testing as well - that's where you find most of the tricky defects. And with a solid BDD process, you can often get most of your acceptance criteria automated before or during the sprint, which frees you up for more and more effective exploratory testing - so double win!
And if you are in a regulated industry, where you need to provide evidence of testing each release - well BDD not only gives you this for free, but, if you write them well, it also gives you up-to-date functional documentation about your product.
Now that you have a set of executable specifications, whenever a new feature or user story comes in, you build on and enhance those existing specifications. If you write them well, you'll have a set of accurate, up-to-date documentation about what the application does, and what business needs it is satisfying. As a bonus, they act as your regression tests. Yay!
These four points should give you an idea of whether you are practicing BDD in an effective, efficient way, or if there are areas you might be able to improve.
But it's also useful to know what I wouldn't call BDD. Why? Not because there's anything sacred about the term "BDD" - I don't much care what you call it. But the techniques I outline below are generally bad news because they are wasteful and inefficient. They give poor results. (And they give BDD a bad name).
So let's look at the main BDD anti-patterns that catch people out...
What BDD Isn't - Common BDD Anti-Patterns
Here are a the two most common BDD anti-patterns I come across with the teams I coach:
Anti-pattern #1 - BAs or Product Owners write requirements in Gherkin
The BA or product owner writes requirements or acceptance criteria in the Given..When..Then format and then hands them over to the team (or records them in JIRA). Maybe the team "reviews" them in a sprint-planning or three amigos session.
This approach is both inefficient (it generally takes the BA longer to write requirements in this format, and can lead to them losing focus on expressing the key business requirements in favour of respecting a rigid format), and ineffective (the Given..When..Then scenarios written this way are often vague and hard to automate, and can miss important details and assumptions).
Anti-pattern #2 - Testers automate test scripts in Gherkin
This is where testers write automated test scripts using tools like Cucumber after the code is completed. It comes from the misconception that Cucumber is a test automation tool, and that Gherkin is a scripting language. More often than not, this simply just adds a layer of complexity to the test automation, and doesn't give the team many of the benefits of a well-tuned collaborative development approach.
It can occasionally be useful for documenting existing fuctionality, or for expressing certain kinds of test cases in a more concise way. But generally test scripts written in this format quickly become long, hard to read, and hard to maintain.
Conclusion
BDD is a powerful practice, but it is not well understood.
Like many other agile practices, it looks easy on the surface, but takes some experience and practice to really get right and reap the benefits.
But, more and more, it is a key factor I see that makes high performing teams stand out. It's the secret sauce that sets the exceptional apart from the average.
So the real question is: do you want to be one of these high performing teams?
If the answer is "YES", then in the next section, you'll find a treasure trove of resources that will help you take your journey towards BDD further...
Next Steps
Learn How To Write World-Class BDD Scenarios 10 Times Faster Using AI In This Free eBook
Without falling into common traps and ending up with unmaintainable test scripts
Unlock the secrets to quick and easy BDD scenario writing with this comprehensive guide. Learn how AI can revolutionize your workflow by providing smarter, quicker ways to achieve excellence in Gherkin scripting. Say goodbye to the old trial-and-error methods and embrace a future where quality and speed go hand in hand.
Inside the eBook, you'll uncover:
The 7 qualities that distinguish world-class BDD scenarios from the rest, and will make you stand out of the test automation crowd
How to avoid the common traps that testers fall into when they write Gherkin scenarios
The simple secret that everyone is teaching wrong about BDD
How to use AI to write BDD scenarios 10 times faster (and not end up with an unmaintainable mess!)
Get free access to a brand new AI tool specially trained to write high quality Gherkin scenarios in a fraction of the time.
BDD Online Courses
Need Some Help Implementing BDD In Your Organisation?
"The executable specifications made it really easy to add new test cases for the BAs, which made it much more flexible and quick to evaluate changes"
Are you trying to introduce BDD practices in your organisation? Chances are we can help! The Serenity Dojo coaches have helped hundreds of organisations of all size master BDD practices and reap the benefits.
Using a highly effective combination of tailored training and light-touch mentoring and support, we can get your teams collaborating more effectively and delivering more value sooner, using BDD practices tailored to your needs and your corporate culture - and at half the cost of comparable training engagements!
Or ready to chat? Fill in the form below and we will be in touch...