How to Categorize Software Performance Testing Defects

In manual/automation testing, artisans raise defects in a bug tracking software, contemporary methodologies like Agile tools or tools, for example, Jira to make user stories and/or bugs. Each flaw has two important details: concern and seriousness. Concern defines just how long the defect needs to be mended. Severity defines how critical the flaw is.

A famed example to distinguish among seriousness and priority would be your judicious measurement of the logo design in the header. The company logo conveys the brand and value -- even whether your logo measurement isn't right, definitely, it's a defect. When lifting a flaw, the tester will assign the following seriousness and concern as Trivial and Crucial respectively.

The reason for this specific variety could be the size of the logo won't impact the true small business purposes. Clients will nonetheless have the ability to do the operations. But the priority to fix the flaw is ASAP, i.e. crucial. Developers should resolve the measurements ASAP from the instantaneous build. Today, let us talk about operation defects.

Some Example

Assume that you are software performance testing a simple online cab booking program. Critical Small Business flows will soon be Registration, Login, Booking a ride, Account, Payment, Aid and Driver's Registration, Driver's History, Payment, Stories, Disputes, etc. You will be testing 25 situations to validate that the operation.

Specialized Solution design states 3 seconds because of the SLA objective for all the web pages. When the operation testing exercise has been performed, you observed there are variances in the response period from the situations.

Today the inquiry is, how do you increase your operation defects: at JIRA, QC, Bugzilla, or your own favorite bug tracking tool?

What will the seriousness and priority be for every single defect/story? The following guide will address individuals.

The way to Categorize Software performance Testing Defects

You need to specify the operation testing effectively ahead of time with all the help of one's architects or business analysts (not programmers). From my agile experience, I'd try to categorize the operation analyzing defects into four categories: Blocker, Crucial, Major, and small. You may ignore insignificant matters.

Blocker

Think that you simply got a fresh code setup in your evaluation environment. Once you launch the page, then it is shooting over 5 seconds for the very first paint, and the opportunity to render the comprehensive page in i.e. will be more than 10 minutes, and it is a comprehensive blocker to receive the tests. 

During the loading, unquestionably it'll attract more problems into this table. Without proceeding together with your tests, you may readily elevate this flaw as a complete blocker.

Critical

Think which you're attempting to complete a booking with your web application. Subsequent to an individual click on the “Publish" button, they hope to find yourself a valid reserving sequence ID. During the load, even if the booking order ID is not currently being made or the invalid booking ID is generated, in that case, your entire trade includes a critical defect. Also, if the answer time is exceeding 30-50% of the real SLA, you can raise a defect as Crucial.

The most important aim of analyzing your web application would be to check if all the users are able to reserve and get a valid purchase I’d. In case many of the transactions are neglecting, you then should elevate an essential defect.

Key

If any of the important functionalities comes with a workaround but it needs to be mended by developers, you'll be able to categorize that this issue as being a big defect. As an instance, if you aren't equipped to access a full page that cannot be clicked, but it might be redeemed having a dictionary key or right loading the page, then you're able to increase this because of an important defect.

Minor

UI defects, grammatical errors, spelling errors, alignment issues, etc. be categorized as insignificant or minor. Moreover, the response time breach in conditions of very minimal price (1 or two milliseconds), you can raise this concern as minor or trivial.

Summary

It is crucial to optimize performance testing flaws prior to the implementation. The above-mentioned categorization heavily changes from project to project. That is no principle of thumb that has to be adopted. To get Google-like websites, the milliseconds matter, so think wisely and formulate precisely the flaw types.