Course Process

Defect Severity & Priority in Testing

Defect tracking has one of the important aspects of the Defect Life Cycle. The testing team may rise many bugs while testing the software out of which some would be extremely critical to fix, some may have less importance. Ultimately all the bugs have to be fixed, but it is important that the critical bugs should not be present in the software, so they need to be fixed first followed by fewer important bugs. Thus, to track the defect by its importance severity and priority is defined for every defect.


Defect Severity:

It could be defined as how extreme the impact of the defect is on the functionality of the application. A higher effect on the system functionality will lead to the assignment of higher severity to the bug. Quality Assurance engineer usually determines the severity level of defect. The defect severity could be categorized as:

1. Critical: A bug or defect which has a major impact on the functionality comes under this category. Any functionality or major system component is completely broken which blocks the testing of the feature. They are also called as blocker defects as they block the further testing. For example, the system crash on try to open a particular page/tab.

2. Major: A bug or defect which is major in nature, but they do not block the testing of the functionality. Another possible cause can be the functionality is working but not as per the requirement or expectations. For example, Any particular field is missing from a page.

3. Minor: Any bug or defect which has very less impact on the functionality of the application, but it has to be fixed. Example, spelling mistake in the field name or error message.


Defect Priority:

It is all about prioritizing the defects means, defining the order in which bugs should be fixed. High priority defects are first picked up by the developer for fixing. Defects are mostly prioritize based on the customer’s point of view. The defect priority could be categorized as:

1. High: Any defect which needs to be fixed as early as possible as it has a major impact on customer business is set as a high priority. High priority defects are been prioritize over defects in order to get fixed. For example, Logo is missing from the application.

Medium: This kind of defect is one level below the high priority defects. These are the defects that need to be fixed before release but not immediately. An example of this would be the major and minor category severity defects.

3. Low
: A defect which has negligible or no impact on the customer business belongs to low priority. Defects of less priority should be fixed only after other important defects like high and medium priority defects are resolved


A defect would belong to any of these four sections

High Priority High Severity: Any defects which break the basic functionality of the application and will not allow the user to use the system. All the critical and some of the major defects belong to this category. For example, while trying to save records in the database throws an error response.

High Priority Low Severity
: Any defect which effect is very less on the functionality of the application but has an impact on the customer experience. These issues also need to be fixed as soon as possible. For example, the logo of the application is missing.

High Severity Low Priority
: This happens when the bug causes major problems in the application, but it only happens in very rare conditions or situations. These defects have to be fixed but not immediately. For example, some JavaScript does not work in a very old browser which is rarely used.

High Priority Low Priority:
Any cosmetic or spelling issues which are within a paragraph (Not on the cover page, headings, title, etc.) or any particular section takes more time to load in the browser. It does not have any impact on the functionality of the application. For example, the privacy policy page takes a long time to load, which is not used by many users.