There are many steps in any software engineering project that must be taken before going live: the development stage must be complete and functional, including the features designed during the discovery process; the project’s scope must be the one agreed upon with the client, and different tests must be performed to ensure proper operation. This last point has been historically focused on two aspects. The first aspect is functional tests – i.e., tests that allow you to make sure that, if you perform a certain action, there will not be an error or, if you click “OK” on a modal dialog box, the software will respond accordingly. The second aspect is non-functional tests – i.e., tests that focus on how the system behaves in terms of security, usability, scalability, among other issues.
However, over time and with use, performance problems may appear that exceed the presence of a bug or issue, and have an equally negative impact on the client: they are the problems that appear when the system is under stress because it is used massively or concurrently or because it has too many features. That is why projects that are more comprehensive and quality-oriented include this additional phase –performance testing–, as a requirement that has to be met before going live.
Starting with Quality Planning
Performance Engineering should ideally start at the same time as general Quality Planning. Preferably, the battery of tests involved should be conducted periodically, before any new release or sprint. It is recommended to work under an agile environment so that we can check constantly that general performance is improving or is at least the same as the previous release, and the latest features added have not affected performance. The first trial run generally comes after a couple of months. Additionally, a more in-depth test is conducted before going live, to guarantee that the end product meets the client’s expectations. If, for instance, we know that the application will be used by 10,000 concurrent users, the system will have to be tested based on that number of users, in order to check system response, tolerance and operation.
Should only large projects incorporate the concept of Performance Engineering? Actually, Performance Testing is a beneficial practice for projects of all types. It is specifically recommended for scenarios like the one above, with a large number of users. However, the truth is that there are also cases of applications with only ten users that are very “heavy” in terms of performance.
Currently, Agile methodologies predominate in software projects due to the need to deliver results in limited periods of time. In this aspect, having a Continuous Integration strategy that includes Load and Performance testing is key because it will help us to quickly identify if our app keeps performing the way it should guarantee all of our users will be able to interact normally with the system
The main limitation to adopting Performance Engineering is budget. Guaranteeing that the solution will continue to perform after some time calls for a production like environment similar to actual production –usually hosted in the cloud– and for specialized resources. However, there is an increasing number of democratizing solutions that make it possible for smaller projects to benefit from Performance Engineering: from the use of free tools to detect small performance problems to less expensive tests that can at least minimize those problems.
There is a second, cultural, obstacle: companies very often balk at investing in Performance Engineering just to discover, after a given release, that there are performance problems. That is why, as technology partners, we at Making Sense raise awareness among our clients, from the start, about the importance of this practice and its benefits, so that it becomes the norm in different projects.
The purpose of Performance Engineering is not only to improve the user’s experience and to sustain application performance in the long run. It is also a true relief for businesses from the numerous headaches created by low-performing applications, once they are in production.