The 10 Commandments of Load Testing

by RentTesters on June 22, 2011

Thou shalt know how thy test tool works.
The worst performance testers I have met were always more concerned about whether they could get their scripts to run, rather than whether the tests they were running were realistic. Read the documentation, practice, spend some time figuring out what all the settings do, then relate how your scripts are running back to how real users exercise your application.
Thou shalt gather realistic usage data.
Garbage in, garbage out. If your transaction volumes are wrong, then your load test is wrong.
Thou shalt have testable requirements.
Non-functional requirements (especially load and performance-related requirements) are usually an afterthought for many projects. This shouldn’t stop you from trying to gather the requirements you need for your tests. The business approach of “let us know how fast it is, and we will let you know if that’s okay” isn’t good enough. Get some numbers. The numbers can change in the future (maybe call them “targets” or “guidelines” rather than “requirements”), but you need something to test against before you start.
Thou shalt write a test plan.
Even if you already know what you’re going to be doing, other people would probably like to know too – they might even be able to help; besides, a signed-off test plan has saved many a tester from the wrath of project management.
Thou shalt test for the worst case.
Don’t test with transactions from an average day, test for the busiest day your business has ever had. Add a margin for growth. Testing failover? A server doesn’t fall over at midnight when no one is using your application (would we care in this situation anyway?), it falls over in the middle of the day when lots of real people are using it.
Thou shalt monitor your test environment infrastructure.
I feel that I have to spell it out, because I still see people who don’t do this. Monitoring your servers allows you to more easily figure out where the problem is. You can also make neat observations like “response times for the new version of the application are the identical to the previous version, but CPU utilisation on the servers has increase by 10%” When I say “monitor your servers”, this includes your load generators.
Thou shalt enforce change control on your environment.
The final thing you tested should be what is deployed into Production – same application version, same system configuration. It’s easy to lose track of what you are actually testing against if people are making uncontrolled changes to your environment, or if people are making tuning changes without tracking what they are changing. Keep a list of changes that are made…even if you are in a hurry; and always make sure you know what you are testing against.
Thou shalt use a defect tracking tool.
An untracked defect is a little like a tree that fall in the forest when no-one is around – no-one cares. Raising defects lets everyone know there is a problem (not just the people who should be working to fix it). It also provides a neat repository to keep track of all the things that have been tried to fix the problem.
Thou shalt rule out thy own errors before raising a defect.
“Oops, my bad!” is a great way to lose credibility with the people who are going to be fixing your defects. If you don’t have credibility, you are going to have to work much harder to convince people that the problem you are seeing is due to a fault with the system rather than a fault with your test scripts. Don’t be so afraid of making a mistake that you test “around” errors (like people who see HTTP 500 errors under load and “solve” the problem by changing their scripts to put less load on the system). It always helps if you have followed commandment #1 Thou shalt know how thy test tool works.
Thou shalt pass on your knowledge.
Write a Test Summary Report and let management know what you found (and fixed) during testing, make some PowerPoint slides, hold a meeting. Let the Production monitoring group know which metrics are useful to monitor, let them re-use your LoadRunner scripts for Production monitoring with BAC. Leave some documentation for future testers; don’t make them gather requirements and transaction volumes again, or re-write all your scripts because they don’t understand them. Retain your test results until you are sure that no-one is going to ever ask about the results of that test you ran all those months ago.

#SQASolutionShare on FacebookShare on Google+Share on LinkedInTweet about this on TwitterEmail this to someone

{ 2 comments }

loadtester September 25, 2008 at 6:51 am

You’ve got a bunch of good points here, but there are 3 that I have to comment on.

“3. Thou shalt have testable requirements.” First, I flatly disagree. Quantified requirements are both wrong and misleading (unless they come from a contract or SLA). Second, you already have testable requirements. Happy users. I assure you that I, and those I have taught, can (and do, on a regular basis) do fabulous performance testing without ever judging the “goodness or badness” of a single number. Simple trend analysis and users expressing their feelings about performance in qualitative terms while they are conducting UAT under load is faster, easier and more accurate.

“4. Thou shalt write a test plan.” It’s been years since I’ve used a test plan, and twice as long since I so much as asked someone to sign-off on one. Or maybe I always have a test plan… it goes something like this:
– Figure out why we’re performance testing in the first place.
– Figure out what I’ve got available to test with.
– Figure out what the application does that anyone cares about.
– Design, develop and execute tests based on current risk assessments.
– Analyze, Report, Reassess and Iterate.

What more do you need? Especially if you commit to reporting results and revised priority lists every 24-48 hours.

“8. Thou shalt use a defect tracking tool.” It depends what you mean by “tool”. If “tool” includes whiteboards, email and sticky notes, then I guess I can live with this.

Now, had you listed these as “10 Critical Considerations of Load Testing”, I’d agree that all of these points should be explicitly considered.

Joe Strazzere December 29, 2008 at 9:03 pm

Previous post:

Next post: