Documenting acceptance criteria as individual scenarios

Anti-patterns in BDD

Working with BDD can be a great way to increase collaboration and conversation between team members. It can help teams with their shared understanding and keep teams on track with their delivery. However, succeeding with BDD requires patience, teamwork and feedback - both on what works and what doesn’t work for your team.

Working as a team can be fraught with anti-patterns, whether they’re caused by biases, losing sight of common goals, or relying too heavily on tooling. In this series, we are looking at some of these anti-patterns, uncovering what they look like, how they are formed, and how they can be avoided.

In today’s article, we’ll dig deeper into the anti-pattern of documenting all acceptance criteria as individual scenarios.

Documenting acceptance criteria as individual scenarios

Imagine you are collaborating on the following user story:

Story: user registration
As a new user
I want to be able to register an account
So that I can access our products services

Acceptance criteria:

• Registration page contains a form with the following fields

• Email address

• Password

• Submit

• The email field must contain a valid email address

• The password field must contain at least one capital letter, lower case letter and number

• Submitting the registration page form will create a new account

The agile team begins to create scenarios after writing acceptance criteria and produces the following:

Given I am an unregistered user
When I navigate to the registration page
Then there is an email input field

Given I am an unregistered user
When I navigate to the registration page
Then there is a password input field

Given I am an unregistered user
When I navigate to the registration page
Then there is name input field

Given I am an unregistered user
When I navigate to the registration page
And I enter an email address
Then the email address must be valid

Given I am an unregistered user
When I navigate to the registration page
And I enter a password

Then the password must contain a capital letter, a lowercase letter and a number

The scenarios go on and on, with all the individual acceptance criteria captured as individual scenarios. We end up with feature files that contain long, boring scenarios that are hard to maintain.

Why is documenting all acceptance criteria as individual scenarios an anti-pattern?

Building scenarios with a one-to-one relationship to acceptance criteria is an anti-pattern because it leads to a challenge in maintaining overly long feature files. A large number of scenarios for one feature negatively affects value and team engagement, which is definitely not what BDD is all about:

• The volume of scenarios and their wording make it hard to appreciate the value of the feature.

• People are less likely to engage with scenarios in a meaningful way since there is so much to read.

Additionally, this approach leads to scope creep. While there will always be a chance that small individual criteria are missed during the analysis phase, the problem arises when they are picked up later, and the temptation is to add scenarios without discussing it with the rest of the agile team. Not only does this lead to scope creep, but it also creates a bias in the agile team towards turning scenarios into test cases which is an anti-pattern in its own right.

BDD best practice and anti-patterns - what’s the solution?

Focusing on how to create unique and engaging examples will help to resolve this anti-pattern and establish BDD best practice.

When we are in collaborative sessions we use examples as a way to share our ideas so that others gain more insight into our ideas. One of the powerful aspects of examples is that they can include many details in just a few lines. Referring back to our registration example from before, we can say:

"I would go to the registration page. Enter my name ‘Mark’, email address ‘mark.winteringham@hindsightsoftware.co.uk’ and my password ‘Passw0rd123’ before clicking ‘Register’. My account is then created and I can log in.

This example could then be translated into Gherkin syntax for future use, like so:

Given I am a new user of the product

When I register the following details