top of page
  • Writer's pictureNick

Introduction to BDD in Jira with AssertThat

Updated: Jan 26

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:


  1. From the features page where all the scenarios are grouped within the feature.

Illustrative example of BDD in Jira using the AssertThat plugin
Streamline your BDD in Jira with AssertThat's integration features for effective Agile testing.

2. On the Jira ticket where the scenarios can be added and linked to the user story from multiple features.

Screenshot of the AssertThat plugin's issue view screen in Jira, displaying scenarios alongside the user story, illustrating native integration
Seamless Integration: The AssertThat plugin in action within Jira, showing user stories and scenarios on the same page.

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.


688 views0 comments

Recent Posts

See All

Comments


bottom of page