← Back to Insights Quality Assurance

Load Testing: Securing Performance Before Go-Live

19 October 2026 · Ramin Amini

Everything works in testing, the business department has signed off – and on the first day after go-live the new customer portal becomes painfully slow. Functionally the software was correct, but it could not cope with real load. Load testing closes exactly this gap. This article shows how to plan and evaluate load tests so that they deliver reliable answers rather than impressive but useless charts.

What a load test checks

A load test examines how a system behaves under a defined, realistic number of concurrent users or transactions. The main measurements are response times, throughput, error rates and the utilisation of resources such as CPU, memory, database connections or network. The central question is: does the application meet its requirements when as many people work at the same time as expected in real operation?

Load tests are part of performance testing and therefore of non-functional testing. They do not replace functional tests but complement them: a function that calculates correctly for one user can slow down under a hundred concurrent requests because of database locks, exhausted connection pools or inefficient queries.

Load, stress, soak: the main variants

In day-to-day projects these terms are often mixed up. A clear distinction pays off in planning because each variant answers a different question:

• Load test: behaviour under expected normal and peak load. Does the system meet the agreed response times?
• Stress test: deliberately pushing load beyond the expected peak. Where is the breaking point, and how does the system behave there – in a controlled way with error messages, or with data loss?
• Soak test (endurance test): moderate load over many hours. Typical findings are memory leaks, log files filling up or slowly growing queues.
• Spike test: sudden, short load peaks, for example after a newsletter goes out or at the deadline of an application process.

Not every project needs every variant. An internal business application with a predictable number of users often gets by with load and soak tests; an online shop running promotions also needs spike and stress tests.

Step 1: Define measurable performance requirements

The most common reason for worthless load tests is a missing target. “The system should be fast” cannot be tested. Formulate performance requirements as precisely as functional requirements: which transaction, under which load, with which maximum response time and which acceptable error rate. Use percentiles rather than averages – for example “95 percent of all search requests are answered within a defined time” – because a good average can hide long waiting times for individual users.

The figures should not come from gut feeling but from the business side and existing data: access statistics from the legacy system, expected user numbers, seasonal peaks, contractual service levels. Capturing requirements properly avoids later debates about whether a test result is “good enough”. Our article The Underrated Success Factor: Clean Requirements explains how to get there.

Step 2: Build a realistic load profile

A load test is only as meaningful as the usage behaviour it simulates. A thousand users opening the same start page at the same moment tell you little about real operation. A good load profile describes:

• The most important use cases and their share of the total load – for example searching, viewing, ordering, exporting.
• Think times between actions, because real users do not click every millisecond.
• The timeline: gradual ramp-up, a plateau at peak load, a controlled ramp-down.
• Background load such as batch jobs, interface imports or reports running alongside interactive use.

Focus on the flows that are business-critical or generate a lot of load. A handful of well-chosen scenarios yields more insight than a script for every screen of the application.

Step 3: Prepare the test environment and test data

Results from an environment that is much smaller than production can only be transferred to a limited extent. Ideally, the load test environment matches production in architecture, configuration and scale. Where this is not possible, document the differences and take them into account when assessing results.

Test data matters just as much. A database with a few hundred records behaves differently from one holding several years of data. Plan for realistic data volumes and make sure personal data is anonymised or generated synthetically. Also clarify early how external interfaces are handled: real third-party systems usually must not be put under load and are therefore replaced by simulations.

Step 4: Execute and monitor

Tools such as JMeter, Gatling, k6 or Locust generate the load, but what you measure in parallel is decisive. Without monitoring at server, database and application level you only see that response times rise, not why. A proven approach:

• First measure a baseline under low load to have a point of comparison.
• Increase load in stages and observe response times, errors and resources at each stage.
• Document every run with version, configuration and data state so results remain comparable.
• After every optimisation, repeat the same test – this is the only way to prove that a change actually works.

Step 5: Analyse results and fix bottlenecks

A load test delivers measurements, not solutions. The real work starts with the analysis: do response times rise evenly or jump from a certain point? Which resource is saturated at that moment? Common causes are inefficient database queries, missing indexes, connection pools that are too small, missing caching, synchronous calls to slow interfaces or lock contention during concurrent writes.

The analysis should be done together with development and operations. The result is a report that clearly answers: which requirements are met, which are not, what risks exist for go-live, and which measures are recommended? This statement is the basis for the release decision by project management and the business department.

Load testing in agile projects

If you only run load tests a few days before go-live, there is hardly any time left to fix fundamental architecture problems. In agile projects, performance requirements should therefore be part of the backlog and the Definition of Done. Smaller automated performance tests of individual interfaces can be integrated into the CI/CD pipeline and reveal degradation as soon as it appears. The comprehensive load test with a realistic load profile remains a fixed milestone before major releases. Our article on regression testing describes how quality assurance fits into sprints in general.

Common load testing mistakes

• Testing too late: shortly before go-live you can only ease symptoms, not fix causes.
• Unrealistic scenarios: all virtual users do the same thing, without think times and with identical data – caches then make the results look too good.
• Overlooking the load generator: if the machine generating the load is itself overloaded, the test measures its bottleneck instead of the application’s.
• Reporting only averages: averages hide the long waiting times users actually complain about.
• Test once and forget: every major change can shift load behaviour. Load tests need repeatable scripts and a fixed place in the release process.

Conclusion

Load testing is not a box to tick at the end of a project but a tool to make risks visible early. With measurable performance requirements, a realistic load profile, a reliable test environment and a joint analysis, load tests provide a clear basis for the go-live decision. Read Why Quality Assurance Decides Project Success to see the role structured quality assurance plays overall.

Frequently asked questions about load testing

What is the difference between a load test and a stress test?

A load test checks whether a system meets the agreed response times under expected normal and peak load. A stress test deliberately pushes load beyond that to find the breaking point and to check whether the system behaves in a controlled way there.

When should a load test be carried out?

Before the go-live of a new application, before expected load peaks and after major changes to architecture, infrastructure or the database. In agile projects, smaller automated performance tests in the CI/CD pipeline complement the large load tests.

Which tools are suitable for load testing?

Widely used tools include JMeter, Gatling, k6 and Locust. More important than the tool are a realistic load profile, a production-like test environment and accompanying monitoring that reveals bottlenecks.