Load testing is a type of performance testing that evaluates how a system behaves under a defined workload, typically modelled on expected or peak production usage. Its primary goal is to determine whether the system can respond reliably, consistently, and within pre-defined performance thresholds when multiple users interact with it concurrently. Those thresholds expressed as Service Level Objectives or explicit acceptance criteria, must be agreed before the test runs. Without them, a load test produces observations, not pass or fail signals.
Unlike stress testing, which pushes a system beyond its limits to identify breaking points, load testing operates within anticipated demand boundaries. It answers a focused question: does the system perform acceptably under the conditions it is expected to handle?
A load test is only as meaningful as its workload model. This includes not just concurrent users or requests per second, but also the shape of the load: whether traffic ramps gradually, remains steady, or follows realistic production patterns such as a diurnal curve. Representative user journeys, think times, and session durations all matter. Wherever possible, the workload model should be derived from production traffic data or analytics rather than assumptions, this is one of the most consequential decisions in the entire exercise.
Load testing measures response time, throughput, error rate, and resource utilisation across application, database, and infrastructure layers. It helps identify bottlenecks, slow dependencies, memory pressure, and scalability limitations. However, load tests reveal symptoms, not root causes. Diagnosing failures requires supporting telemetry metrics, distributed traces, logs, and profiling data collected during execution.
The reliability of results also depends heavily on environment fidelity. If the test environment differs significantly from production in topology, configuration, data volume, or external dependencies, the conclusions may be misleading regardless of how well the test itself was designed.
Effective load testing examines how performance degrades as demand increases, how the system recovers when load subsides, and whether user experience remains within acceptable bounds throughout. These behaviours matter as much as whether the system survives the load itself. Where tests involve sustained load over extended periods to observe memory growth or gradual degradation, this moves into the adjacent practice of soak testing, which carries its own distinct objectives.
Load testing sits at the intersection of development, operations, and architecture. In organisations where ownership is unclear, it tends to be performed poorly or not at all. Treating it as a shared responsibilityoften under a performance engineering or site reliability function,, significantly improves both the quality of the tests and the organisational response to findings.
In mature engineering organisations, load testing is not a one-time pre-release activity. It becomes part of continuous delivery pipelines and ongoing system health monitoring as systems change and user behaviour shifts.
