Performance Testing

Performance Testing: How To Increase Its Priority

I have been watching videos and LinkedIn posts on performance testing and how the priority given to it has been on the downward trend in the past years. It is not very surprising as product teams and the customers have become apathetic to the performance issues. In this blog, let’s look at why performance testing is not given priority, and what can be done about it.

There is an impression that the infrastructure has moved to cloud and either there is no need to consider performance or the cloud service provider will take care of it – shocking, but true. There is a feeling that the infrastructure has ‘gone out of control’ of the product team because it has moved to the cloud, and there is really nothing much that can be done to improve performance attributes.

James Pulley wrote a nice LinkedIn post some time back highlighting how multi-tenanted systems in the cloud are the hard ones to measure performance for on an individual software basis, and how service level agreements have to be written to cater for individual software and not for the entire systems, as software is getting distributed and micro-services are orchestrated (keep moving) by platforms like Kubernetes.

In last week analysis by Scott Moore on 2022 World Quality Report, he highlighted the fact that many headings in the survey didn’t have performance as a priority. While keywords like Agile, DevOps, etc. seem to take high priority, the core design considerations like Performance, Security, etc. seem to be not highlighted or not in the attention of the stakeholders of many companies. Scott recommends that the basics of performance engineering and performance testing have to be made important, and I agree. Software Engineering team members as well as Product Owners, business analysts, supporting teams, as well as customers need to pay attention to performance engineering aspects.

How can this be done? Well, as with any ‘tests’ related to any area of the software, the performance requirements need to translate into tests, such that the tests pass or fail based on whether that requirements are taken care of in the code. Code, from day one, should be written based on the requirements of design considerations (including performance). TDD is a great way of doing this.

How to make developers do this? If your organisation has a culture of collaboration between relevant stakeholders through methods like Ensemble Programming, it is very easy to implement. Performance experts can take part in Ensemble Programming and suggest which requirements need to be included in the validation tests from a product perspective. These performance requirements can be written in BDD. I have been requesting Scott, James, and all the performance experts to toy with Ensemble Programming sessions so that we get used to test-first in product teams. I hope to see some action on that front in the near future.

Hope that gives you some thoughts and ideas about implementation of performance engineering while the product is being developed. For product testing strategies, feel free to contact me.

Leave a Comment

Your email address will not be published. Required fields are marked *