Load Testing – Why?

Load tests identify performance problems that will affect users. If the web app takes 15 seconds to respond when someone is putting a widget into your e-commerce shopping cart, the probability of that user inputting a credit card number decreases dramatically. Cognitive psychologists have show distinct correlation between user confidence and unexpected application behavior. When the system does something “odd”, then people don’t trust it. Slow is bad. Slow response loses visitors and loses revenue. It can cost your company $ millions (NO EXAGGERATION)!

Successful web applications will run as smooth as silk…even when a large volume of users are banging on it during the busiest day of the year. That’s why load testing is so important. Every stakeholder should be very concerned about the performance of the app – marketing execs, C-levels, product managers, project managers, developers, QA leaders…everyone. If the system can’t handle the load, bad things happen. Revenue is lost. Customers go away. Your company gets a bad reputation. Bloggers write about your failures. System failure leads to a downward spiral.

Load testing provides a way to scientifically confirm that these bad things won’t happen. At least not because the web app melted down due to having too many customers.

For the development team (that includes QA), load testing is CYA. Documentation of the test process is a clear, objective indicator that we know what we are doing. We are software professionals, and we are concerned with making customers #1 priority.

We care about quality. We take pride in the success of our company. We want our business to grow and pay big Christmas bonuses. We want to be the industry leader and have conferences call us asking us to speak because we are recognized as a top player in web application development. Without good load testing, you will just be an attendee who is crossing her/his fingers hoping the system doesn’t crash the day after Thanksgiving so you won’t join the Circuit City employees in the unemployment line.

According to Gatesway Testlabs’ blog, “Load Testing is one of the most difficult phases of development cycle – since it deals not only with the testing tools but also with the overall test infrastructure.”

Customers expect pages to respond within a few seconds. Most of us aren’t comfortable with anything over 4 seconds. Impatience is a common characteristic of today’s web users. When the page has a poor response time, customers are moving on to someone else’s site.

While there are no industry standards for response times, there are certainly usability parameters that should apply to your web application. Most of us will be more patient browsing through your family’s photos on Flickr, even if the pages are slower than normal in Flickr. Buying something is different. Especially in this time of economic crisis where buyers can be choosier and more demanding of merchants. To quote Veruca Salt in the original Willy Wonka, “I WANT IT, AND I WANT IT NOW!”

(BTW, didn’t you think the remake was creepy?)

Online marketplaces aren’t the only apps that are increasingly competitive. Providers of sites for social networking, online media, and other Web 2.0 applications should be load testing to measure their ability to handle traffic. Personally, I had some bad response times on Plaxo several months ago, and I stopped going there. I’m sure other people have done the same. It is too easy to switch, so why inflict pain on yourself by using a slow web app?

Only you can evaluate what is acceptable for response times for your app or site. You should study any data you capture on conversion patterns relative to page display speed. My bet is that excessively slow pages will have significantly slower conversion rates. Likewise, pages with even small error rates will chase off customers.

Load testing can detect errors and pages with bad response times. You may be surprised what you find in your app under testing. From my experience, there is commonly a volume where problems begin spiking. For example, an application may have no errors and sub-second response times until 1,500 concurrent users are on the site. More importantly, those 1,500 are running a specific scenario. That’s the value of load testing – you can find the bottleneck. Uncovering the troublesome code or device is imperative in fixing it. Moreover, by pinpointing the scenario that causes load failure, you know where to start looking in the system.

Another reason to load test is that site failure will get the boss’ attention very quickly. You know how it works: The CEO’s wife was on our site today when it got very slow; she called him; he called the Product Manager; who started growling as he went hunting for who to blame. As one of my managers once taught me, “Crap rolls downhill.” Load testing is your defense against the crap avalanche that crashes near your desk when the site fails under volume.

Why load test? Because it is the right thing to do. We want happy customers. And you want to keep your job.