top of page
Friends

How to use BDD to write effective acceptance criteria!

by Chris Lewis (2 minute read)

‘Are you thinking of using Behavioural Driven Development (BDD) for acceptance criteria or just curious? If the answer is yes, then read on!

Acceptance criteria are used to check if project requirements are complete. BDD supports project requirements with the creation of effective acceptance criteria, early in the process. I believe acceptance criteria creation shouldn't be a solo activity. I like the way BDD empowers the team and brings efficiency to the development life cycle. Some more information and reasons to use BDD follow:

​​

1. It is collaborative

Team members work together to understand each other's views in a method called 'the three amigos'. In this technique, team members that represent different views come together to discuss and agree on acceptance criteria. Traditionally it involves the tester, the developer and the business analyst. For me, the key factor is that the acceptance criteria are the result of more than one person's perspective.

​

2. It has structure

BDD uses a standard format called a gherkin. This plain English format supports productive discussions during creation. The format is: Scenario <the header> Given <the context> When <the event> Then <the outcome>

An example of the user story and associated example gherkin is:

As a library user, I want to be able to borrow a book so that I can read it outside the library

​

An example of BDD is:

Scenario Taking books out the library

Given I have a library card

And it is not expired

When I present a card to borrow a book

Then I am allowed to take it from the library.

​

3. Testing considered at the start

It is easier and cheaper to fix issues the earlier they are identified in the project process. The BDD structure provides a base for the consideration of manual and automated testing early. It can also be enhanced to handle different variants of test data inputs with the association of data tables (also known as Quality Assurance Tables). It will take time to get used to, but it is worth it! It can take time for a team to be comfortable in the use of BDD. In my experience, the difficulty is often due to the user story. For example, the user story is not small enough. My BDD journey was difficult at first, but it was worth it!

​

Continuing your journey

There are lots of tools and blogs available to support BDD. I have used 'BehavePro' and 'XRay'. A link to an online BDD article I used from Dan North is here.

​

#BDD #BehaviourialDevelopment #Agile

bottom of page