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:
- Better communication and collaboration
- Shared understanding
- Less ambiguity
- Executable artifacts
- Living Documentation
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.
SDLC without BDD
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.
Following a BDD approach
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.
- They speak through examples
- Discuss how the features will behave in different situations
- Build rules around the expectations
- Come up with a set of working examples for the features.
Through this process, all stakeholders understand the requirements and how they should behave in various situations. The examples will become scenarios in BDD.
Documenting in Gherkin and Domain Specific Language
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:
- Given - is a precondition or current state of the system
- When - is the action which happens on the system
- Then - is the outcome of the event that happened on the ‘When’ step
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.
How to map user stories using BDD
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:
- Customer searched for a product in the application
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-
- Customer adds product to the cart
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 in test automation with Cucumber
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.
Testing in BDD with Xray
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. With Xray, you can take advantage of BDD and write scenarios without leaving Jira.
