Key takeaways
- Stress testing pushes a system past its expected peak load to find the breaking point, see how it fails and check that it recovers.
- The failure mode matters as much as the limit: graceful degradation and clear errors beat a silent crash.
- Watch recovery after the load drops back, not only the moment of failure.
- Run it deliberately, against a copy of production you own, because it is designed to cause failure.
Stress testing in software testing is a type of performance testing that loads a system at or beyond the limits of its expected workload, or with fewer resources than normal, to see what breaks first and what happens next. The ISTQB glossary words it as evaluating a system “at or beyond the limits of its anticipated or specified workloads, or with reduced availability of resources such as access to memory or servers” (ISTQB glossary via imbus.de, October 2026).
What is the goal of stress testing?
A load test asks whether the system meets its targets at the traffic you expect. A stress test asks the opposite question: how much can it take, and what happens when it cannot? Three results come out of a good stress test:
- The breaking point. The load at which throughput stops growing, error rates climb or response times rise sharply.
- The failure mode. What fails first (database connections, application threads, CPU, memory, a downstream service) and how it fails: clear error responses, queueing and timeouts, or a crash.
- Recovery. Whether the system returns to normal by itself once the load drops, or stays degraded and needs a restart.
Stress tests also surface bugs that only appear under heavy load, such as race conditions and memory leaks, and show whether the application returns sensible error messages instead of stack traces while it is struggling.
How is stress testing different from load, spike, soak and volume testing?
Each test changes one variable, and the same definitions apply across this blog:
| Test | What changes | Question |
|---|---|---|
| Load testing | Load rises to the expected peak and holds | Does it meet its targets at expected traffic? |
| Stress testing | Load goes past the peak | Where does it break, how does it fail, does it recover? |
| Spike testing | Load jumps suddenly, then returns to normal | Does it survive a sudden burst? |
| Soak testing | Normal load held for hours | Does anything build up over time? |
| Volume testing | The data grows, the users stay fixed | Does it still perform with much more data? |
For the full comparison, read load testing vs stress testing.
How do you run a stress test?
- Start from a passing load test. If the system does not meet its targets at expected load, fix that first. A stress test on top of a failing baseline only tells you what you already know.
- Define the stop conditions. For example, stop when the error rate exceeds a set value, or when the load reaches a multiple of the expected peak. Write them down before the run.
- Increase the load in steps. Raise the number of virtual users stage by stage and hold each step long enough to see a steady state. In JMeter that is a longer ramp-up in a Thread Group, or stepped stages with the Concurrency Thread Group from JMeter Plugins; in k6 it is the
stagesof aramping-vusscenario. - Watch the system, not only the load tool. Record CPU, memory, connection counts, queue depth and error logs next to response times and error rate, so the first resource to run out is visible.
- Drop the load and keep watching. Return to the normal level and measure how long response times and errors take to recover.
- Fix the weakest link and repeat. Each fix moves the breaking point to the next bottleneck.
What is an example of a stress test?
Imagine an online ticket shop that expects 2,000 concurrent visitors at the on-sale peak. A load test confirms checkout stays fast at 2,000. The stress test keeps going, to 3,000, 4,000 and 6,000, and the team records what happens: say the database connection pool is exhausted at 4,000 and checkout requests start timing out. That is the breaking point. The failure mode is timeouts with no useful message. When the load drops back to 2,000 they check whether checkouts succeed again within minutes, or whether stuck workers need a restart. The numbers here are an illustration, not measured results.
What should you watch for during a stress test?
- Throughput that flattens or falls while load still rises.
- Error rates and the type of error (timeouts, 5xx responses, refused connections).
- Response time percentiles (95th, 99th), which climb before the average does. See key metrics in performance testing.
- Resource saturation: CPU, memory, disk I/O, network, connection pools.
- Data integrity: no lost or duplicated orders after failures.
- Time to recover after the load drops.
Where should you run stress tests?
On a staging environment that mirrors production, or on production only with a plan agreed in advance, because the test is meant to cause failures. Only test systems you own or have written permission to test. Running tests from the cloud lets you generate more load than one machine can: LoadFocus load testing runs load tests for websites and APIs from 25+ cloud regions, and JMeter or k6 scripts you already have can run there too (loadfocus.com, October 2026).
Frequently Asked Questions
How is stress testing different from load testing?
Load testing checks behaviour at expected traffic and verifies targets. Stress testing deliberately goes past it to find the breaking point and see how the system fails and recovers.
What should I look for?
The failure mode as much as the limit. Whether the system degrades gracefully, returns clear errors, or falls over entirely is more actionable than the number where it stopped.
Why does recovery matter?
Because production traffic eventually drops back. A system that breaks and recovers cleanly is in a very different position from one that needs manual intervention.
Can stress testing be automated?
Yes. Scripts in JMeter, k6 or similar tools run the stepped load, and a CI job can run a shorter version after changes. Use the same pass criteria each time, so results are comparable between runs.
Sources
- ISTQB Standard glossary of terms used in Software Testing (v3.4), “stress testing”, as reproduced at imbus.de (read October 2026)
- loadfocus.com/index.md and loadfocus.com/load-testing (read October 2026)
