Web performance is pivotal for any e-commerce business because loading time can have such an impact conversions and sales. That’s why regular performance testing – to understand the load your site can take and when you’ll need extra resources – is crucial.

We’re often so busy detailing all the functional details of how software should work and behave that non-functional aspects like performance get overlooked.

But it becomes much more difficult to address performance issues when a site is live – data may become corrupted and you may need to take the site down to deploy software, leading to lost revenue and lost confidence from your users.

Ideally, we should all be documenting the performance requirements for normal and peak loads for our systems before we go live. It’s far easier to anticipate and deal with problems if we have a good knowledge of our site’s load capabilities ahead of time.

There are various tips and techniques we can use to improve performance in our frontend and backend code. Once we’ve developed and made enhancements within the code, we should look at the system end to end from a user’s point of view and try to measure overall performance.

Types of performance testing

Performance testing is usually performed by the quality assurance or testing team and looks at the system as a whole. It’s an umbrella term for lots of different types of testing – here I’m going to focus on the two main types, load testing and stress testing.

 

 

Load testing is about validating the non-functional requirements of your website, while stress testing is about pushing your system to the limit and seeing how it recovers.

Load testing

This is the more positive of the two types and looks to gradually increase load and look for any potential performance problems within the system. It seeks to determine and document how the system deals with increasing load.

To perform a load test, you’ll load your website using specific scenarios relevant to your business that are extracted from your functional requirements, and document how well it performs. A test can be done with end-to-end IT systems and measures and records the response time of the system under test. It can be as simple as getting concurrent users to hit the system at the same time, and record the response times.

Alternatively, you can also use software such as Selenium to throw load at your system. You simply increase the load until you start to see performance issues – from there, your development team should be able to identify any performance bottlenecks and fix the issues before you release your software into the live environment.

Stress testing

If load testing is about the positive confirmation of your performance levels, stress testing is its negative cousin. We’ve all experienced the effects of peak traffic and websites grinding to a halt under the strain of Black Friday mega-deals or the release of must-have festival tickets. Performing a robust stress test will give you confidence that your site can perform at peak traffic times, correctly handles error and is recoverable.

The purpose of this test is to push a system to the breakpoint – because all systems have them – but it’s how the system deals with stress and recovers that we’re interested in. You’re looking to prove that your data won’t corrupt and that the correct error messages are displayed to your customers at peak times.

During stress testing, you might load the number of users on a site to 10,000, where you know your max load is 1,000. You would record how the system copes with the stress and if the system displayed appropriate messages to the end users.

How to define test cases

Hopefully, you will have defined the non-functional requirements and know what you can expect from load for normal and peak traffic. You also need to consider the following;

Measurements – you need to define what you will be measuring, such as response times, CPU usage, maximum user load before performance is compromised.

Environment – ensure that your test environment mimics production, taking into account both hardware and software.

Acceptance criteria – as with other types of testing, define what constitutes success and failure in terms of performance for your system. Decide what levels are acceptable and what will see the test ‘fail’.

Test case – you need to keep your end user in mind when choosing which test cases to run for your load testing. For example, if it’s a retail site it may be login, add products to basket and checkout. For a typical e-commerce site, you could have 200 concurrent users browsing, 50 viewing their accounts and say 120 adding products to their basket and checking out. You load this test case until you start to see a degradation on performance.

Your test tool – It is not absolutely critical to use a tool, but there are lots of good performance testing tools on the market.

Tools for performance testing

The market is flooded with performance testing tools and it can be quite a daunting task as to which tool to choose. A good place to start is the comprehensive guide from Software Testing Help.

Loadrunner is a robust premium tool I have used many times. It allows you to add massive load and benchmark your system’s performance. 

WebLOAD is a low-cost plugin for use with Selenium, a great opensource tool. You can either call your Selenium scripts in WebLOAD or code a Selenium script within WebLOAD.

How to fit testing into your project life cycle

Once you’ve run your first round of tests, simply analyse the results, implement any fixes and re-run and benchmark until you are happy that your system has met the acceptance criteria.

For each new project, define your performance testing process at the same time as your requirements.  Test your site regularly so you always have an up-to-date view on what your site can take and when you may need to add additional resources. Use those results to plan for the future and work out how to deal with extraordinary events.

If you take the time to understand your capabilities in advance, you’ll be able to anticipate problems before you even have them.

Found this useful?

Here are more testing tips from Sarah:

• A simple guide to testing your software requirements 
• Save time by squashing bugs before writing code

If you have complex testing needs that you would like to discuss, why not drop us an email?