Soak Testing: Finding Bugs That Only Time Reveals
Soak testing is like running a marathon, not a sprint, to find bugs that only time reveals. It applies a typical production load over a long period to uncover slow memory leaks or resource exhaustion. The footgun is confusing it with stress testing.
Why it exists
Some bugs are sneaky. They don't cause immediate crashes but slowly degrade a system over time. Issues like memory leaks, where a program fails to release memory it no longer needs, can go unnoticed in short tests but eventually cause the entire system to fail after hours or days of continuous operation. Soak testing was created to find these time-dependent, slow-burn problems.
The mental model
Think of soak testing as an endurance run for your software, not a high-intensity sprint. You're not trying to find the absolute maximum weight a bridge can hold (that's stress testing). Instead, you're checking if the bridge can handle normal, everyday traffic for weeks on end without developing cracks or structural fatigue. The key variables are a typical load and a long duration.
How it works
A soak test involves setting up a test environment that mirrors production. You then apply a load that represents typical, average user traffic—not a holiday shopping spike. This load is sustained for a prolonged period, from several hours to multiple days. Throughout the test, you monitor key system metrics like memory usage, CPU utilization, and response times. The goal is to spot negative trends, like memory usage constantly creeping up without ever coming down, which indicates a leak.
When to use it
Use soak testing before a major release or significant infrastructure change to validate long-term stability. It's crucial for stateful services, applications managing long-lived connections like WebSockets, or any system where resource management is critical. It's the final check to ensure your system won't mysteriously fall over after running smoothly for its first few hours in production.
When not to use it
Don't use soak testing to find the system's breaking point or to test functionality. For finding maximum capacity, use load or stress testing. For verifying features, use integration or end-to-end tests. Soak testing has a specific, narrow purpose: verifying stability under a normal load over time. Running it for only 15 minutes is pointless; its value comes from duration.
One canonical example
An engineering team prepares to launch a new microservice that manages user sessions. Short-term tests work perfectly. Before deploying, they run a 48-hour soak test with a realistic user load. After 24 hours, they see memory usage has steadily climbed from 200MB to 2GB and isn't decreasing. They've found a memory leak: session objects aren't being garbage-collected. Without the soak test, this bug would have crashed production a day or two after launch.
Interview question
Which type of software issue is soak testing specifically designed to identify?
- a.Immediate system failures or unexpected behavior under sudden, extreme spikes in load.
- b.Functional errors in new features that prevent them from operating as intended.
- c.Slow memory leaks or resource exhaustion that manifest over extended periods of normal operation.Correct
- d.The maximum number of concurrent users a system can handle before failing.
Why? this is the answer
Soak testing's primary purpose is to uncover time-dependent issues like memory leaks or resource exhaustion that only become apparent after a system runs under a typical load for a long duration. Option D describes stress testing, which focuses on maximum capacity, not long-term stability under normal conditions.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on testing — each one lists the topics its interview covers.
See open roles