You are here

You are here

Performance testing tools: 8 things to consider

Mike Urbanovich Head of Test Automation and Performance Testing Labs, a1qa

During the final episode of Mare of Easttown, the HBO streaming service crashed—just as happened during HBO's Game of Thrones season 7 premiere. In both cases, the site was unable to withstand the load, service was interrupted, and viewers quickly expressed their frustration on social media.

Heavy traffic and performance issues can hit a business in any industry. The consequences are the same each time―a tainted company reputation, lost revenues, and disappointed users.

Such unpleasant outcomes are avoidable if you do performance testing. But your success depends on having the right toolkit as your foundation. The right choice depends on your business needs, budget, and the specifics of your workloads. Here are eight key considerations to keep in mind as you evaluate your options for performance testing.

1. Protocol support

The ability of a testing tool to generate the required workload of virtual users, be it 500 or 50,000, depends on its scalability, and that's often a problem due to limitations imposed by the protocol used.

You should also consider the protocol your application uses, whether it's HTTP/HTTPS for a web application or Real-Time Messaging Protocol (RTMP) for a streaming one. Even the protocol version matters. Ensuring the quality of HTTP 2.0-based software with a tool supporting only HTTP 1.0 is an express train to invalid testing results.

However, to achieve continuity in the QA process, you might want to go even further and consider a tool that supports a range of diverse protocols. This approach guarantees the absence of any process interruptions if the infrastructure changes.

2. Distributed testing and load-scheme customization 

Let's say you have an online store, you expect peak traffic loads during Black Friday, and you need to provide equally trouble-free service across diverse geographies. To simulate the elevated number of concurrent users from remote regions, the tool you choose should be able to run distributed load tests (e.g., applying a master-slave configuration in Apache JMeter).

Another feature to look for is the ability to set up the scheme for applying the load. For instance, if the software supports 500 users (250 should work concurrently), the tool you choose should allow you to perform verifications no matter how this parameter changes over time.

3. Automated reporting

When performance test runs conclude, QA engineers proceed with the topmost activity―processing results. They analyze detected defects, response times, the number of requests, metrics from a database, and other system components to define the overall performance level and design fit-for-purpose improvements.

None of that would be possible without logs generated by a performance testing tool. The ability of a tool to automatically deliver this data is critical, especially when you face tight project deadlines.

4. Licensing costs, restrictions, and options

While commercial tools tend to have advanced protocol support, be aware of licensing limitations that might impede your desired workflow. The set of protocols a tool supports, the number of generated users allowed, the time period and location of use, and the available support are the most frequent issues to consider.

Optimizing licensing to meet these criteria might result in extra licensing and support fees, depending on which tool you're using.

The cost of any performance testing tool must fit within your allocated budget. However, if the software price is low but your team spends too much time delving into the peculiarities of its usage, you're better off opting for a more expensive tool that offers a more intuitive, user-friendly design and better support. Otherwise, the costs associated with implementation could make the tool more costly in the long run.

5. Solid vendor and community assistance

When it comes to support, the people behind the performance testing software you choose are more essential than the tool itself. The opportunity to receive guidance throughout a setup process or help when troubleshooting any issues will save you time and money.

And if you're considering open-source tools, find out in advance whether those tools have a strong support community. Visit technical forums to see how easy it is to find solutions to the latest issues or to stay in the loop regarding the latest patches and how to apply them.

6. Integration with your CI/CD pipeline

The cornerstones of DevOps culture include providing ongoing improvements, sharing responsibility for quality, and having a deep focus on the client's needs. To achieve that, teams leverage continuous integration, delivery, and deployment to automate workflows and deliver software at a fast pace.

That’s why it's vital to choose a performance testing tool that will seamlessly integrate with your CI servers. For instance, Gatling or Apache JMeter open-source tools are compatible with most popular CI systems such as Jenkins and TeamCity. So it's possible to open Apache JMeter in TeamCity from the command line. 

7. Compatibility with monitoring tools

Modern performance testing software should include a built-in mechanism for monitoring response times, the number of concurrent users and transactions, detected defects, and so on. And for more convenience, look for tools that can share this information with other monitoring tools.

For example, the open-source Grafana lets you visualize data generated by your testing tool and showcase it to project stakeholders in a structured and presentable way. The testing tool you choose should allow collaborative work with monitoring software.

8. Customization possibilities

Cost does matter when making your choice, but even if an open-source tool is the only option, that doesn't mean its capabilities are limited. You might be able to write plugins that help overcome some testing constraints (for instance, sending queries from Apache JMeter to Redis).

Match these considerations to your needs

When choosing a performance testing tool, think about whether a given tool supports the right set of protocols, its distributed testing and automated reporting capabilities, the licensing and support costs, the availability and quality of vendor and community assistance, whether the tool is DevOps- and CI/CD-friendly, whether it integrates with monitoring tools, and whether there's room for customization.

There is no one best choice when it comes to performance testing tools. What's optimal for one company may bring troubles to yours, so think about the considerations above and how each applies to your own unique needs before you make that investment.

Keep learning

Read more articles about: App Dev & TestingTesting