The Tech Tales. From load testing to UI automation: inside the fintech QA process

In my most recent article, I talked about why QA is not just a fundamental part of software development, but why it’s absolutely crucial for fintech. 

QA ensures that the software product meets the end user's expectations and is free from errors and defects. When it comes to handling our clients’ money, errors and weaknesses are not an option. That’s why at OpenPayd, we follow the best QA practices to ensure that our software is of high quality and meets the required standards. 

In this article, I wanted to dive a bit more deeply into exactly what those practices look like.

Shift left testing

Let’s start with ‘shift left testing’, a software development practice that involves testing early in the development cycle, ideally at the beginning of each phase. This approach helps to catch defects early, which saves time and money by reducing the cost of fixing defects later in the cycle. At OpenPayd, we have integrated shift left testing into our software development process.

To support our shift left testing approach, we have implemented several automation solutions. One of these solutions is Provider Automation for testing the integration part of our applications. We work with a wide range of underlying providers to offer our customers the best possible financial products and services. These include banks, payment gateways, and other financial institutions. Integrating with these providers can be complex and challenging, which is why we use Provider Automation to test the integration side of our applications.

Provider Automation allows us to test the behaviour of different components working together as early as possible. By doing so, we can detect integration issues before they become more complex and challenging to fix.

To do this, we’ll simulate different scenarios and test the behaviour of our application when integrated with different providers. We will also test the performance of our integrations and ensure they can handle high volumes of transactions without any issues and that we are identifying and fixing defects before they become more complex and difficult to address.

UI and API Automation

Next, we have a UI and API Automation for testing client behaviours. UI Automation allows us to simulate user interactions with the application and test the UI functionality. It’s software that behaves like a user would when they’re using our services, but that allows us to run hundreds or thousands of tests much faster than testing with individual users. 

Similarly, API automation allows us to test the application’s behaviour in response to different API calls. By testing these behaviours early, we can identify and fix defects before they affect end-users.

Load testing

Another important aspect of our QA practices at OpenPayd is load testing. Load testing is a type of performance testing that involves testing the application’s ability to handle a specific load or number of users. By simulating heavy traffic or high user volumes, we can ensure that the application can handle these conditions without slowing down or crashing. This is especially important for applications that will be used by large numbers of users or for critical applications where performance is essential. Our user volumes can jump quite rapidly – some clients need to onboard a million underlying customer accounts within a few days, others will have just a handful of users. We have to be ready for those sudden changes in demand.

At OpenPayd, we use the tool k6 to simulate heavy traffic and test the application’s performance. We also use tools like Grafana to monitor the performance metrics of our applications during the load tests. This helps us identify any bottlenecks or performance issues that need to be addressed.

During the load tests, we measure various performance metrics such as response time, throughput and error rate. We also measure the number of transactions that can be processed per minute or hour. This information helps us determine the capacity of our applications and identify any potential performance issues that need to be addressed. By identifying and addressing any performance issues early, we can provide our customers with a stable and reliable platform for their payments needs.

Observability

Aside from automation, we also have certain observability solutions in place with Grafana and New Relic. Observability is the practice of gaining insights into the internal workings of a system based on its external outputs. By collecting and analysing data from various sources, we can understand the behaviour and performance of our applications.

Grafana and New Relic allow us to visualise data from different sources in a single dashboard, making it easy to identify any performance issues or blockers. We can also set up alerts and notifications based on predefined thresholds to ensure that we instantly know when something needs to be looked at. This helps us identify and fix any problems early on, allowing our applications to run smoothly and provide the best user experience possible.

Here in the OpenPayd QA team, we’re always working to bring our clients better software. The tools and principles we have adopted over the years have helped us to catch bugs early, reducing both costs and the time it takes to release new features. It’s these testing methods that help us ensure the OpenPayd platform stays reliable, stable and meets the financial needs of our customers.