A Complete Guide to BDD Testing in Financial Services

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. 

Why use BDD Testing?

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. 

What is BDD Testing?

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 

• Given (some context)
• When (event)
• Then (outcome) 

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.

Advantages & limitations of BDD Testing in financial institutions

In the context of financial services, BDD testing offers several benefits, including:

• Alignment of Business and IT: BDD promotes collaboration and alignment between business stakeholders and IT teams. It encourages effective communication, shared understanding, and collaboration, enabling business requirements to be translated into executable specifications. This alignment ensures that the software development process accurately reflects the needs and objectives of the financial institution.
• Improved Requirement Clarity: BDD scenarios use a business-readable language that enhances requirement clarity. By defining scenarios in a standardized format, BDD eliminates ambiguity and reduces the risk of misinterpretation. This results in a shared understanding of the desired behavior of the software, minimizing rework and improving overall project efficiency.
• Early Defect Detection: BDD testing facilitates early defect detection by promoting early collaboration and feedback. Scenarios are defined upfront, allowing potential issues to be identified and addressed early in the development cycle. By automating BDD tests and integrating them into the CI/CD pipeline, financial institutions can catch defects and regressions quickly, minimizing the impact on software quality.
• Faster product delivery: With BDD testing bridging the gap between business and technology stakeholders and can be automated, financial institutions can accelerate development with faster test execution and increased test coverage. 

Nevertheless, BDD also has certain limitations that financial institutions should be aware of:

• Potential for excessively tightly coupled behavior to arise from prolonged meetings among stakeholders and the necessity of involving all key stakeholders in the BDD process. 
• BDD relies on well-prepared software requirements to effectively articulate business requirements through Gherkin scripts. In fast-paced Agile environments where briefs are commonly used, ensuring the level of detail required for BDD scenarios may pose challenges.

How to perform BDD testing in Cucumber for financial institutions

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:

1. The Feature File

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

• Given a user opens the banking app on their phone
• When a user selects the face scanning authentication as the login option
• And the user scans their face using the device’s camera
• Then the user should be successfully logged into the mobile banking app

Scenario #2: Unsuccessful log into the app

• Given a user opens the mobile banking app
• When a user opts for face scanning option to log in
• And user scans their face using the device’s camera
• And the face scanning authentication doesn’t match the registered face data 
• Then the user shouldn’t be successfully logged into the mobile app

2. Step definitions

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

3. Test Runner File 

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 {

}

BDD’s advanced automation capabilities

Its advanced automation capabilities offer several key benefits to financial services, including:

• Create modular test cases by reusing common scenario steps: This approach is particularly advantageous for writing Regression Testing scenarios in the financial services domain. As financial institutions often have complex and interconnected systems, being able to modularize and reuse test steps enhances efficiency, maintainability, and coverage of regression tests.
• Parallel testing to accelerate test run times: The parallel testing capabilities of platforms like Katalon Studio, which support both sequential and parallel execution of Cucumber-based tests, are highly valuable. By dividing tests into shards and conducting them concurrently, financial institutions can significantly reduce overall test execution times, enabling faster feedback and quicker release cycles.
• Extensive use of Data Tables to store test data for automated execution: This capability proves highly advantageous, particularly in Regression Testing scenarios in financial services, as it allows for testing the scenarios with different data situations. This ensures stability and robustness of the financial system.

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 | 

• Allow for improved test coverage by linking business requirements in project management tools such as JIRA to test cases within the Feature File. This integration enables seamless mapping for user stories, including their unique IDs, directly to BDD scenarios. By incorporating User Story IDs from JIRA, BDD scripts establish a direct connection between business requirements and test cases, facilitating the creation of automated test scripts. 

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:

• Set the default package for step definitions.
• Build or add a feature file
• xRun your feature file.
• Define and link steps.
• Add your feature file to a test case.
• Upload and view BDD reports on Katalon TestOps. 
• View BDD report files generated from Katalon Studio.

Best practices for BDD testing

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: 

• Feature files
• Background
• Scenarios and steps
• Tags

1. Avoid lengthy descriptions 

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.

2. Keep the background short

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. 

3. Don’t tag the background

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. 

4. Points to consider for ‘’Tags’’

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:

• Deploy relevant tag names: for example, you can utilize tags like ‘’@daily’’, ‘’@hourly’’, or ‘’@nightly’’ to indicate the frequency of execution. Similarly, tags such as ‘’@todo’’, ‘’@wip’’ or ‘’blocked’’ can be used to denote the progress status of features.  
• Tagging features strategically: while tagging individual scenarios is common practice, there are situations where tagging the entire feature can be beneficial. For instance, you can use tags to associate a feature with a specific story number in a bug tracking system like JIRA, such as ‘’@Jira-story#PROJ-43’’. 
• Minimize unnecessary tag usage: If you have already tagged a feature, there is no need to duplicate the same tag for individual scenarios within that feature. This is because scenarios automatically inherit the tags assigned to their parent feature. By refraining from excessive tagging, you can prevent overcomplication of your feature files and maintain a streamlined and organized testing process.

Conclusion

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.