This article describes the basics and background to BDD to help you get started, and describes how AssertThat’s features and functionality support your implementation.
BDD has evolved over a number of years and is commonly associated with test automation. However the primary goal of BDD is to gain a shared understanding between Product owner, Developer and Tester, leading to successfully achieving the business goals. With that said, why wouldn’t you use these example specifications (Features and Scenarios) to build reliable, automated tests to prove the key functionality of your product?
Our previous article in the series “BDD evolution with AssertThat” outlines the journey from writing BDD scenarios in Jira to today where all the users stories, features and examples are in one place to support the conversations required to gain that shared understanding. Agile and BDD is about the people and the conversations, however having the right tools designed specifically for BDD will help you along your journey.
The BDD process moves through 3 phases. The process is iterative and is followed for each user story,
Each user story will iterate through the 3 phases adding a small piece of business value with each cycle. The rapid iterations will enable your business to quickly gain feedback on the changes, informing the next set of user stories for development.
User stories will generally be of the format as shown below and written from the perspective of the customer’s domain:
Feature: feature name As a <type of user> I want <some goal> So that <business benefit / goal>
Feature: Filter scenarios in Jira using tags and feature name As a tester I want to be able to filter what scenarios are on display from within a feature So that I can quickly and easily manage and update my scenarios and features from within Jira
You may or may not be provided with some high level Acceptance criteria at this stage, which can provide a useful starter, for example:
Should be able to filter by tag
Should be able to filter by scenarios name
Should be able to filter by more than one tag
Filter by tag should use logical Or operator
At this stage I wouldn’t recommend writing the scenarios in Gherkin syntax – Given, When, Then. The primary objective of this phase is to gain a shared understanding of user story with clear examples.
There are a number of different techniques that can be employed to help with this process. Getting it right will ensure the remaining phases are straight forward and without surprises.
The process will drive out any ambiguity or questions that need clarification, and highlight what the high priority examples are for the user story.
There are a number of techniques that can be used to drive out concrete example specifications, which are well documented e.g. example mapping and feature mapping.
If you have read this far you will understand that the primary goal of BDD is to get a shared understanding; automation will follow. We can now start to write example specifications (Features and Scenarios) for each example identified in the Discovery phase. The specifications are written in Gherkin syntax using business terms, this ensures:
The entire team can review the scenarios and confirm it aligns with their understanding from the Discovery Phase.
The examples can be used directly for Automation
It follows therefore that the features and scenarios should be clearly presented and easily accessible as opposed to being buried in source control. AssertThat’s BDD plugin provides a number of features to support the Discovery phase:
Scenarios and features are clearly presented and linked to each user story in Jira. This ensures you have a single source of truth for easy access and verification by the entire team
Bulk update tools to manage and refactor your scenarios as they grow in number.
Gherkin syntax validation, and Manual / Automated flags to ensure the scenarios are ready for automation
Step autocomplete to minimise rework and duplication.
The Gherkin scenarios can documented in 2 separate locations within the plugin:
If your Discovery phase has gone to plan, the terms and language required to write the specifications will be clear. The AssertThat plugin provides the tools to ensure your Gherkin scenarios have the correct syntax, yet writing scenarios that survive the test of time will take a number of attempts.
I have included some pointers as regards writing Gherkin scenarios further down in this article, however my number one recommendation is to make a start. You will learn quickly what works and what doesn’t work after you have been through a few cycles. Keep the feedback loops as short as possible and look to improve on every cycle.
Some common pitfalls when writing Gherkin scenarios, and tips to ensure your scenarios are easy to read and automate, can be found below:
Best practice for organising your Features and Scenarios
Focusing your scenarios - https://cucumber.io/blog/keep-your-scenarios-brief/
Tips to make your Gherkin scenarios easier to read and automate
Automation is described as the final phase of BDD. However the specification and automated tests will continually evolve over time and require refactoring as new functionality is added.
So to recap, we’ve had a discovery phase to develop a shared understanding between our Product Owner, Developer and Tester. We’ve taken the output from this and written a specification using common language and terms which we all understand. We will now take our specification and turn it into Automated tests.
Following the BDD Discovery phase, it should be clear which are the high priority scenarios, and happy path flows through the user story. These scenarios are the ideal candidates for Automation.
The AssertThat plugin provides a flag to identify if the scenario should be Automated or tested Manually. Although it’s not necessary to flag the scenario as Automated to download the feature file into your automation framework this is the default setting.
We’re now ready to start automating our first scenarios. For this we’ll need to download our features from AssertThat to our test automation framework and start developing our tests. A detailed example of this process can be found here, which walks through the following steps:
Download features flagged as automated to your Test Framework
Write your acceptance test code to check for a feature which doesn’t exist
Write production test code to make the test pass
Refactor the production test code and the acceptance test code so that it passes
Over time your features and scenarios will grow significantly, however this can be managed by careful use of tags and naming.
Tags have many uses with scenarios and features and, used correctly, can provide a range of information to control execution, group functionality and execution priority. The article Organising your features with @Tags provides guidance and a number of options for how to manage your scenarios and features.