Load testing. Test before users do it for you

Which type of testing is more important? Modular testing checks business logic, functional testing checks interface behaviour, A/B testing checks user preferences, integration testing checks component interaction, and penetration testing checks the system's ability to withstand external threats. Here, errors often appear immediately after release and rollout.

However, performance issues often remain hidden until the first serious load. They are only discovered when real user traffic comes to the new version of your website or application, which either the software part of the project (database, application server) or the hardware infrastructure (insufficient RAM or disk subsystem overload).

That is why, for us at Emat EOOD, load testing is a key, essential and, at the same time, the most difficult stage in preparing a software product for launch to users.

Peak traffic
What would happen if a thousand users visited the website at the same time within three minutes? How many operations per second can your shopping cart handle? Where will the database and task queue start to ‘break down’? How does the system respond to a failure of one of the services in the chain?

A service that previously worked without problems can ‘crash’ even under a light load. This is because the amount of data has increased and the logic has changed during the service's operation.

Most often, load testing is not considered or is only remembered a couple of weeks before something important: Black Friday, a large-scale promotional campaign, or an email campaign. In this case, the goal of load testing is not to ‘load to the maximum,’ but to assess the limits of the system's performance. Emat company specialists recommend doing this in advance.

When everything ‘seems to be working’
The application or website is functioning, everything launches and opens without errors, but the interface slows down, and users leave without completing their session. This is where load testing comes in handy.

In this case, Emat EOOD Bulgaria recommends starting load testing with standard scenarios: login, product viewing, filtering, order placement. Then we increase the load and observe when the response time starts to increase. Most often, this is an unobvious ‘bottleneck’, a specific point. For example, a heavy SQL query or suboptimal cache performance. An external service that cannot handle frequent requests. Or a front end that lacks image caching.

Launching a new system or migrating
It is better to test new infrastructure in a safe environment rather than in production, thoroughly and in advance. Every change in architecture, migration to Kubernetes, database transfer, cloud or stack change is a potential risk.

Load testing emulates user actions. During such testing, Emat specialists increase peak activity and analyse how the system copes with the load. We create test scenarios using real access logs from previous weeks. We clean them of requests and leave key user actions. Such testing simulates 90% of user behaviour and allows us to identify possible failures before the system goes into production.

AI in load testing
AI systems detect anomalies in real time, analyse user behaviour, build activity models, and suggest test scenarios themselves. Such tools are already capable of not only sending a stream of requests, but also simulating real user scenarios, taking into account time, sequence of actions, and even behavioural patterns. For example, the system can ‘understand’ that the average user first goes to the catalogue, then applies a filter, opens 2–3 cards, and only then adds the product to the basket.

Cloud load testing
Today, to test a system for 50,000 virtual users, you don't need to rent racks in a data centre — just a couple of clicks in k6 Cloud, Azure Load Testing or similar solutions. Cloud tests allow you to flexibly scale the load, run simulations in different countries, take network delays into account, and even test the behaviour of CDNs and load balancers under real conditions. What used to take weeks now takes hours.

API load testing
Users may not visit your website and only use the mobile app, generating hundreds of requests to your backend API. The product interacts with external systems, third-party services, widgets — and all of this is built on the API. Therefore, API load testing is no longer an optional extra, but an essential part of engineering culture. Testing not only functionality, but also fault tolerance and scalability.

Test the load before users do it for you!
Load testing checks the readiness of a software product to work in less than ideal conditions, evaluates throughput during peak load periods, and detects errors.

Emat EOOD develops specific testing scenarios in collaboration with the customer's team. To do this, we use one of our internal load testing frameworks (internal load-testing-as-a-service frameworks). We actively use asynchronous workflows, running them in the background.

If the customer wants to conduct load testing but cannot formulate clear criteria, we analyse the web server's access logs, for example, for the last month, remove requests for static files from them, and create a set of scenarios that simulate user behaviour with tests.