So your company won’t purchase a Jira app to help with BDD...

There are many apps on the Atlassian Marketplace that can help with BDD, they all come with different features, price points and security considerations, but some find that even for the cheapest solution their company isn’t prepared to pay.

Often this is caused by a psychological issue around Atlassian licensing for Apps - if you need an App for 10 users but you have 1000 users in Jira then you have to purchase 1000 users for the App. This licensing causes a feeling of over paying for an App however, the vendor is likely to have priced this consideration in, and would likely charge a different price for true per seat pricing.

So what alternative setup could you use with Jira?

The key benefit of BDD is building a shared understanding about a User Story before development begins by discussing examples of how the system or software is meant to behave. You can also capture the examples to create an executable specification using Cucumber or SpecFlow and publish this as documentation. This requires collaboration and conversations between the Product Owner, business stakeholders, developers, testers, etc. for BDD to work well and makes Jira a natural hub for this.

It would be tempting for a team to write Given When Then (Gherkin) scenarios/examples directly into Jira issues but I would advise against this. For one Jira can’t syntax highlight Gherkin so there will be no support for writing it, but more importantly to enable Cucumber or SpecFlow to create the executable specification the scenarios would need to be stored in the teams git repository.

This duplication of scenarios between two different locations will present a problem, as the gherkin examples evolve and change who updates them in the other system? Which one is the source of truth when they disagree? Where should the business look to see how the system is intended to work?

I would always recommend storing the Gherkin scenarios in source control, make this your single source of truth, and you can even add Jira issue keys. This is what the more advanced BDD apps for Jira such as Behave Pro do - store the Gherkin scenarios as a git repository and allow them to be accessed and edited from Jira.

Storing them only in source control does present a problem, how does the business access them? Cucumber and SpecFlow can both generate HTML reports and these can be published to an internal website for the business to access. The reports are a little simple and a little clunky to use, and a more advanced option would be to use Serenity to generate a more functional documentation website.

If the product owners and business stakeholders are involved in BDD but you are also automating using Cucumber, SpecFlow or another BDD automation tool, I would recommend only capturing the Gherkin in one place and that should be source control rather than Jira.

This solution does mean conversations would need to be captured directly in source control instead of Jira, but if you currently use a technique like Example Mapping or Feature Mapping for user story discussions I would capture a screenshot (if remote or WFH) or a photo of the sticky note examples from the  example mapping session and attach those to the Jira Issue until the Gherkin is written up in source control.

I do receive comments that a solution like this does use small amounts of time to maintain and use, but that is part of the trade-off. Tools are meant to save time for team and individual members, the decision of what tools to use or pay for usually comes down to how much time is willing to be sacrificed.

To get a demo of Behave Pro and our Git please book a meeting, or sign up for an evaluation on our marketplace listing.