Essential Load Testing Tips for Testers

The saying, “testing is a process, not a destination” is very true. Testing is an ongoing process as it should be performed at each step in the development cycle and should even continue after the application is live. While it can be frustrating that a tester’s job is never done, it’s important to take consolation that with each testing and remediation cycle, the application improves.

Without adequate prep work, a load test can’t find all that it should. Applications go down under load for two reasons: Either developers didn’t load test or, worse, they took the time to load test but didn’t prepare properly.

For example:

• If you hope to discover how your application performs with little or no load in order to get a baseline, you will run a single user test.
• If you hope to determine how your system will perform under normal expected load, you will run a load test.
• If you hope to determine the breaking point, the point where your application either stops responding or responds so slowly that it is unusable, you need to run a stress test.
• If you want to know if your application has memory leaks, you will want to run endurance or soak test.

Fix a number of users: If you are going to load test, how many virtual users do you want to simulate? Talk to your architect, marketing people and look at the performance specifications. For concrete statistics from a historical perspective, go directly to your own analytics reports. You may even want to ask your engineers how many concurrent users they designed the application for, and your product owner/marketing base their projected numbers based on promotional activities. Plan to test that number and some percentage above it. You should also make a note that if you run a post-production load test for some reason, be sure to schedule your tests for a time when actual users can be minimized or eliminated.

Analytics are a Tester’s Best Friend: The best and only way to really understand your users is to study history i.e. analytics. By studying your analytics, you will be able to create tests that are actually representative of your actual users – as opposed to tests that you guess are representative of your users.

Gather your team: Testing is done best when you involve expert people in their respective domains. Developer, Network Engineer, DBA and Business Owner etc – all of these individuals are keen in making the application successful and each will approach the problem from a different angle. The correct solution will not fall into any individual’s bucket but will be a combination of two or more.

Prepare your browsers: Use testing software that brings you as close to your actual users’ experience as possible. You should be able to record your scenario in the browsers of your choice as well as you need to anticipate the browsers your users will most likely use.

Allot time to analyze results: You should be prepared to spend some time analyzing test results as a group that includes all the people who were present during testing. Results need to be looked at carefully to ensure that loopholes are well understood and that the remediation is effective.

Schedule time to make changes: Different remediation will have differing costs in terms of time and money. Remediation such as implementing a caching strategy, re factoring code, database optimization and hardware upgrades have a wide range of costs. For example, adding additional hardware will require time to order it, receive the shipment, test the new hardware, install software and data, test, install into the network and test some more. This can take months.

Plan an Agile testing methodology: Each time a bottleneck is uncovered and corrected another one rises to take its place. It is important to plan an Agile testing methodology, whereby performance testing is baked into each step of the development cycle. Additional testing should be performed: