BoomBet

Download PDF

Experience the convenience and excitement of sports betting

BoomBet is one of Australia’s oldest online bookmakers that has both Web and Mobile based responsible Betting Application enabling end-users to participate and place bet on various Races, Sports and Other Games. Below are the Challenges, Solutions and Outcomes shortly referred as CSO.

Boombet
  • Name: BoomBet
  • Domain: Online Sports Platform

Taking a step-by-step approach to addressing issues Problem brief to be resolved

Melbourne Spring Racing Carnival is a busy time for BoomBet, with a large number of users and bets.

QA Case Study
  • To test the performance and robustness of their betting application and its associated modules during this peak period.
  • To ensure high availability and reliability of their APIs and web-based application modules

Accomplishing the intended results

  • The performance testing exercise was conducted in two rounds.
  • The first round involved testing the application on the existing environment, while the second round tested the application after fixing identified issues and implementing other changes
  • The tests were conducted on a production replica environment using the K-SPARC performance testing framework.
  • Performance test assets were created using JMeter for both the API (13 APIs) and the web-based (9 scenarios) components of BoomBet.
  • Baseline tests were conducted for both the API and web modules at different load levels using Redline13, with infrastructure monitoring using Azure Application Insights.
  • The test results were analysed for performance issues and benchmarked.

What we achieved

We were able to deliver below features to client without any miss and within given time:

  • The APIs being tested were able to handle up to 3000 virtual users (vUsers) without issue, but started experiencing timeouts at 5000 vUsers.
  • The web module was not able to scale to 1500 vUsers due to timeouts caused by the third-party GenerationWeb (GW).
  • The response time of the APIs increased when the GW started timing out.
  • The app and database servers were not under significant stress and had capacity to handle more load.
  • The business calls and queries did not show significant degradation.
  • The next round of testing will take place after the timeout issues and architectural changes have been addressed

Explore an ingenious approach to software testing.

Let's begin.

Get in Touch with us

Consent(Required)