Skip to content


Continuous Delivery Test Reporting

We have spoken in a previous blog post about documentation about how we believe that if you are building performance tests that support either Continuous Integration or Continuous Delivery then having to produce performance testing documentation before and after each test does not fit with this methodology.

This got us to thinking that if we truly want to use an agile framework and continually push code to production then we need to also consider how we monitor and report on our performance test results produced from our testing tools.

If you have an agile testing process, then you will have functional tests built into this deployment process that run in each environment and if you have a mature robust process then this process deploys to production with no manual intervention if all the functional tests have passed along with any deployment checks.

Now in reality we need to have a performance testing stage in this process as well as each release needs to go through a performance test, whether that is a full suite of peak volume, soak test, scalability tests scenarios or whether that is a regression tests of core functionality.

And this is the bit that we are going to discuss in this blog post because if your organisation wants to push code directly to production then you do not have the luxury of running your performance test, analysing the results and writing up a report to be signed off.

Updating JMeter Performance Tests with an XML parser

When building performance tests, we all understand the value of using properties or variables to store static values outside of our tests. This ensures that any changes to these values need only be made in one place rather than having to make these changes in many tests.

Sometime though you may have inherited a suite of JMeter tests, or you were ** under pressure to develop these tests** and in order to do so you hardcoded values in your tests. This means that if anything changes, an endpoint or the server-name or even the payload of a sampler then you need to make changes to these static values in your tests.

Performance Response Times

When performance testing you need a set of requirements to measure your response times against. When defining these you should do so with your end users or business teams.

It is relatively easy to predict volumes, load and users that will use your application as you will no doubt have some data based on your current systems. It is a lot harder to agree on what the response times of your application should be. Without this critical measure we really cannot say for certain that an application or service performs. The reason being that we are not measuring the response time under load against a value that has been agreed upfront.

We need to be able to answer these questions:

  • At what point does a response time become unacceptable?

  • How can response times be defined in the requirements gathering stage?

  • How can we ensure there is a measure to test against?

We are going to look in this post at how we might categorise response times based on the interaction model with the end-user. And use these metrics to build response time requirements as part of your wider non-functional requirements.

Performance Testing in Production

In this Blog Post we are going to discuss performance testing in production.

Now before you think we have gone mad and lost our minds completely this is not as crazy as it sounds.

Production is an environment that:

  • Is sized accurately,
  • Has a suitable diversity of data,
  • Has the correct data volumes,
  • Is on the correct infrastructure.

All the things you spend a significant amount of time getting right in your performance testing environment and that can be difficult to achieve.

OctoPerf Spira Integration tutorial

We've recently been working with folks at Inflectra to develop an integration between Spira and OctoPerf. If you don't know about Inflectra and Spira they offer a very cool test management solution (among other things), you should check it out.

In this blog post we will highlight all the steps to follow in order to setup this integration. This way you'll be able to see the benefits of working with both tools in your organization.

Launch an OctoPerf test from Spira

Most of the following info has been taken from Spira's documentation page dedicated to OctoPerf.

Activate OctoPerf in Spira apps

The first step is to activate the OctoPerf integration from your Administration > SpiraApps page: