BDD Is Not About Test Automation.

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 many things in agile, it can be tricky to implement.

Here are a few tips that can help you get it right:

1) Don’t put Given..When..Then in your story definitions. This is a common habit, but it’s almost always ineffective. In fact it’s worse, and the earlier you use the Given..When..Then, the worse it is. Gherkin should record the understanding that emerges from a conversation, not dictate a narrow view of the requirements.

2) Don’t write Gherkin test scripts. Gherkin is designed to represent requirements in an executable format, NOT traditional test scripts. (That said, if you try to automate manual test scripts directly in ANY coding language, you will run into trouble). Automate your requirements, not your test scripts.

3) Involve the entire team in the BDD process. BDD is at it’s heart a collaborative approach and it’s important to involve all team members, including developers, testers, business analysts and stakeholders in the conversation to ensure that the requirements are well understood and accurately represented in the Gherkin feature files. Remember, the Gherkin scenarios (if you choose to use Gherkin) are the OUTPUT of the conversation, not the input.

4) Start gradually. If you are new to BDD, try applying BDD to a couple of stories in a sprint, or just focus on the requirements discovery aspects first (these alone can give you some great quick wins in terms of alignment and shared understanding). And as your confidence grows, expand to more stories and automating your acceptance criteria.

I’ve seen BDD work wonders on team performance when it is done well — it’s a simple approach, but simple isn’t always easy. If you can find the right mix for your team, though, the results won’t disappoint.