When we talk about performance tests before a go-live, we often hear the objection ‘it costs too much money and makes no sense because the application is not finished yet’. And even after going live, it is often thought that performance testing costs more than it yields. We think this is a misconception: the business case for performance testing is easy to make.
Profit from performance testing before going live
It is recommendable to perform performance tests as early as the development phase of an application, especially if the application is not yet finished. These tests check whether the foundation (or architecture) of the application is capable of delivering the required performance, and whether the application (to that point) meets the performance requirements. For each change or in-between release, it is tested whether it has an influence on the performance, or whether it has unexpected side effects on other parts of the application (this process can also be automated). And if so, it is immediately clear where any deterioration comes from.
Costs versus benefits
This makes it possible to draw a business case for performance testing: the costs of performance testing versus the costs of performance problems. The most direct costs of performance problems are in finding the cause: man-hours of different areas of expertise are needed, tooling is needed and the solution also involves costs (for example, scaling up load capacity by adding hardware, or making changes to the code of the application). Moreover, after the problem is solved, a performance test is often performed to check the desired result. In addition, there are indirect costs such as the aforementioned image damage, productivity loss or even loss of revenue.
Preventing is cheaper than curing
