Monitoring and Identifying Performance Bottlenecks

Lack of Appetite to Test
The most debilitating and possibly biggest challenge I face when it comes to load testing is the lack of appetite to load and performance test from the senior project stakeholders.

It is difficult for some people to recognise the risk of a load or performance issue. On projects, they are less common than functional bugs and so unless someone is living and breathing this stuff, it is easy to assume that the risk is lower than it actually is. The reality is that although the likelihood might be lower, the impact of a performance or load issue is much higher. Unlike a functional bug, there is the chance that the whole system will be impacted and hundreds or thousands of users will be unable to perform their tasks.

However, unless the budget holders and decision makers get this, they typically do not recognise the value of performance testing. As such, I often find that I’m having an uphill battle to convince decision makers that they need to plan for some non-functional testing.

In a SAAS and cloud world the problem is exacerbated and decisions makers assume they can throw hardware at a performance issue and fix forward. To some extent this is true, however, the number of load issues that hit the headlines make me wonder if this is the right thing to do. It partly depends on whether the decision maker’s job is on the line if an issue like this materialises once the product is live.

I’ve not been able to identify a quick fix to this challenge but I have made it my mission to make as many people as possible aware of these dangers and I call on you to do the same at every opportunity.

Limited Time and Budget
It takes time and money to do load and performance testing properly. Unfortunately lack of appetite and lack of knowledge at the planning phase means that the right time and budget are often not allocated. This makes it necessary to reduce the test scope, depend on low-skilled testers or select open source tools which in turn increases the project risk. It is true that all projects should carry a certain level of risk, but the problem comes when the risk is not understood or mitigated somehow.

If you are not sure what to allocate to your load and performance testing, give me a call. If you don’t want to do that, I can tell you now that one week is not enough time.

Selecting the Wrong Tools
What is the best tool to test your system? Often the decision is based on the skills and experience of the testers on the project, licensing cost or perhaps the test manager or the corporate standard. Sometimes this might be the wrong decision and (sometimes many, many) days are lost to getting the scripts working and getting the tools to recognise the controls of the application being tested.

A short Proof of Concept easily fixes this and is well worth the investment before the commitment to a tool is made.

End of Project Lifecycle
Load and performance testing are usually placed at the end of the development lifecycle or sprint. There are two reasons for this:
1. It makes sense that the application works functionally before it is performance tested.
2. Traditional load testing tools that record HTTP traffic depend on a stable build as the scripts they generate are fragile.

The nature of project work means that being at the end of a lifecycle and having these dependencies, the allocated time for load and performance testing gets cut. As such, the planned scope of the tests does not get complete and the risks that the tests are supposed to mitigate are left unmitigated.

These challenges are largely strategic, requiring patience, tenacity and influence to resolve. These are the skills that a good Tester, Test Manager or Head of QA need to exercise and perhaps sharpen in order to make performance testing a success.

What next?

nFocus have identified a range of challenges when purchasing load and performance testing services. To learn more about these challenges, including how to solve them, please visit the website info page here.