Load vs stress testing

Load testing and stress testing use the same tooling to ask opposite questions. A load test applies the traffic you expect — a normal Tuesday, or the busiest hour you have forecast — and asks whether response times and error rates stay inside what you promised. It is a verification exercise with a pass or fail attached. A stress test deliberately exceeds that level until something breaks, and its purpose is to discover the breaking point and the manner of the collapse. It has no pass condition, only findings.

The second question is usually the more valuable one and is far more often skipped. Knowing that the system serves the expected load tells you nothing about what happens on the day it does not: whether it degrades gradually or falls over instantly, whether it recovers by itself when the traffic subsides, whether the database or the queue gives way first, and whether the failure of one component takes the rest down with it. A system that handles four times its forecast but never recovers without a manual restart is a considerably worse position than one that slows down honestly at twice.

Related exercises worth distinguishing

• Soak testing, which holds an ordinary load for hours or days and is the only reliable way to surface memory leaks, connection exhaustion and storage that fills quietly.
• Spike testing, where the traffic arrives suddenly rather than ramping, since autoscaling that copes with a gradual climb frequently does not cope with a vertical one.
• Capacity testing, which steps the load up in stages to establish the level a given configuration supports, and is what an infrastructure budget should be argued from.
• Recovery observation after any of the above, because how the system returns to normal is a separate finding from how it behaved while overloaded.

Results are only meaningful against production-like data volumes: a query that returns instantly over ten thousand rows and unacceptably over ten million is a defect no load profile alone will reveal.