Skip to content


Which environment to use?

We can all agree that running a realistic load test is important to assess server performance correctly. One of the aspects of such a test is the testing environment. It must be selected carefully based on your requirements.

The sooner the better

Since I began my career as a tester I've been told it is better to test early to prevent costly defects. But sadly I must admit I ran a lot more tests in production than in an early Q&A environment. This usually happens because load testing is disregarded and only conducted at the last moment. However, testing early comes with a lot benefits even if it is also quite different than a typical load test.

What is the plan?

If you are a tester, chances are you already know what a test plan is. If not, the short definition would be : "A specification document of your load test campaign".

This document is very close to the functional test plan in its structure because both share some common ground. The question I'm often asking myself when preparing a load test is if this document should be used at all.


Don't get me wrong, the thinking behind it is mandatory. Otherwise your test campaign might not be very effective. But what about the actual document a tester usually produces? For years, I have been a tester working for different customers every week or every two weeks. I have to admit that I don't rely on a test plan half of the time. Even if you don't switch context so often, I believe there is some common ground depending on the project length and complexity.

How do I define my user profiles?

One of the questions I hear the most from newcomers preparing load tests is about defining proper virtual user profiles.

If you are familiar with testing, you probably heard about the 80/20 rule, also know as the Pareto principle. Apart from impressing the ladies at parties (you know, probably), this principle states that roughly 80% of the effect (performance) comes from 20% of the cause (functionalities in our case). This principle is widely used when selecting the functionalities to test and avoid too much and/or too long user profiles.

Performance testing is not functional testing

Ok, I know, thanks captain obvious.


But still I see a lot of testers creating more than 10 user profiles to test the performance of simple applications. You must keep in mind that these two types of tests differ in terms of objectives, but also in terms of preparation cost.

Yes, a performance test first objective is usually to improve performance. Well this is not always true, but that's another debate.

How do I survive the stampede?

As a performance tester, I am always surprised to see how unprepared most retail websites are. Even when load testing has been done (to prepare for sales or marketing campaigns), most of the time it is nowhere close to the real users behavior. We've already seen the importance of response times in a previous article, but there are other aspects we should consider.

For instance, unless you spent the past years on a different planet, you have probably seen these videos where thousands of people rush into stores during sales. There is no reason why thing would happen differently on a retail website. So the question is how do I survive the stampede?


Focus on what you already know

As obvious as it may seem, you should start by analyzing your users behavior. If this is not your first rodeo, you probably know what to expect. Also, websites like google analytics will give you an idea of what should happen. But never underestimate the importance of analyzing this data.

How to Design Virtual Users as Fierce as RuPaul

Rupaul is an American actor, author, drag queen, model and recording artist born in the sixties.

What is recording

Recording consists of creating a snapshot of the interactions between a web browser or a mobile app and a remote HTTP server. This step is particularly important to create realistic load tests. We have already made great tutorials about recording using JMeter, Fiddler and Google Chrome.

Improved Import

We're excited to announce that we've added the following features:

  • New Record Wizard: the wizard has been greatly reworked for enhanced readability,
  • Automated containers (business transactions): when importing a Google Chrome or Fiddler HAR, we create containers for you automatically,
  • Automated Dynamic Resources: a recording can be bloated with many requests to resources like Javascript, Images or Css. You can now choose to remove them automatically, and we switch HTML request to download those resources dynamically.

Let's take a tour of all these features and see how they help to create realistic virtual users quicker than before!