Behaviour-driven development, also called BDD, is a methodology that involves developing software through examples and provides collaboration between different stakeholders on the team. Stakeholders on a SDLC team are a mixture of technical and non-technical people.
BDD encourages all team members to work closely using a common, non-technical language to set the expectations and behavior of a feature. Because of BDD, they share a common understanding of the work that they have to deliver. Collaboration and communication clear any ambiguity, misunderstandings, and differences in opinions among the team.
You can expect these benefits from BDD:
In this post, we’ll go over the process of BDD, how testers can map user stories using BDD, and, finally, how you can automate testing in BDD using Cucumber.
In a traditional SDLC without BDD, the business analyst, developer and tester work independently. This process leaves a high chance of miscommunication around understanding the requirements. The developer will have one understanding and based on that, the application will be developed. While the tester will design test cases based on their own understanding.
At the end of the project when the application is delivered it might have deviated from what the client expectations and needs — which is costly to fix.
When you adopt BDD you can avoid such miscommunication and ensure that everyone involved in the SDLC knows the requirements and expectations of the client.
As shown in the diagram below, the three amigos are the business analyst, developer, and tester. At the start of a project, they meet to discuss and elaborate on the requirements using examples.
Through this process, all stakeholders understand the requirements and how they should behave in various situations. The examples will become scenarios in BDD.
Once every stakeholder has a shared understanding, they must document every scenario that they agreed on. The structured way of writing them is known as Gherkin Language. Gherkin provides a set of keywords, they are:
These keywords are also often referred to as Domain Specific Language (DSL). With BDD Domain Specific Language, the team writes down the scenarios using the language that is known to them in a structured format and defined terminologies. This way, everyone is clear about what they want to achieve, and there is no room for confusion.
Let’s look at an example of BDD in action. Assume that the new feature is going to be an “Add to Cart” functionality of an e-commerce application.
The three amigos (business analyst, developer, and tester) discuss what that feature is and how the feature will behave in different scenarios. They will take different examples and see how the feature will behave in each case. These examples will be the scenarios for developing the feature. Once they agree on each case, they will “formally” write down different scenarios - which are the examples.
First, they will decide on pre-requisites/pre-conditions/current systems. For example: to implement the ‘Add to Cart” feature, they come up with the following prerequisites:
So that goes to the Given statement of the example:
Given a customer has searched for a product
Now that they have to decide on actions associated with the scenario-
It can be written using When statement as below:
When customer adds product to the cart
Finally, the team identifies the outcome of the action and described them with Then:
Then customer should be able to see the shopping cart updated with the product name
And the product quantity should be 1
If you see here, there is a keyword And used in the Then example. The keyword And is used when there are more steps for a specific type (Given, When or Then) instead of using:
Then customer should be able to see the shopping cart updated with the product name
Then the product quantity should be 1
Note that every Then statement must be an assertive statement, i.e. must use the keywords such as should, should not, etc.
There will be many such scenarios based on their discussion, and all of them will be documented in this format. This gives a good overview of what to implement.
BDD fits well with test automation because the scenarios created by the three amigos can be put in a feature file and used for automation. The technical people on the team can implement each scenario in the tech specification files.
After the development of the feature, the feature files can be executed and that generates test reports which will not have any technical details or codes but contain the scenarios that they have executed.
Business analysts can easily cross-check if something is missing from the feature developed since they can easily understand the language.
There are many automation tools/frameworks that enable BDD in test automation, and Cucumber is one of the popular. You can use Cucumber in test automation and apply BDD in an effective way.
Because of its non-technical nature, you can adopt BDD in your whole team with a small learning curve. BDD can easily be adapted to test automation, as the tests will use the same scenarios written by the business analyst, developer, and tester. The testing team can design and implement the tests and save time and effort.
Xray supports Gherkin based frameworks including Cucumber, Behave, Serenity and SpecFlow. That way, you can take advantage of BDD and write scenarios without leaving Jira.