Skip to content

Load Testing Blog

We are Obsessed With Quality

As mentioned in our previous article, Are You Buying Quality Software, we aim to deliver features at fast pace while maintaining the highest possible code quality. Our last article about our code quality has been written more than one year ago, how are we doing today? The following sections get you an insight about the code quality of our backend server written in Java.

So you’re saying you have no bugs?

We're not saying our software doesn't have bugs. Every single piece of software has glitches or bugs. But, it's quite usual for us to fix a bug and release a patch the same day. We thoroughly test our software entirely to make sure most of the bugs get caught before going into production.

Ask one of our competitors reports about their code quality. We are pretty sure no one will ever give you that information. We think you must know what you pay for.

Sonarqube Analysis

Quality Profile

Our code quality analysis is based on Sonarqube, using a custom quality profile with more than 750 rules enabled.

Sonarqube Quality Profile

Our profile used last year had a little over 700 rules enabled. We try to slowly increase the number of rules checking the code to further improve code quality. Feel free to use our own quality profile inside your company to check their code against our coding rules. I'm pretty sure you will be surprised by the results.

Test automation with OctoPerf's API

Even though automation is not always the best solution, you can still use some to save time on your day to day chores. And since OctoPerf is a GUI based tool we sometimes get remarks on how "unpractical" or "not devops friendly" this can be. Although I do not agree and still think that even a devops has better things to do than learning another coding language to test his code, I'd like to prove that even a GUI driven tool can be used to automate your testing.

So how does it works

And there's a simple reason for that, our backend is made of REST services. So anything that can be done through the GUI can be achieved with REST calls. That does not necessarily means that the work of our front end engineers is useless (they don't take criticism well so let's skip it) but rather that anything you need to do is possible. For today I'd like to automate a simple case to show you: updating the list of users and running a test. This is something you might want to do as part of your continuous integration pipeline, and making sure the list of users is up to date is definitely a plus when it comes to avoiding/analyzing errors. You can find the swagger of our REST api in the documentation or directly here:

API documentation

Search and replace in HTTP actions feature review

The latest version of OctoPerf comes with an improvement to the Search HTTP actions: You can now replace values in the flagged HTTP requests actions!

How it works

You could already flag HTTP actions that match some search criteria, for example:

  • HTTP actions with a specific header's name,
  • HTTP actions with a particular query parameter's value,
  • POST requests whose content contains some data,
  • etc.

Search header by name

Collaborative JMeter Testing

Performance Tester Teams struggle to share their work when using JMeter. Sharing JMeter projects can be a tedious task. OctoPerf solves this issue by allowing Teams to share their load tests.

Workspaces allow teams to share JMeter projects (Virtual Users, Scenarios and test reports). A Workspace is a collection of projects accessible by one or more people with different rights.

Workspace members have different rights depending on their role:

  • Administrators has access to everything,
  • Testers can do anything except managing the workspace members,
  • Viewers can only view the content of a workspace.

OctoPerf becomes a JMeter Performance Center for QA Testing Teams who want to scale.

Load testing without think times?

There are a few key parameters that you must control in order to launch relevant tests. I believe think time is one of those, and it is so often overlooked that I would like to take some time to highlight what it stands for. Any quick search on your favorite search engine will tell you that think times in load testing are meant to reproduce human interaction time. As a load testing script is usually composed of a list of requests, it's easy to understand how replaying them with think time is one more step toward a realistic behavior. But this doesn't mean it's easy to understand how to use and configure it.