Series: QA in Agile SDLC (#2)
QA and application performance!
Test client & server side performance of the product.
In case you missed the first part of this story, here it is.
In this part, I will be touching upon performance testing.
Website performance plays a huge role in customer retention. Based on my experience on a few projects, I will be discussing performance testing of web applications.
This is a vast field in itself, an umbrella term covering client & server side performance testing. There are various flavours of server side performance testing:
- Spike tests.
- Endurance tests.
- Load tests… and many more .
Depending on what the team needs at the time, you might need to delve deeper into one of them. I will now share my understanding on the following two subtopics that can help people take things further.
Server side performance testing :
Every team will have its own requirements to see if the SLA is being met or not. In one of my gigs, I owned this fully; right from choosing the tool, defining the scenarios, executing them, analysing the results and fixing issues.
During performance testing, certain parameters one can focus on are:
- Response times.
- Success rate against the number of requests in a specified period of time.
- Mean time to recover in case of application failure.
- Latency.
The expected application user load can be figured out from the stakeholders as well as by monitoring the application. Accordingly, we can decide the number of users to be simulated in a specified time period.
If your website caters to requirements such as “Short term offers”, “Midnight Sale”, where very high customer traffic is expected, you should make sure that the system performs gracefully in such times and is adequately performant.
Page performance testing :
This is where client side performance is evaluated.
There are many plugins that help test page performance manually. LightHouse is one of them. It can give a plethora of information to improve page performance.
Additionally, it will also give helpful information on accessibility status of the website.
We might want this process automated. Download and analysis of HAR (HTTP Archive format) is how you can achieve this. One of the many ways is, using Firefox extension “netexport” which has now been upgraded to “har export trigger”. One can automate the browser headlessly and use the extension to download the HAR, or integrate this with the existing automation suite.
HAR file is formatted as a JSON. One needs to be careful with it since it contains sensitive data of your interaction with the website. Developer tools in browsers allow the HAR files to be downloaded manually as well. In order to analyse the HAR files the data points can be start time of the request, wait time, time when response was received, DOM load time, page load time, page size etc. Google provides a HAR analyzer which can be helpful in kick starting the analysis for you.
I hope this would help engineers get started on their path of performance testing.
In the upcoming article I will be focusing on my experience with application security.
