Performance and security are typically only high on the list of priorities among those who test for them. Even in DevOps environments, you see that developers are very much focused on the functional aspect of what they are delivering – a missed opportunity, because by giving more prominence to performance and security within development teams, not only can the quality of the final product be improved, but ultimately the development process can also be speeded up.
It is often decided to test the performance and security of an application only at the end of a development process rather than during the process. I regularly see that this leads to problems in the production environment. In such a situation, there is more pressure on DevOps teams to solve problems that might have been prevented. A consequence is that at the end of the process, there is even less focus on testing. After all, the product needs to go live as soon as possible. This vicious circle is hard to break unless teams realise that by keeping performance and security in mind in the development process, they can actually save time in the delivery phase of the whole product.
Surprising insights
This requires a different mindset on the part of developers and means that the whole team needs to have greater knowledge of these disciplines. Developers can then view their product from a performance or security perspective, which can lead to surprising insights. For example, if as a developer you are looking at an application/partial application, the focus is always on the 'happy flow' of what you are delivering: is the most common path that the user needs to complete smooth? By contrast, a security tester will go looking for the vulnerabilities in that path and in other paths that could be taken to exploit a system. If developers are already familiar with the most common vulnerabilities, they will view the product very differently during development.
How do you achieve this? By giving testers responsibility for sharing the knowledge they have with colleagues. That way, the whole team becomes more aware of performance and security. This can be done, for example, by training developers and administrators. That way, they learn to think about the performance impact and the security of the application/partial application for themselves. Of course that doesn't mean developers take over the role of the testers, but it is possible to achieve quick wins that avoid delays in going live at the end of the process.
Testing after integration
By raising awareness, you work towards a situation in which performance and security, like functional testing, become an integrated part of the development process within DevOps. You could even go a step further by automating these tests within the teams. In this case, testing after the integration of all the components can be fully focused on overall performance and security.
This is an ideal situation which is very uncommon in practice. But ultimately it results in a better product that is completed more quickly. In other words, it's an opportunity that organisations should seize with both hands.