Real-World BDD

What are the minimal practices you can do, 
and still say you are doing Behaviour Driven Development?

"Do you even BDD?"

BDD (Behaviour Driven Development) 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 pretty good competitive edge. But, like agile in general, it can be tricky to implement.

But, like agile in general, it can be tricky to implement.

But what is BDD, anyhow? Isn't it just using the "Given..When..Then" format for acceptance criteria, or using Cucumber for test automation?
Turns out there's a little more to it than that.

You might be surprised to know, I don't use the term "BDD" that much. 

See, despite the heading of this paragraph, I'm not that interested in telling you whether you are doing "real BDD" or "BDD properly". 

When it comes to BDD, I'd prefer to say something like "trying to collaborate more effectively to focus on delivering high value features faster", but that's a bit of a mouthful. So BDD it is.

On this page I want to explain what BDD is actually about, and what are the key BDD practices you REALLY need to be doing if you want to get good results.
CUSTOM JAVASCRIPT / HTML

So What Is BDD, Anyway?

BDD stands for Behaviour Driven Development. 

It's been around for a while, and like a good wine, it has matured with age. But like many agile pratices, it is essentially a relatively simple process. 

In it's simplest form, it goes 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.
 This stage is essential to BDD - if you aren't having the conversations, you aren't doing BDD, no matter what format you write your requirements in, and no matter what tools you use.
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.
  The key thing that makes these structured requirements part of a BDD process is that they represent the rules and examples that emerged from the conversations in the previous step, written in a more rigourous format.
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.
Writing clean, business readable executable specifications that capture the real business intent and encourage collaboration and conversation, and that are executable, is a little bit of an art. 

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). 
CUSTOM JAVASCRIPT / HTML

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.

So the real question is: do you want to be one of these high performing teams?

In the next section, you'll find a few useful resources if you want to take your learning further.
CUSTOM JAVASCRIPT / HTML

Some video tutorials and articles on BDD and agile test automation

Some books on BDD

BDD In Action, 2nd edition

John Ferguson Smart and Jan Molak

Discovery: Explore behaviour using examples

Gaspar Nagy and Seb Rose

Formulation: Document examples with Given/When/Then

Seb Ros and Gaspar Nagy

The Cucumber Book: Behaviour-Driven Development for Testers and Developers

Matt Wynne and Aslak Hellesoy

Behavior-Driven Development with Cucumber: Better Collaboration for Better Software

Richard Lawrence and Paul Rayner

Specification by Example: How Successful Teams Deliver the Right Software

Gojko Adzic

CUSTOM JAVASCRIPT / HTML

BDD Online Courses

And Master BDD Requirements Discovery Practices in this in-depth video training

Write automated acceptance tests with Cucumber in Java faster and more easily.

CUSTOM JAVASCRIPT / HTML

Need Some Help Implementing BDD In Your Organisation?

"John opened my mind to a more collaborative, productive, improved way of working"

- Tina, Investment Banking Vice President, London
"I really was able to understand BDD and how to apply it in my daily work"

- Uinicius, Software Developer, New York
"We are already seeing a very visible and significant increase in the quality of the scenarios"

- Parimala, Team Lead, Cary
"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"

- Brotin, Lead Test Manager, New York
Are you trying to introduce BDD practices in your organisation? Chances are we can help! The Serenity Dojo has helped dozens 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.

Book a call below and we can chat!
CUSTOM JAVASCRIPT / HTML
Powered By ClickFunnels.com