P R O J E C T
Behavioural Testing in Insurance
A cloud warehouse solution for building business confidence in developer's calculations applied to large scale data.
B A C K G R O U N D
Working in a large insurance company with a large data warehouse, we had a number of business-critical calculations that were applied to large scale data. These calculations were often complex and required a high level of confidence in their accuracy.
To maintain this confidence, we needed a way to ensure that the calculations were correct and that any changes made to the code did not introduce any regressions. This is where Behavioural Driven Development (BDD) testing came in.
BDD testing is a software development approach that focuses on the behaviour of the system rather than the implementation details. It allows us to define the expected behaviour of the system in a way that is easy to understand and maintain.
Feature: Health Insurance
Scenario: Customer applies for insurance with valid documents
Given there is a customer named "Abigail"
And Abigail has a valid ID
And Abigail has a valid proof of address
And Abigail has a valid proof of income
When Abigail creates application "HI Application A" for health insurance
Then HI Application A's status should be "approved"
Scenario: Customer applies for insurance without valid ID
Given there is a customer named "Barney"
And Barney has a valid proof of address
And Barney has a valid proof of income
When Barney creates application "HI Application B" for health insurance
Then HI Application B's status should be "denied"
And HI Application B's reason should be "Missing ID"
And Barney should receive a notificationT E C H N O L O G I E S
C H A L L E N G E S
One of the largest hurdles to creating a common business focused language is getting the ground work right. This involved extensive collaboration with business stakeholders to understand their needs and translate them into technical requirements.
Once the base understanding is made the technical team can often derive more nuanced requirements by modifying the existing established language.
If the technical implementation of the plain english is not flexible enough to apply to the different contexts the business may apply it to. Then it can cause performance slow downs while also causing losing the hard earned trust of the business in the flexibility of the codebase entirely.
As all tests are defined in plain English, it is clear and simple to communicate what aspect of the code isn't working when a failure occurs. However, when everything is running smoothly it is hard to configure the test reporting to properly communicate every area of the business and the significance of each test.
P R O J E C T
O U T C O M E
We successfully implemented a robust test suite in the existing codebase ensuring that scripts are tested for quality.
The new approach built trust with the business to have confidence that the code was robust and aligned with business goals.
The common language used to define acceptance criteria improved communication between business stakeholders and technical teams.
P E R S O N A L
G R O W T H
This project taught me the highlighted how important the quality of communication between teams is. Not just the quantity of communication but the effort to understand the world from their perspective and to speak in their terms.
I have learned that the trust built with the business is always in flux and that it is important to spend energy maintaining that confidence through a high level of quality in the codebase.
I have learned that simply testing brings business value in code stability. However, to reach a new summit, having the business review and derive meaning from the tests provides further value still by having a shared living specification that can change with the business requirements.
