A Guide to Load Test Smarter | LoadStorm

Jason Buksh is a Technical Project Manager and Performance & Load Test Consultant in London, England. Jason has extensive experience with performance testing at many companies including HSBC, CMC Markets & Siemens. He gives independent advice, is test tool agnostic and has wide experience with many of the leading market tools. Jason also writes many articles and runs the Performance Testing blog perftesting.co.uk

We appreciate his time to share his thoughts and experience with us about a topic that gets us excited. Here are some tips from him to make the best of your load testing.

10 Tips from Jason Buksh

1. Workload Definition: I am truly amazed at how many projects I’ve looked at that don’t have a clearly defined performance workload model. Its no good sitting in your head – because at some point, someone is going to want to know what exactly you have tested (and why) when you present the results. Good performance testing starts with a well-defined workload model. The reason I think this is not clearly defined within many projects is that it can take an exceptional amount of time to get small but important information. TIP: If you can’t get it easily guess & document.

2. Sign Off: Get a stakeholder to sign off on an agreement for the workload model. This ensures a few things: most notably risk mitigation; also communicated interest – people become interested when asked to sign things. This also reduces ‘finger pointing’ should something go wrong. E.g. If the site experiences much higher load than you have tested for, (and crashes) you are all responsible. Also, if the site crashes during load testing – you won’t have people disputing the load you are applying.

3. Tool Selection: Different load testing tools have different costs, benefits, limitations and investments in effort to get them working. Understand these before choosing your weapon of choice. Make the limitations known to stakeholders.

4. Don’t forget to Monitor: Load testing tools are great for generating load, but monitoring backend metrics (such as CPU, log files) will help enormously to understand any areas of contention and application capacity.

5. Just Test It! Don’t get bogged down for weeks in writing strategy and planning documents. Start basic load testing in parallel. Your planning and strategy will be more meaningful and grow out of date at a much slower rate.

6. Outsource to a Professional: Quite quickly load testing can become an albatross to those that have inherited it. Developers definitely have the ability to execute this role, but lack the experience and more importantly the time. A seasoned performance tester will be able to execute, advise, and complete a project in a much shorter timeframe with less risk to the business.

7. Outsource Agnostically: If you chose to outsource, don’t outsource to a vendor that is tied to a specific tool, because surprise surprise they will recommend that tool. Some tools are more suitable than others, some are cheaper – don’t take this choice away from yourself.

8. Environment Role & Demarcation: This is the largest cause of time risk I observe on projects. If there is a pre-production environment, how easily can the team deploy a live-like build to it? Make sure environment debug responsibility is a separate, clearly defined task, and assigned to a named person.

9. Be Flexible and Adapt: Every business works in a different way, don’t be rigid in approach. Work in a way that allows you to adapt your process and requirements around the way people work within the business.

10. Loosely Define Key Performance Metrics: Do this yourself. Quite frankly I’ve seen this messed up so many times that I’m now firmly of the opinion that its much easier and faster to do it yourself. I’m also a fan of getting KPI’s defined – but not too strongly. Attach an SLA to it. People tend to know enough to see if a KPI result is acceptable or not.

Follow the above guidelines and you should save yourself time, effort, cost and risk.