Broad brushes and narrow brushes: there’s more to BDD than Given/When/Then

IT teams today are under constant pressure to deliver more value sooner, and Behaviour Driven Development (BDD) is one of the more effective ways to help teams deliver the high quality software that their business needs. When they adopt BDD, many teams look to tools like Cucumber to help them. But BDD isn’t simply about picking up a new tool.

If you have done any work with Agile projects, you may have come across requirements expressed like this:

Given I have £1000 in my bank account:
When I withdraw £100 from a third party ATM 
Then I should be charged £1 transaction fee
And I should have a balance of £899 in my account

This format is called Gherkin, and it was invented by Dan North, about a decade ago, as a way to express requirements more clearly. It is also used in BDD tools like Cucumber as a way to automated acceptance criteria.

When used properly, this format is a great way to express and discuss detailed requirements in a clear and unambiguous way. Gherkin can act as a central source of truth for business analysts, developers, testers about what they should be building. And when automated, these requirements become “executable specifications” that demonstrate that the application is fit for purpose.

With the growing popularity of Cucumber and tools like it, the Gherkin format has become for many synonymous with Behaviour Driven Development, or BDD. Cucumber is frequently used for test automation, and in many Agile teams these days, business analysts even write acceptance criteria for stories directly in Gherkin well before discussing them with other team members.

But there is a lot more to BDD than Given/When/Then and Cucumber, and both can be misused. In this article, we will take a step back and look at the bigger picture, and learn why using Gherkin at the wrong time, or for the wrong purpose, may be holding you back.

Cucumber was never meant for test scripting

For many teams, the first time they come across the term “BDD” is in the context of test automation. They use “BDD” tools like Cucumber to write automated test scripts, most often after the development is completed.

Many testers love Cucumber. They find the format expressive and flexible, and the readable nature of the scripts makes them easier to understand and maintain. And this is fine. Teams should use the tools that work best for them.

But this is not where BDD gives us the most leverage. In fact, it’s not really BDD at all. The authors of Cucumber themselves are the first to point out that Cucumber is not actually a test automation tool, but a collaboration tool. If all you want to do is write high quality, maintainable automated acceptance criteria, then other tools may suit you better.

But the real reason that we say that Cucumber is not a test automation tool is not about whether it is fit for purpose. The real reason is that, if you are just using Cucumber for test automation, you are missing out on most of the benefits of BDD.

If you are just using Cucumber for test automation, you are missing out on most of the benefits of BDD.

Cucumber is a collaboration tool, and the big gains come from when you use it as such. Gherkin (and, indirectly, Cucumber) comes into its own when team members (business analysts, developers, testers, and, if you are lucky, product owners) use it as a way to share and challenge a set of very specific requirements. This collaboration is at the heart of BDD, and it is where the big benefits come from. We will look at how this works in more detail shortly, but for now, suffice to say that when a tester writes automated acceptance tests directly in Cucumber, after the work is finished, all the potential benefits of this collaboration are lost.

And Gherkin was never meant to be written alone

Now like anything else, Gherkin is no silver bullet. Writing acceptance criteria with Cucumber is great, if you do it at the right time and with the right people.

In many teams nowadays, business analysts write requirements using the Given-When-Then format. And it turns out that this practice is potentially just as harmful to BDD adoption as using Cucumber purely for test automation.

To be clear, when a business analyst writes detailed acceptance criteria in a JIRA card using a Gherkin or Gherkin-like format, they mean well. After all, they are trying to note down as much detail about the requirement as they possibly can. But the problem is, once again the benefits of collaboration are lost, and these acceptance criteria more often than not need significant rework before they can be automated.

So what’s a team to do?

Broad brushes and narrow brushes

When an artist sets out to paint a painting, they don’t start with the details - they start by sketching out the broad lines, using a charcoal pencil or a broad brush. Only when they are happy with the overall picture will they start working on the finer details.

Requirements discovery and definition is similar. It is like paining a masterpiece: you need to use the most appropriate brush at each stage.

Requirements discovery and definition is like paining a masterpiece: you need to use the most appropriate brush at each stage.

The value of Gherkin comes from the fact that it hits a sweet spot between rigour and accessible business language. But if you write Gherkin scenarios from scratch in a Sprint Planning meeting, with the whole team present, you run the risk of getting bogged down in the minute details of the format, and losing focus on the bigger picture. It’s not an efficient use of time. Gherkin should not be the only tool in your BDD toolbox.

A typical BDD team will use a range of tools, depending on the nature of the project and the stage of development. In a BDD process, we can identify several key phases, that repeat for each feature we work on:

• Discover
• Define
• Formalise
• Automate
• Deliver

At each stage, the most appropriate tools and techniques vary:

• Discover: Very early on, high level techniques like Story Mapping and Impact Mapping can help get an overall picture of what it is you are trying to achieve. Techniques drawn from Design Thinking are also an excellent way to get a broader idea of the problem you are trying to solve, and the solutions that might work. At this stage, the emphasis is on breadth, rather than detail.
• Define: as you get closer to discovering and defining features, you start to have more concrete conversations around more specific business rules and examples of how the user would interact with the system. At this stage, low-fidelity techniques such as Example Mapping, and Feature Mapping work well. These techniques are light-weight, fast and flexible, and you don’t get bogged down in the Gherkin syntax. Example Mapping is great for brainstorming business rules illustrated by concrete examples to keep it real. Feature Mapping is excellent for conversations around how a user interacts with the system to achieve a goal.
• Formalise: Once key business rules and examples have been identified through Example or Feature mapping, they can be formalised into Gherkin. This can be done “offline” by an engineer in test, often pairing with a BA or manual tester. Once they are ready, the Gherkin scenarios should be shared and discussed with the broader team.
• Automate and Deliver: During development, these scenarios will be automated; in a BDD team, a feature or story cannot be declared “done” until the corresponding executable specifications pass.

Of course these are only suggestions, like an artist, each team must choose the combination of brushes that works best for them.

Conclusion

Cucumber and Gherkin are not the only tools in the BDD toolbox, and using them at the wrong time, or in the wrong way, can sabotage your efforts to deliver higher quality, higher value software. So when you look to adopt BDD, make sure you think about both broad and narrow brushes.

We love helping teams adopt better practices! If you'd like to learn more about how we can help your team get the most out of BDD, be sure to take a look at our brand new Low Tech High Impact Sprint Planning workshop and our other BDD training workshops.