The solution was to be deployed to the Cloud and the Bank needed to gain confidence in its performance when subjected to the expected levels of load.
Our role
Our team worked with the project team at the Bank to identify a series of user journeys that made up the bulk of the anticipated load. When performance testing, there is often a need to select tests that are going to provide the most realistic simulation, without taking up too much time recording. We opted for the following:
- Secure registration
- Login and secure access
- View accounts, balance
- Make a payment to an existing payee
The security of the connection to the app was one of the areas where our team needed to work with external security services vendors, to allow our tools to pass the correct tokens to the application during the tests.
The process
User volumes and profiles of the required tests were agreed to provide an accurate simulation of the expected traffic on the application. This then correlated to the amount of data needed. The volumes needed to take into account an autoscaling feature, expected to be triggered at a certain number of concurrent connections.
Apache JMeter was used to record the scripts, as the user interface was web-based. A series of tests were run, representing normal and peak load, as well as a soak test over several hours, to check for any degradation over time.
It was proven that the system was able to cope with the anticipated spike in load, as new users went through the registration process. This was the equivalent of a significantly higher volume than expected once the application is taken to go-live.
All in all, the tests demonstrated the capability of the system to provide the key functionality of getting to the user dashboard, making payments, and viewing direct debits while under load.