1. What do you really need to know?
Determine what you want to learn about your application or system. Each type of test is run differently, and looks at your application in a different light. So, you’ll need to run different types of tests based on what you hope to find out. 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 load test.
- If you want to know if your application has memory leaks, you will want to run an endurance test.
2. Decide on a number of users.
If you are going to load test, how many virtual users do you want to simulate? In order to answer this, you will want to approximate how many concurrent users may visit your site, and that depends on the time of day. Many testers just take a guess. Instead, talk to your architect, talk to your marketing people, and look at the performance specifications. You may even want to ask your engineers how many concurrent users they designed the application for. Plan to test that number and some number above it.
- Note: You will need to schedule your tests for a time when actual users can be minimized or eliminated.
3. Study your analytics.
Do not pretend to know how your customers use your application. The onlyway to truly 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 users – as opposed to tests that you think are representative of your users. In this regard, analytics are a tester’s best friend!
4. Gather your team.
You need to involve a number of people in the testing effort: Developer, Network Engineer, DBA, Business Owner – to name a few. All of these individuals have a vested interest in making the application successful, and each will approach the problem from a different angle. The correct solution will not fall directly into one of these buckets, but will be a combination of two or more. Make sure each is available for testing to:
- Monitor their area of expertise.
- Provide balanced feedback.
- Gain a sense of ownership for the health and performance of the application.
5. 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, but you also need to anticipate the browsers your users will most likely use. Consider the countries and regions where you anticipate high usage, and research the most used browsers. You’ll need to have these installed on your machine to begin testing. Then you need to make sure your load testing software emulates as closely as possible actual user behavior. This includes:
- Parallel thread processing.
- Run Multiple Concurrent Scenarios
- Complex Scenarios
- Being able to generate load from multiple agents (network/cloud)?
6. Be prepared to test your production application.
While it is valuable to test your application when it is in a staging environment, for a number of reasons this can leave some holes in your testing.
- Staging environments are not often exact duplicates of production.
- Staging environments are often accessible from only inside the firewall.
- There is something to be said for testing the same system that you are gathering information about.
7. Set aside time to analyze results.
You should be prepared to spend some time analyzing test results as a group (remember all of those people that were present during testing?). Results need to be looked at carefully to ensure bottlenecks/errors/weaknesses are really understood and that the remediation is effective. Make sure to reach out to everyone and schedule adequate time.
8. Set aside time to make changes.
Also allow time in your schedule to actually implement the changes that you determine are needed! Different remediations will have differing costs in terms of time. Remediations such as implementing a caching strategy, refactoring code, database optimization and hardware upgrades have a wide range of costs to implement in terms of both time and money. As an example, adding additional hardware will require time to order the hardware, receive the shipment, test the new hardware, install software and data, test, install into the network, and test some more. This can be weeks or months!
9. Plan an agile testing methodology.
Once you remediate, it is time to test again! The saying, “testing is a process, not a destination” is very true. 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:
- When code is modified or updated.
- When new hardware is introduced.
- When changes are made to the application server or DB server.
- When traffic spikes are anticipated.
Take a deep breath and relax! You’ve already done most of the heavy lifting. Now that you’ve taken the time to really prepare, load testing your application will help you continually improve your product and your business.