I’m reading the classic book The Art of Software Testing by Glenford Myers. While it may be old (copyright 1979), it is still full of golden nuggets. Myers uses real examples from the ancient days of software development to demonstrate the practical side of testing.
One of my favorites is his definition of stress testing.
“Stress testing is the process of evaluating failure points in a web application by introducing adverse conditions into the runtime environment.”
Normally I think of stress testing as overloading a web application with large volumes of users. Many people stress out their website that way. This form of testing isn’t limited to web, it could be an iPhone app or a Windows spreadsheet or even a laser printer, because there are other forms of stress and other types of system that aren’t web.
My definition:
Stress testing is doing anything you can to cause the system to fail.
A tester may remove a web server from the load balancing pool to see if the system degrades gracefully. Other resources such as disk drives, database servers, or network bandwidth may be restricted in stress testing because the engineer needs to know if the consequences will be painful for end users.
Wikipedia defines it thus:
“In software testing, stress test refers to tests that put a greater emphasis on robustness, availability, and error handling under a heavy load, rather than on what would be considered correct behavior under normal circumstances. In particular, the goals of such tests may be to ensure the software doesn’t crash in conditions of insufficient computational resources (such as memory or disk space), unusually high concurrency, or denial of service attacks.”
It is true that in a general sense stress testing is experimenting with conditions to break a system or device. For my purposes, I will stick to websites and applications. LoadStorm’s style of stress testing tries to break the application by increasing the number of virtual users over a period of time until the application fails.
I’ve received emails or read about many terms for this failure:
- Meltdown
- Knocked the system over
- Sucked the blood out of the database
- Sank the tank
- Tossed the ring in the fire
- Put the baby to bed
- Disconnected HAL
- Michael is now the Don Corleone
- Killed it
- Hammered the server to the ground
- Brought the Klingons up in here
- Blew it up
- Smackdown
- T-Rexed the guy in the outhouse*
- Pitched a Vader fit
- Gave it a lethal injection
- Overrun with traffic
- Put it in stasis
- Brought it to its knees
- Unplugged it from the Matrix
- Bit the poison apple
- Overloaded its capabilities
- Drained the system’s life
- Uncovered the Kryptonite
- Congested with requests
- Server got pregnant
- Ran out of gas
- Fried the circuits
- Tricked the Joker
- Inundated with volume
- Made it an offer it couldn’t refuse
- Flooded out the site
- Sent ET home
- Crashed the server
- Needed life support
- Cratered the app
- Rode the dead horse
- The Blade Runner arrived
- Danced on its grave
- Squashed the cahunas
- Took the black train
- Brought the agents to the party
- Pulled a Freddy Krueger
- Gave up the ghost
- Shutdown brother Lore
I bet you can add to this list. Just put them in the comments.
By stress testing your website or web application, you can determine what your users/buyers will experience in times of extreme load. Also, you can find the points of failure in order to tune your application. Perhaps you realize that your web app becomes database bound after about 500 concurrent users. This knowledge allows you to make some appropriate adjustments to your infrastructure or architecture. You then run another stress test and find that your web app doesn’t fail again until you reach 5,000 users.
Myers states in his book that 50% of the time and cost related to a typical software development project are expended in testing. Maybe this basic dynamic of development is different now. After all, we have web applications running on ubiquitous Linux boxes rather than COBOL programs running on VMS 370. Furthermore, we have Agile development methodologies instead of the antiquated waterfall approach. Regardless, I bet he never T-Rexed the guy in the outhouse*!
*pop culture reference to Jurassic Park