Performance Testing coverage needs to be defined from the application under tests functional requirements and this does not change regardless of whether you are following an Agile or a more Planned approach.

Preparing resilient tests can be a challenging process when you do not know where to start. We will cover this in this guide, from the virtual user validation to smoke testing. And then analyzing the most common errors and how to fix them. Note that we also recommend reading this other guide, it can greatly help understand the analysis and report engine of OctoPerf.

You don’t have to performance test if you are not bothered about the performance of your application; this is the only reason, if you are bothered and you want to make sure your customers get the best possible experience then it is wise to do some.

Timers in JMeter are incredibly important when it comes to the balance and pace of your performance tests, we are going to look at the Timers that ship with the standard JMeter installation in this Blog post but there are others that are available as a Plugin and hopefully this post will encourage you to investigate these further.

Regression Testing, as all Quality Assurance professionals know, is ensuring that previously developed and tested software continues to operate after a change. Performance Regression being a subset of regression testing as a discipline is therefore ensuring that previously developed and tested continues to meet its performance criteria after a change.

This post is about Kafka and the process I have been through recently writing a performance test for an application that subscribes to messages from this technology. The test I ended up with was in the end very straightforward but there were several hurdles that took a while to resolve. I hope that reading this post will hopefully help you avoid them.

It’s been some time since our latest major release, in fact OctoPerf v12 is probably our biggest/longest coming release to date. There’s of course been a couple of minor versions this summer and we’ll also cover them but first let’s focus on the new killer features: the scheduler, alerting through slack/mail and a better UI for the menus. The scheduler is the first item left on our original roadmap (back when OctoPerf was still called jellly.io).

“JMeter is old technology”, I hear this a lot. “Let’s use this tool or that tool instead of JMeter as it’s the latest”, I hear this a lot. “We need a lightweight tool without the GUI interface to write our tests as that will make us more agile”, I hear this a lot.

This article is the fourth part of a series of tutorials dedicated to Gatling Load Testing. Kraken is used to ease the debugging of Gatling simulations and to speed up the process of load testing a fake e-commerce website: PetStore. We will focuse on POST requests and script modularization: In the previous blog post we created a realistic Virtual User that browses the store without buying anything.

While developing Kraken’s frontend I quickly stumbled upon performance issues with Angular Material tree when too many nodes where opened. Kraken is an open source load testing IDE. As such, it displays a tree of directories and files used to script the load testing scenarios: You can have a look by creating a free account on the demo or check the source code of the UI on GitHub. It uses the latest version of Angular and components provided by Angular Material such as the tree.