Thursday, December 7, 2017

How to create front-end performance Test Cases and beyond

Front-end performance testing is crucial when considering today’s performance testing and engineering domain. Now a days we are more or less into the web base application implementation and testing. Hence we need to look at client side performance while we are taking care of the server side (Back-end).

As quality assurance engineers, we are more methodical. Whatever things we have to test, we tend to create a test case in order to keep the test results visible and manageable. And also, QAs are using these TCs to get the history of that feature as well as (considering a performance test) we can take the benchmark of the figures which were there before the optimization. So we can compare results and show to our customers as they are keen on the ROI.

In this blog, I am going to describe and show you how to create an initial front-end performance test cases which you can use for performance testing. The main motivation behind these test cases is to avoid the unprofessional way of doing it.


First of all, lets have a look at following cycle which discribe all the areas including mitigation.



1. Info/Data: First of all, you need to read articles, books, blogs to get the data and information to do this. Without the knowledge, you cannot create any valuble scenarios.

2. Learn / R&D: Then, you need to learn from them and do the R&D stuffs to clear things. Get the idea behind it and properly structure the knowledge base.

3. Create TCs: Now you have proper knowledge to create test cases. So create those according to your domain, SLA, etc. But there should be common practices.

4. Execute/Assess: We need to execute the test cases with the SUT (System Under Test) and update the TCs. Make sure to mention all the performance values in the comment area. And also take screen shots if necessary (I prefer it’s good to take screen shots).

5. Log: All the finding should be logged after you had a chat with your developers. So this should be a collaborative approach and not a single decision.

6. Optimize: After you know that there is an issue, and after you log it in your tracking tool (e.g.: Jira), developers can work on that. So developers are fixing this and then QAs are testing with the benchmark to check that is there any improvement.

According to my experience, do not create separate hardening sprints to fix those non-functional issues. What we can do is, if you are fixing 10 functional issues in your sprint, take only 9 and pick one from the non-functional backlog.

7 Re-assess: After all the improvements are fixed, then QAs can do another round of official test to check the results. In here, make sure to update your test cases with new figures so that all the stakeholders can see that.

Likewise, the cycle should execute regularly.


So let’s start describing front end test cases from now on. There are test cases I have created upon my requirements so you can have your own test cases.

1. As the first part of my test cases, I have selected to validate the front end performance rules as it is utmost important. Targeting Web and mobile apps.







































2. And then, I am referring to analyze how content size, type, and global rate as well as analyze how user see the performance and timing. In this case I have used 2 very popular tools which freely available.





























3. As the 3rd area, I have selected to analyze the Critical Rendering Path (CRP) using manual analysis and using the lighthouse tool in the Chrome browser. In this case we need to manually analyze the CRP and find issues. As well as from the lighthouse tool, there are good options to check the CRP.












Hope you got an idea about Front-end testing, test case writing and beyond. And make sure to create your own TCs according to your requirements. And please share all those with us coz then we also can learn from it.


No comments:

Post a Comment