Embark on your 'BDD in Jira' journey with this introductory article, detailing the essentials of Behavior-Driven Development (BDD) and how the AssertThat plugin enriches your Agile practices within Jira.
Evolution of BDD and Its Impact
Learn how BDD, initially recognized for test automation, focuses on creating a unified understanding among Product Owners, Developers, and Testers to meet business objectives. Discover how AssertThat's features enable the construction of reliable automated tests to validate your product's key functionalities.
From Writing Scenarios to Agile Collaboration
Explore the transformation from writing BDD scenarios in Jira to creating a centralized, collaborative environment for all user stories, features, and examples through our "BDD Evolution with AssertThat" series.
BDD in Jira: A Three-Phase Approach
The BDD process moves through 3 phases. The process is iterative and is followed for each user story,
Discovery
Formulation
Automation
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.
Discovery phase
User stories will generally be of the format as shown below and written from the perspective of the customer’s domain:
Example:
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.
Formulation
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:
From the features page where all the scenarios are grouped within the feature.
2. On the Jira ticket where the scenarios can be added and linked to the user story from multiple features.
Writing good Gherkin scenarios
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
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.
Which scenarios do I automate?
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.
Acceptance test automation example
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
How are tags used to manage my features and scenarios?
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 Gherkin features with @Tags provides guidance and a number of options for how to manage your scenarios and features.
Free Trial
If you would like a free demo or trial then please click on the button below or get in contact with us at support@assertthat.com.
Comments