5 reasons to use BDD to write effective acceptance criteria
October 2019 Chris Lewis
‘Behaviour Driven Development’ also known as ‘BDD’ is a great approach for effective acceptance criteria. Some may think it is solely for the technical bods, but it can be used effectively by everybody in a project. This post lists my top five reasons why I use BDD.
1. Completes a user story
An effective user story should have everyone in the project team aligned with what it means. To complete the user story acceptance criteria is essential as a reference for successfully completion and the foundation for tests.
2. Supports consistency
A great way to ensure acceptance criteria is consistent in the way it is captured. I think we can all appreciate that the earlier an issue is found the cheaper and more convenient it is to deal with. A consistent approach improves the communication and identification of issues earlier.
3. Involves different role perspectives
I am a great believer of the involvement of all project team members up front and align in understanding.
An amazing developer and the senior business analyst introduced me to the world of BDD (Behaviour Driven Development). They highlighted a way that you would only need to write effective acceptance criteria once, a proven method was used successfully used by many organisations. This method potentially avoided the developer rewriting acceptance criteria when he received acceptance criteria from the business analyst so his development team could work on them.
Acceptance criteria should not be processed and completed as a solo activity. It is more fun and effective with friends😊. My focus has always been making sure the team is aligned and make sure you are on the project journey together. This is way I liked the BDD collaborative ‘3-amigo approach’ where different perspectives work together to create and align on acceptance criteria.
4. Uses an intuitive format
BDD is based on the behaviour to an event and written in a way that makes sense regardless if you are technical or not. When I looked at an example, I loved the way it was written in a plain English format and learned in fact designed to be understood easily by the different types of people. I have had the privilege to meet more and more people who used it, they all said it was a bumpy ride at first, but so worth it in the end. Like all methods Agile or otherwise, things can be implemented wrongly! The following is an example of the format in relation to a user story:
A user story:
‘As a library user I want to be able to borrow books so that I can read them outside the library’.
Given < the context>
When < the event>
Then <the outcome>
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 can take it from the library
5. Validates a user story
If a BDD is too difficult to write it is a trigger for me to have a look at the user story in case. Typically it may not be small enough or not clear enough.
There are many tools available to support you in the creation of gherkins and more. For example, checking your syntax or supporting the software in the automatic generation of partial code. BDD can also be used as the foundation of automation testing.