Skip to content

Load Testing Blog

What to do with my results

Since I started my career as a tester, I'm often impressed by how disregarded communication in load and performance testing is. However, you can be as skilled as you want as a technical tester, if you can't explain your analysis and convince decision makers to take actions, most of your work was in vain. In fact, I've seen colleagues who were not interested in the technical aspects of the job get better customer satisfaction. The good thing is, communication is just a skill amongst others that you can train.

Today I would like to share everything I learned about presenting results.

Once upon a time in my load test campaign

Once upon a time

In my opinion, you should always come up with a short story describing your load test campaign. Rest assured, it does not have to include fairies and princesses, the truth will do just fine. It allows everyone to understand quickly what happened during the campaign. And it's pretty obvious that a good story always sells better.

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.

Joker-plan

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.

  • in DevOps
  • 7 min read

Backup Couchbase to S3 automatically

Couchbase is a popular NoSQL Database. I'm working with this database for about a year. I like this database for several reasons:

  • Easy to install: a single .deb file to dpkg on Ubuntu,
  • Fast: it serves queries within milliseconds,
  • Distributed: you can build a distributed cluster with tens of machines.

The biggest downside with this database is that it consumes almost 20% of cpu on our m3.large AWS instance for no reason. As soon as you setup query views, it consumes cpu cycles even if no data is stored.

The point of this article is not to debate about the pros and cons of this database, but i though sharing some thoughts about it can be useful.

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.

ThankYouForNoticingThisNotice

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.