April 21, 2015 // By Aaron Humerickhouse
More times than not performance/load/stress testing is performed at the end of the project with little time to fix issues before launch. If we think of poor performance as a defect, why would we want to wait until the last few weeks of a project to fix it? Performance issues are triaged, fixed, submitted, and tested just like defects. Knowing there are performance issues with little time left on a project is not advantageous. If a project starts executing performance tests earlier time will be saved and performance will be better.
When a project decides to start performance testing earlier, the team can find performance issues earlier. Much like a defect, the earlier it is found the less expensive it is. Developers will spend much less time triaging the issue and it will not affect as many areas if it were found earlier. Additionally, it can help teach developers what to stay away from when designing, planning or coding. This will help reduce time dedicated to performance near the end of a project.
Figure 1: Theoretical difference between starting Performance Testing at the beginning of a project vs. the end of a project
Executing performance tests earlier and more often can also help identify other issues than if it were run just at the end of a project. There are concurrency issues, server farm issues, deadlocks, and maintenance jobs that can arise throughout a project that will affect performance; these are not likely found when performance testers have time set aside to run their suites.
Running performance tests throughout the project can also help improve overall performance more so than running performance tests at the end of a project. If there are guidelines for performance that are enforced throughout the project, developers will always keep performance in mind leading to better performance overall. Additionally, smaller snippets of code that are well performing will not lead to major performance issues at the end of the project.
Executing performance tests early and often is also crucial when a project utilizes legacy code. When there is old code existing it is already susceptible to performance issues; focusing on performance early will help eliminate crippling performance at the end of a project.
When performance is given a second thought to functional requirements, quality assurance teams can suffer. Often when QA members are working on the project that is hindered by performance, their time is wasted while waiting to log in, a page to load, or a database query that takes far too long. In the moment it may not be such a big deal, but over the life of a project it can lead to days or weeks of wasted time.
Performance tests should be written and performed throughout an entire project. Creating small smoke tests to keep the developers in line with the overall performance goals will help a project keep performance excelling.
You can read more about how to maximize the impact of your QAT efforts in this white paper. You can also go to our contact page or call us directly at 855-344-1845.