It’s 4:49pm on a Thursday. The phone rings.
Wendy, the Performance Engineer: Hi, this is Wendy.Larry, Head of Development: Wendy, I’m so glad I caught you before you took off for the day. How are you?
Wendy: Ummm, fine.
Larry: Great. Listen, we were able to jam that great new feature into our latest build and want to make sure it’s included in this weekend’s load testing. Can you get that going for us so that we have results on Monday?
Wendy: On… Monday?
An owl hoots in the distance.
Load tests can be super-scary if you aren’t expecting them. They take a fair amount of planning and coordination to pull off. They don’t just happen by themselves.
Why would you need to run an unexpected load test? Turns out there are a number of reasons. For example, let’s say your app crashes in production. Once you recover from the crash and determine what went wrong, which is pretty high-pressure in itself, you then have to run some tests to make sure the problem won’t happen again.
Or like Wendy above, maybe your dev team surprises you with a new feature or with an early build, and you have to cram in a load test before you’ve had a chance to properly put everything in place.
The point is, things like this can creep the average performance tester out. But you don’t need to get spooked. Planning your load test doesn’t have to take tons of time if you approach it the right way and if you set yourself up for success from the start.
Follow this advice and all will end well.
It’s All About the Scenarios.
Load tests are by their very nature big and complicated. That doesn’t mean they have to be inefficient. The key to executing a large, complex task is to focus. For load testing, you want to focus on the pathways that matter most. Don’t waste time testing code that hasn’t changed or testing a feature that users rarely access. Instead, keep your eye on the prize and you’ll give yourself the most confidence you can in your app’s ability to grow and scale.
Performance engineering is all about the experience, which exists at the intersection of the user and the app. That means you’ll want to focus your load testing on those user paths that are most likely to be followed. Plus, you need to account for any relevant attributes of the application itself, how it was built, and how it is changing.
There are a few ways of approaching this:
- Focus on pathways that users are likely to go through: Take some time before you turn in at night to cuddle up with Google Analytics. Understand how visitors are accessing and traversing your site: where do they enter? How do they navigate? What are their goals? Look for the 20% of pathways that host 80% of the people. Better yet, find the 5% of pathways that host 95% of the people. Pages like your home page, your main login, or a hot viral video landing page will give you the biggest bang for your load testing buck.
- Focus on pathways that involve money or other KPIs: If you are an eCommerce site, your checkout process really matters. If you are a content site, view counts of your top articles drive your advertising rates and your financial engine. Whatever you do, there is a path on your site that plays a role in how you get paid. These pathways are critical to test under load because they are what turn a website into a business.
- Pathways that involve new or recently changed features: If you are looking for the parts of your app most likely to break under load, a great place to look is in anything that’s new or changed – especially if you have a robust load-testing practice and high confidence in the scaling specs of your site. Work with your dev and functional QA teams and watch your change logs to identify revised or updated code blocks, as well as any recent areas of quality regression. New features can hold unexpected surprises in production. These make great candidates for the focus of your testing.
- Pathways that involve known bottlenecks: Finally, every app has its secrets. There’s that one SQL query that doesn’t scale like the rest of the app, or that particularly troublesome module that’s never been fully trustworthy even though no one knows why. Like the abandoned house just at the edge of town, it’s the unknown things lurking inside that create the biggest scares. You’ll always want to be looking out for these dangerous areas, as they have a way of never quite dying.
When you have to throw a load test together quickly, figure out which of these areas gives you the best approach for focusing your efforts in light of the circumstances you are under. Once you do, it’ll be a lot easier to put the pieces in place that will let you quickly and confidently run your test.
Be Prepared to Act
Like the Boy Scouts say, be prepared. It’s really hard to set up a load test quickly if you don’t have good infrastructure to begin with, so spend the time now when things aren’t crazy to get those systems in order.
Start with a library of scenarios that you can use as building blocks for complex tests. These performance unit tests are a great way to quickly build highly customized scenarios that cover the pathways you have already identified.
Next, automate your tests and plug them into your test automation platform or your continuous integration platform. If you do this by stringing together your unit tests, you’ve got a system and the experience to easily and flexibly create a variety of different tests. Then, when that unexpected load test comes around, it’s not as much of a fire drill. You know how to do it. You’ve got it.
You’ll also want to have a good shared understanding of how to build and execute a performance testing plan. Create a test plan template as a starting point to give you structure when you are in a rush. It doesn’t need to be complicated. With the right amount of forethought, it can really help you focus on the right set of pathways and go from there.
You should also have strong monitoring systems in place so you can keep track of important load testing key performance indicators, or KPIs. In general, your most important metrics for virtually any load test done in a hurry come down to concurrency, transaction rate, and the user experience. You should have the process to measure these KPIs down cold, so you’ll be ready when you need them.
The cloud is a great resource to have on tap when you need to set up load generators in a hurry. You get even more value if you combine your load tests with synthetic users that can gather metrics against your live production site for trending and comparison purposes.
When you are under pressure to come up with a plan, time is not a luxury you have. That’s why it’s important to be prepared, choose your use cases carefully, and know what metrics you are looking for. It’s not that scary if you simply break it down. For more tips on what you can do to be prepared, check out these performance testing horror stories from Brad Stoner and get his suggestions on how to avoid them.
Photo Credit: Kristy Hom