How to Categorize Web Performance Testing Defects

In manual/automated testing, artisans raise defects in a pest monitoring device, contemporary methodologies like Agile tools or applications, for example, Jira to create user bugs or stories. Each flaw has two major details: priority and severity. Concern defines just how long the defect should be fixed. Severity defines how significant the flaw is.

A famed illustration to distinguish amongst severity and endurance would be the invalid dimension of the company logo within the header.

The company symbol carries the value and brand -- even if the logo size is not appropriate, certainly, it is a defect. After lifting a flaw, the tester will assign the subsequent seriousness and priority as Trivial and Critical respectively.

The reason behind this particular variety is that the dimension of the logo is not going to impact the true small business functions. Users will still have the capacity to do the operations. But the concern to resolve the flaw is ASAP, i.e. important. Developers should resolve the dimensions ASAP at the instantaneous develop. Now, let's speak about performance defects.

Sample Case study

Suppose that you are testing an easy online cab reservation application. Critical business flows will likely be Registration, login, Booking a ride, Account, Payment, Help, Driver's Registration, Driver Heritage, Payment, Reviews, Disputes, etc. You will be analyzing 25 scenarios to confirm the performance.

Technical Option design conditions 3 seconds since the SLA objective for all the web pages. As soon as the web performance testing procedure is done, you observed there are variances in the answer period at the scenarios.

Now the inquiry would be, how exactly can you raise your operation flaws: at JIRA, QC, Bugzilla, or even your own favorite bug tracking tool?

What will the seriousness and priority function for every single defect/story? The following write-up will handle people.

The Way You Can Categorize Web Performance Testing Defects

You will need to define the QA software testing very well ahead of time with the assistance of one's architects or company analysts (not programmers). In my nimble expertise, I would attempt and categorize the operation analyzing defects into four types: Blocker, Crucial, Major, and small. You may ignore insignificant things.

Blocker

Think that you got a brand-new code setup on your evaluation environment. After you launch the page, it is shooting over five seconds for the very first paint, and enough time to leave the comprehensive page in Internet Explorer is 10 or more minutes, which is a comprehensive blocker to receive your tests. During the loading, unquestionably it's going to attract more issues to this dining table. Without moving along with your tests, you may readily boost this defect as being a comprehensive blocker.

Critical

Suppose that you are working to finish a reservation with your internet software. After an individual click on the “Submit" button, they hope you'll find a valid reserving order ID. During the load, even in case the reservation order ID isn't currently being created or an invalid booking ID is produced, in that case, your entire trade features a critical defect. In addition, in the event the response time is surpassing 30-50percent of the true SLA, then you might raise a defect as Critical.

The principal aim of analyzing your web application would be to see if all the users can reserve and get yourself a valid purchase I’d. In case most of the transactions are neglecting, then you should raise a critical defect.

Important

If any of the significant functionalities comes with a workaround but it has to be mended by developers, you're able to categorize that this dilemma as being a chief defect. For example, in the event that you aren't in a position to obtain a full page that cannot be clicked, however nevertheless, it might be navigable with a shortcut key or right loading the page, then you definitely may boost this because of an important defect.

Minimal

UI defects, grammatical mistakes, grammatical errors, working problems, etc. be categorized as trivial or minor. Also, the response time violation in conditions of rather minimal worth (1) or 2 milliseconds), you can raise the dilemma as trivial or minor.

Conclusion

It's important to optimize software performance testing flaws well before the implementation. The above categorization significantly changes from project to project. There is no rule of thumb that has to be adopted. For Google-like sites, even the milli-seconds matter, so think sensibly and invent precisely the flaw types.