Performance, Load and Stress Testing

On a normal evening 800 people shop on Basketly at once. On the night before a festival, marketing expects 5,000. Checkout works perfectly for one tester clicking alone, but nobody knows what happens when thousands pay in the same minute. That is not a question functional tests can answer.

The rule

Performance measures speed; load tests the expected peak; stress goes past it.

Performance testing is the umbrella: measuring how fast and stable the system is. Useful measures:

• Response time, usually as a percentile: "95% of checkouts finish within 2 seconds" (the p95). Averages hide the slow unlucky users.
• Throughput: how many requests or orders per second the system handles.
• Error rate: the share of requests that fail.

Load testing runs the system at the expected busiest level, 5,000 shoppers for Basketly, and checks it meets its targets there.

Stress testing pushes beyond the expected level until something gives, to learn two things: where the breaking point is, and how the system behaves when it breaks. A good failure shows a clear "we are busy" message and loses no orders; a bad one charges cards twice or needs a manual restart.

Related variants: a spike test jumps suddenly from 800 to 5,000 users, and a soak test holds normal load for many hours to expose slow problems such as memory leaks.

The shortcut

Ask "Which number of users am I testing, and why?" The expected peak means load. Beyond the peak on purpose means stress. Any level, measured, is performance.

The trap is testing with one user and calling it performance testing, or reporting only the average. An average of 1 second can hide one customer in ten waiting fifteen.

Drills

Answer fast — trust the rule.

Remember

• Performance measures speed; load tests the expected peak; stress goes past it.
• Ask "Which number of users, and why?"
• Set targets first, report percentiles, and check how it fails, not just when.