How to Categorize Performance Testing Defects

Within manual/automated testing, testers boost defects in a bug tracking tool, modern strategies such as Agile, or tools like Jira to generate user stories and/or pests. Each defect has two important particulars: priority and severity. Priority defines how soon the defect has to be fixed. Severity identifies how critical the problem is.

A famous example to differentiate between seriousness and priority is the invalid dimension of a custom logo in the header. The company logo carries the brand and value — if the logo dimension is not right, surely, it is a defect. Any time raising a defect, the tester will assign these severity and priority as Trivial and Critical correspondingly.

The reason for this variety is the sizing of the logo will not impact the actual business functions. Users it’s still able to perform the procedures. But the priority to fix the defect is ASAP, i. e. critical. Developers need to fix the dimensions ASAP in the immediate build. Now, let’s discuss performance problems.

Sample Case Study

Assume that you are testing a simple web-based taxi cab reservation application. Critical business flows will be Enrollment, Login, Booking a ride, Account, Payment, Help, Driver’s Registration, Driver’s History, Payment, Reports, Disputes, and so forth An individual will be testing twenty-five scenarios to validate the performance.

Technical Solution design states 3 seconds as the SLA objective for all the pages. When the performance testing exercise is completed, you observed that there are variances in the response time in the scenarios.

Now fit, how do you raise your performance defects: in JIRA, QC, Bugzilla, or your selected bug tracking tool?

Exactly what will the severity and priority be for each and every defect/story? This article will tackle those.

How to Classify Performance Testing Defects

A person need to define the performance testing well in advance of time with the aid of your architects or business experts (not developers). From my agile experience, I would try to categorize the performance testing defects into four categories: Blocker, Critical, Main, and Minor. You can ignore trivial things.

Blocker

Assume that you got a new code deployment in your test environment. As soon as you launch the web page, it is taking more than 5 seconds for the first paint, and you a chance to render the complete page in Internet Explorer is more than 10 seconds, which is a complete blocker for your checks. Through the load, definitely it will bring more issues to the table. With out proceeding with your tests, you can simply raise this defect as a complete blocker.

Critical

Assume that you want to complete a booking with your on line application. After the user keys to press on the “Submit” button, they expect to get a legitimate booking order ID. Throughout the load, if the booking order ID is if she is not made or an invalid booking ID is generated, then your complete transaction has a critical defect. Also, if the response time is exceeding 30-50% of the actual SLA, you can boost a defect as Essential.

The main intention of testing your web application is to see whether all the users are able to book and obtain a valid order IDENTIFICATION. If the majority of the purchases are failing, then you should raise a critical defect.

Significant

If any of the major functionalities has a workaround but it needs to be fixed by developers, you can categorize this concern as a significant defect. With regard to example, if you are not able to access a page which should not be visited, but it can be navigable by using a shortcut key or directly loading the page, then you can raise this as a major defect.

Minor

USER INTERFACE defects, grammatical errors, punctuational mistakes, alignment issues, etc . can be categorized as minor or trivial. Furthermore, the response time violation in conditions of very minimal value (1 or 2 milliseconds), you can raise this concern as minor or trivial.

I work as a Senior Testing Specialist at TestingXperts. I handled day-to-day operations for all aspects of software testing. With over 7 years of professional experience I know how to build strong connection with the clients and testing capability. Load Testing Services plays an important role in the development of new IT programmes and many every day products, like cars and electronic goods.