In the past, when the majority of software projects followed the waterfall model, load testing would typically be carried out towards the end of a project ( i.e. just before the system was expected to go live).
Although this approach allows for the facilitation of a realistic test environment for the application to preside, the overriding problem with it is the sheer cost and complexity to fix any identified performance problems. These issues are compounded by being found at a late stage of the project, with release deadlines looming.
As software projects now predominantly follow an iterative agile approach, it is recommended that load testing follows suit and starts being incorporated much earlier in the project’s lifecycle.
A load test can be incorporated into the build process of the continuous integration solution, allowing the development team to measure and assess performance fluctuations with every incremental software build or release.
The primary value in all testing is finding problems early and providing quick feedback. It is insufficient to find the problems at the end of the project when there isn’t enough time to address them.
The importance and necessity of starting load testing early in your project can be better emphasized by statistics that demonstrate the impact of poor performance from your web application.
Particularly striking is the statistic that shows the amount of revenue at risk of being lost from introducing even a single second delay to your web page. An organisation stands a far greater chance of detecting (and thus resolving) unacceptable delays such as this if they can be found early in the project lifecycle.
If problems like this are found at the end of a project, or when a system has already gone live, it can be very difficult (not to mention expensive) to resolve the issue.
Starting your load testing exercise early, and continuing iteratively throughout the project lifecycle, has other benefits as well such as:
- Improving developer knowledge
Finding a performance issue early in a project on an isolated function or feature can teach developers the best practices they need to adopt when designing, planning and coding in that area.
- Other types of issue can be detected
Executing load tests earlier in the project, and more often, can also help identify other issues than if the tests are only run towards the end. Examples of the issues that could be found include server farm issues, deadlocks and concurrency issues. These issues may actually not even be uncovered at all, if all load testing is left until the end of the project.
- Increased reporting and metric data
From running load tests iteratively as part of an agile process, the development team will soon build up a significant quantity of metrics and reporting data relating to the performance of the system. This data can be subsequently shared with project stakeholders to provide confidence in the performance and progress of the system being developed
With all of the above being said, you might still find yourself coming towards the end of a project when your load testing efforts haven’t begun yet. In this case, take a pragmatic approach and start load testing as soon as is realistically possible. Even though beginning load testing late in a project is not ideal, it is still much better than not executing any load testing at all.
The temptation may be there to simply release the application into production and hope for the best. This is not a good approach to take, as issues uncovered in production can cost exponentially more to fix.
Coupled with this massively increased cost are other negative implications such as system downtime, loss of reputation and decreased confidence from end-users. If these performance issues can at least be found in the test environment, a plan can be made to resolve and mitigate issues such as these.
Learn more about Gatling, the best developer tool to load test your applications, at gatling.io
The Gatling team