I’m sure that as you read this you can think of many times recently when you have heard about an IT application that has crashed or failed due to technical issues ….! There are lots of real world examples with banking, baggage and border control issues all making very public news recently.
There are many problems in IT that are a direct result of a poorly performing application. Whether it be slow response times or the system crashing unexpectedly; both of which are detrimental to an organisation and its reputation as it creates a poor user experience and you guessed it, cost both time and money to rectify. This blog will describe the top five reasons why performance issues are affecting IT organisations around the world:
1. Ownership. There normally isn’t a single owner in the IT infrastructure that would take full responsibility for performance issues. There are usually multiple roles across multiple businesses and domain areas, all of which impact on how an application is supposed to perform. Many areas would be in charge of their own tooling and methods of doing things, probably not in a joined up way and it doesn’t stop there. Do the Business Analysts speak to Application support, and do they know (if one exists) what the capacity planning policy is, and do the planners know what the performance engineering team are working on and so on? I’ll take a guess they probably don’t.
2. End to End Performance Testing. Will the performance engineer fully understand the User journey? Performance Testing must test across the whole of the application in the same manner as a typical End User and the testing must extend to other applications of the business that may use, for example different web servers, databases and third party applications.
3. Tools. It might sound obvious, but getting the tooling selection right is as important as getting the test framework right, having a tool that only works across half the IT estate wouldn’t be sufficient to sign-off and prove that the End Users journey is robust and fit for purpose, so selecting the right tool or tools is vital to the success of the exercise.
4. Data. Data always gets a mention. Whether in functional or non-functional terms, it’s often a piece that gets missed when planning Performance Testing. Is the right data available? Does the data meet the acceptance criteria to create meaningful tests that do actually replicate the User actions? Subsequently, can the data scale to provide all the necessary conditions to performance test the application in a manner that you have assurances the system will withhold peak, stress and load?
5. Costs. When planning and costing a project Performance Testing often gets overlooked, naturally there is a focus on functionality and the application working as per the functional requirements; but the performance is a large part of the User experience, so make sure it gets the attention it deserves. Additionally, you may not require a full-time performance tester, so out-sourcing is a cost effective alternative.
If you don’t have a Performance Testing strategy in place nor a single point of ownership you may come unstuck when faced with live performance issues. You will also struggle to perform sufficient triage to trace the error back to the route cause if you are unsure what everyone else is doing or has done to the system under investigation.