How Should We Plan Load Testing on a Project?

In today’s world of IT community, it is really easy to find tools for load testing. You can combine them in several mechanisms and simulate load in several hundreds virtual users.

But it won’t do any good; if you don’t understand why to perform these tests and what results can lead to in the future.

Hence, before you proceed with testing, you have to answer such questions:

1. What scenarios will be tested?
2. What is expected software behavior in these scenarios?

For example, we have a computer sales site. Administrators noticed that the resource has the most users early in the morning on Wednesday. You ordered the advertisement on TV and waited a lot of new users anytime soon.

Keeping It All in Mind, You’re Figuring Out Your Next Moves:

• All the website pages have to be loaded correctly in less than 1.5 seconds when it is an ordinary load on Wednesday morning.
• The resource should easily process more than 5,000 requests per second.
• The site has to withstand 5,000 users for 1 session. Such a number can easily be real after an advert on TV.

The next step is to analyze what the test environment will be used.

Undoubtedly, testing after release is the most realistic environment. Thus, it is not a good idea to perform load testing in such a situation. In this case, the test can lead to a non-working website.

The next most realistic scenario is a test environment that can correctly show the real environment in the way of total contacted servers and database capacity for back-office. It will be a perfect scenario if your test environment is used only for load tests. Unfortunately, it is not always a real thing.

Sometimes several QA engineers may need a test environment at the same time. Then everyone should know exactly what the other one is doing and how it can influence your work. Other testers should know when you perform your load tests and they shouldn’t be astonished at long response time.

As soon as the test environment is ready, you can perform a few simple tests to see what basic metrics you need.

Load Test Design

1. Creating individual variations, for example, web page loading or a single request via API;
2. Testing full use cases: web page browsing, adding product to a cart, checkout process.

It is worth to use both strategies but not simultaneously. Supposing, you can estimate time necessary to load the homepage if there are 2000 requests per 1 second. In another test, you can create a scenario when more than 100 users can visit website pages, add products to the cart, and monitor the results of error detection.

For this test you have to answer such questions:

• How many users will interact with the system at a time?
• These interrelations will be added simultaneously or gradually?
• How long will take one test?

Let’s imagine for clarity that we have a test for our store that sells TV sets. We perform a test for the date when the site’s ads are shown on TV.

Suppose we have formed test steps that correctly load a website, scroll a page, and add some products to the cart. We need the system to withstand the load of 5,000 users per hour which is why our test will be focused on this.

In real life, it is unlikely that all 5 thousand users will simultaneously make purchases which means that you can specify the test to add a new user every 10 seconds. Each such user will go through the test scenario once, and then it will end. The verification will take one hour and more or until the moment when all 5,000 visitors complete their test scenarios.

Before starting the tests, you need to make sure that the steps can return defects if they do not get the expected result. It is significantly important to make sure that the tests do verify the software’s initial behavior.

Performance of Test

When there are steps, specified test configurations (number of users, frequency of their addition), and the tester made sure that the validation of the result is okay, it is time to perform a load test.

During the test performance, it is necessary to monitor the response time from the server and the processor load. If there are a lot of defects or peaks of excessive CPU load, you can immediately stop the test and note on which particular load it happened.

In any case (if the test is stopped prematurely or after its successful completion), it will need several runs to make sure that the results are completely consistent with each other. At the end of the tests, we can answer the question of whether the developed software can withstand 5,000 orders in 1 hour.

If all test orders were successful and the server response time was acceptable, then the answer is yes. If during the testing process we face problems or the response time from the server is significantly increased, then the answer is no.

In this case, you should quickly share this information with the programmers. They have to know how many users your system can withstand.

In a word, load testing is not an easy thing and it requires enough time and attention. But at the same time, with the help of this type of checks, you can save the system from all kinds of malfunctions.