Cucumber was created as a tool to support teams using Behaviour-Driven Development (BDD). Teams that are practicing BDD typically use the Gherkin language (also known as Given-When-Then) to document the key examples of how their software should behave. They use Cucumber to execute those documents as Acceptance Tests and check their software’s behaviour against the documents.
Cucumber for Jira brings those Gherkin documents into Jira - the place where your whole team already works together.
Let's take a look at how you might build a simple application from scratch using BDD, Cucumber, and Cucumber for Jira.
Here we are, first day on a new project. We work for NorthSouth Rail. Currently our customers are able to buy their tickets in advance but they are not guaranteed a seat at busy times. In order to encourage people to purchase their tickets in advance the company would like to allow these customers to book their seats at the time they purchase their tickets.
This tutorial assumes you have a basic knowledge of using Jira and have already installed Cucumber for Jira on your Jira instance. |
Our team kick off with a workshop to make sure that we all understand what we are working on. We talk about the possibilities and what we need to get started and decide to start with three stories that we think will provide customers with a usable experience.
Allocate booked seats automatically
Indicate reserved seats in carriages
Customer chooses from available seats
Let's create a new project in Jira and add the stories to our board.
As we are a BDD team, our day-to-day work essentially consists of three practices:
Discovery: First, take a small upcoming change to the system – a User Story – and talk about concrete examples of the new functionality to explore, discover, and agree on the details of what’s expected to be done.
Formulation: Next, document those examples in a way that can be automated, and check for agreement.
Automation: Finally, implement the behaviour described by each documented example, starting with an automated test to guide the development of the code.
It’s time to get started so we pull our first story – Allocate booked seats automatically – into discovery.
To “do discovery”, we use a technique called example mapping that helps us to facilitate a Discovery Workshop. You can get a feel for how this works and learn more about it by watching this Example Mapping Webinar that focuses on this User Story.
At the end of this Discovery Workshop we have created the following example map.
We have discussed the user story – our yellow card – and everyone has pretty clear idea about what behaviour the seat booking system needs.
We have discovered three business rules – the blue cards – that we need to implement:
Ideally, do not book more than 70% of the seats in carriage
Don’t book more than 70% of the available seats on the train
Don’t split bookings across carriages
We have discussed some key examples of how the system should behave which they drew using a simple notation during the discovery meeting. These key examples will become the basis of our acceptance tests which we will Formulate in Gherkin.
We update our story issue in Jira to reflect this.
During our discovery workshop we spent a lot time discussing how the system should behave and we have uncovered some important domain language. As we are a BDD team we now take the time to write up those key examples as scenarios that are written in the language our business stakeholders understand.
One of the developers and one of the testers on our team take this task. You might have seen some teams where the Product Owner or Business Analyst is expected to write Gherkin scenarios but we have found that having members of the delivery team write the scenarios really helps to flush out any misunderstandings.
Cucumber for Jira gives us a place to start drafting our scenarios ready for feedback from the rest of the team. We start by creating a new Jira issue for the feature, label it with BDD_Feature and link it to the story issue.
We can now enable Cucumber for Jira on this issue.
This allows us to Create a feature file.
The developer and tester on our team pair on formulating these scenarios. They can write the feature file directly in Cucumber for Jira.
As the first step they outline the scenarios they need, and ask our Product Owner for feedback.
After some more back and forth and couple of edits to the file the team are happy with scenarios and ready to get started.
