Strategy around your load tests is as important as the tactics and execution. While one might debate the best comprehensive strategies, here we’ll share a couple of key ideas that can help you no matter what type of project you’re load testing.
Troubleshooting: Change only one variable
Because today’s apps are more complex than ever, sometimes it’s hard to pinpoint a particular bottleneck or performance problem.
For example, you may find that your load tests indicate a performance dip at, say, 1000 virtual users trying to submit a sales order, but you haven’t been able to find the error in your code. Guess what: the way we build and deploy apps today means it could be a hardware problem (for real, not just in the way we like to say that everything is a hardware problem). Or, perhaps, it might be an issue with caching on the server, database or client.
Regardless, as any seasoned engineer (in any field) will tell you, to find which piece of the puzzle is causing the problem, make sure you change only one thing at a time as you run your tests. It sounds fundamental, but we see this time and time again.
This means, too, that you have to bring together your DevOps team to troubleshoot sticky performance issues.
Prioritizing user scenarios
That’s a fancy headline that just means "choosing which user actions to test first.” Most load testing, like the tests LoadImpact conducts, is based on scripting particular user actions.
But which scenarios do you prioritize? Which do you do first, and how frequently?
As with so many development issues, the answer is "it depends.” If you have a specific area that is absolutely critical - like a checkout capability in an e-commerce app or a purchase order submittal from a mobile sales team - start with that. It may not be the simplest scenario to start with, but if it is the action the business depends on - and the metric by which your project’s success is measured, focus there.
Otherwise, another strategy is to start with small, manageable scenarios. For example, you might make sure the "contact us” form works. You might also make sure the log in function works for many people logging in at once. Or you may test that a map service API you’re using can deliver with a particular load based on a given address.
Any of those bite-sized scenarios are good to run individually, but even better to run collectively. Once you’ve build many small scenarios, you can piece them together into a full scenario that tests many aspects of your project.
As we so often suggest, running that bigger, combined scenario as part of your build pipeline can save you from significant issues when a code change affects features you didn’t anticipate.
Try these tips with your next project and see how these load testing strategies can help.
Happy testing!