In the fast-paced and highly regulated world of financial services, software quality is arguably of utmost importance. To ensure financial products meet complex requirements and deliver seamless user experiences, robust testing methods are crucial. One such approach that has gained significant traction in the financial industry is Behavior-Driven Development (BDD) testing.
It has transformed the traditional testing paradigm by bridging the gap between business stakeholders, developers, and testers, fostering collaboration.
In this comprehensive guide, we’ll explore the depths of BDD testing highlighting its principles, benefits, and how it can be applied in the financial services sector to deliver reliable and secure financial systems.
In the traditional development process, stakeholders communicate their business requirements to the Product Owner (PO) or Business Analyst, who then prepares a business document containing user stories.
The development team uses this document to begin coding and designing the system, while the testing team simultaneously writes test cases. Once development is complete, the testers run regression cycles, and finally, the product is released into production after receiving QA sign-off and creating technical documentation.
However, this approach often causes a communication bottleneck, with engineers misunderstanding the business requirements and business professionals having limited insight into the technical capabilities of their team. This miscommunication and lack of collaboration then result in a software product that falls short of meeting the business requirements. This is where BDD comes in to bridge the gap.
In short, the BDD testing framework generates executable tests in natural language phrases that are easily comprehensible. The ultimate goal is to ensure stakeholders understand all aspects of a project without getting lost in complex code. In other words, the BDD testing approach empowers teams to create tests that depict the expected behavior of the system and users’ requirements.
In BDD terminology, the PO, QA, and Dev are often referred to as the ‘’three amigos’’. These individuals engage in discussion and collaborate with each other, raising questions and exploring various scenarios that meet the objectives of the project.
Once all the requirements are mutually agreed on, they’re then documented in the form of scenarios using an English-based format called Gherkin.
Each test is derived from a user story using the Gherkin Given-When-Then structure
For example:
Scenario: Make minimum due payment
Given user is on the pay credit card page
When the user fills in the details and selects the minimum amount option
And user clicks on the pay button
Then credit card confirmation page is displayed
Then the QA team takes the same scenarios and transforms them into either manual or automated test cases. This is where Cucumber comes into picture, as it provides a tool for running automated test cases based on the Gherkin scenarios.
In the context of financial services, BDD testing offers several benefits, including:
Nevertheless, BDD also has certain limitations that financial institutions should be aware of:
Having established a fundamental understanding of BDD testing and recognizing its significance in financial services, it’s crucial to delve into the procedural aspects of performing BDD testing.
In this instance, we’ll showcase the widely used Cucumber - Selenium - Java framework as a demonstration of BDD testing. The specific scenario revolves around accomplishing a successful login to a mobile banking app.
The Cucumber framework typically consists of three primary components:
In BDD, a feature is used to define a single functionality. These features are written using the Gherkin syntax, which follows the Given, When, Then logic. They’re stored in files with the ‘’.feature’’ extension, and these files contain information about the feature, including their description in plain language, the scenarios to be tested, and any relevant data required for testing the feature.
Feature: Login to the mobile banking app.
Description: The user should be able to log in to the banking mobile app by providing the correct username and password.
As a user
I want to log in to the banking app
So that I can process online payment transaction
Scenario #1: Successful log in to the banking app
Scenario #2: Unsuccessful log into the app
After defining the features in the feature files, the next step is to execute the code for the scenario. Step definitions serve as a repository for mapping data between the steps described in the feature file and the code that should be executed.
To establish the mapping, both Java and Selenium commands can be employed to associate the feature file with the executable code.
package StepDefinition;
import cucumber.api.java.en.Given;
import cucumber.api.java.en.Then;
import cucumber.api.java.en.When;
public class Steps
{
@Given(''^a user opens the mobile banking app$'')
//Code to open the mobile banking app and launch the login page to define the GIVEN step of the feature
@When(''^the user selects face scanning as the login option$'')
//the face authentication button is identified using the find element of the XPATH and is clicked to have the face scanned
@When(‘’^user face scan matches the registered face data$)
//the input for the face scan matches the registered face data. The WHEN step of the feature is being executed here
@Then (‘’^user gets directed to user profile$’’)
//Direct to the User profile of the application as a result of correct face scanning in the WHEN step. This would define the THEN step of the feature
To implement the BDD tests, a Test Runner File is necessary. In this case, a JUnit Test Runner Class is used, which contains the location of step definitions and other metadata required for test execution.
In Junit, the @RunWith() annotation is used to specify the test runner class that executes the tests. Meanwhile, the @CucumberOptions annotation is utilized to define various settings such as feature files’ locations, step definitions, step definition, reporting integration and more.
Test Runner Class within cucumberTest package, with the feature files are stored in the ‘’src/test/Feature’’directory, while the Step Definition files are located in the ‘’src/main/stepDefinition’’ folder.
package cucumberTest;
import org.junit.runner.RunWith;
import cucumber.api.CucumberOptions;
import cucumber.api.junit.Cucumber;
@RunWith(Cucumber.class)
@CucumberOptions(
features = "src/test/Feature"
,glue={"src/main/stepDefinition"}
)
public class TestRunner {
}
Its advanced automation capabilities offer several key benefits to financial services, including:
Feature: I want to login into the Internet banking with valid and invalid data
Background:
Given I navigate to the Internet banking
Scenario: Login as a new sign-up user with valid data
When I entered a valid credential
| email | validpassword |
| laurennb120@gmail.com | LRB94$
When the user clicks on the sign-in button
Then validate the title after login
Scenario: Login with invalid data by entering an invalid password
When I entered an invalid credential
| email | invalidpassword |
| laurennb120@gmail.com | LRB82#
When the user clicks on the sign-in button
Then error message should display
| errormessage|
| Authentication failed |
If you have a quality management platform, you can enhance its capabilities by integrating the Behavior-Driven Development (BDD) testing framework to create test cases. By incorporating BDD frameworks like Cucumber in tools like Katalon Studio, you can utilize test hooks that execute at the beginning and end of each scenario:
When it comes to BDD best practices, it can be overwhelming to navigate through numerous articles and conflicting advice. Hence, we’ve compiled a list of common mistakes that we often observe when working with financial institutions. These tips are organized into different categories to provide comprehensive coverage:
In the realm of financial services, it’s crucial to prioritize sensible, short features’ title and description. Lengthy feature descriptions tend to become tedious and can discourage stakeholders from engaging with them. To maintain stakeholder interest and ensure clarity, feature descriptions should be succinct, capturing the scope and context in a concise sentence.
It’s advisable to utilize a background for shared steps that are necessary in each scenario in your feature file. This can help you eliminate repetitive steps and prevent duplication across feature files. An ideal background length is no more than four lines.
Users tend not to think about the background when reading scenarios within the feature files so make sure you use something that’s very generic, such as Given the user has logged in.
Only apply tags to scenarios and features, and not to the background section. Additionally, it’s recommended to avoid using the background in feature files that contain only one scenario. In such cases, it’s more sensible to include the relevant details directly within the GIVEN step.
You should also avoid using both a before hook and a background simultaneously. This is because it can lead to duplication of context, with both the background section in the feature file and the before hook in the code serving similar purposes.
Tags play a crucial role in organizing features and scenarios within a BDD project. They provide a means to effectively filter specific scenarios or features, especially when feature files are spread across different directories.
For instance, if you have a collection of scenarios related to Gmail, you can employ the ‘’@mail’’ tag to mark those specific scenarios. This allows for convenient searching and retrieval of scenarios tagged with ‘’@mail’’.
Here are a few additional tips regarding the usage of tags:
The combination of Agile, test automation and BDD testing in the BFSI industry allows for the right product is shipped off in the right manner while accelerating product delivery timelines. Its use of natural language scenarios also facilitates effective stakeholder communication.
For optimal results, it’s worth considering having IT providers such as KMS Solutions to consult and assist financial institutions on tool selection and BDD testing implementation. Having 14+ years of experience in the industry, KMS Solutions in collaboration with Katalon - the leading automation testing platform have helped multiple companies, including Discovermarket, GIC, Maxis, Simplyhealth and more, in their digital transformation journeys. Feel free to contact us to have a free consultation where we can provide customized solutions for your business needs.