Skip to content

Load Testing Blog

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.

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?

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.

REST API using Node.js

I want to setup a simple REST server that allows to Create, Read, Update and Delete data (Users in this case) using Node.js, Express, and TypeScript:

  • I could do it using Java/Spring in a couple of minutes, but I want to learn more about Node.js.
  • Express seems to be a good choice to create REST APIs.
  • And as I think that TypeScript may be the good compromise between Java and Javascript I will keep on giving it a try.

Also, I would like to feel as comfortable as using Java. First I need a debugger. No need to spam console.log() using node-inspector. Then unit tests are mandatory and cannot go without a code coverage tool. Finally, I make use of various tools to build, test, debug and run the TypeScript code. Grunt is convenient simplify these processes (plus it's a gain for productivity).
The only thing I bypassed is a code quality tool. We use SonarQube on a daily basis for OctoPerf, and I might do the same for this sample someday.

Before reading this article further, you may check the result on GitHub Rest-Crud.