Severity in Testing vs Priority in Testing

In software testing, a bug is the most critical entity. The most important attributes that can be assigned to a bug are priority and severity. They help teams to efficiently fix bugs and go through the release scheduling processes without letting any critical issues fall through the gaps. The article focuses on discussing the difference between Severity and Priority in testing.

What is Severity?

Severity is defined as the extent to which a particular defect can create an impact on the software. Severity is a parameter to denote the implication and the impact of the defect on the functionality of the software.

• A higher effect of the bug on system functionality will lead to a higher severity level.
• A QA engineer determines the severity level of a bug.

Types of Severity:

Severity in software testing can be classified into 4 categories:

• Critical: This severity level implies that the process has been completely shut off and no further action can be taken.
• Major: This is a significant flaw that causes the system to fail. However, certain parts of the system remain functional.
• Medium: This flaw results in unfavorable behavior but the system remains functioning.
• Low: This type of flaw won't cause any major breakdown in the system.

What is Priority?

Priority is defined as a parameter that decides the order in which a defect should be fixed. Defects having a higher priority should be fixed first.

• Defects/ bugs that leave the software unstable and unusable are given higher priority over the defects that cause a small functionality of the software to fail.
• It refers to how quickly the defect should be rectified.

Types of Priorities:

Priority in software testing can be divided into 3 categories:

• Low: The defect is irritant but a repair can be done once the more serious defects can be fixed.
• Medium: The defect should be resolved during the normal course of the development but it can wait until a new version is created.
• High: The defect must be resolved as soon as possible as it affects the system severely and cannot be used until it is fixed.

In software testing, just as understanding the distinction between severity and priority is crucial for effectively managing bugs, having a strong grasp of overall testing strategies is essential for ensuring software quality. If you're looking to deepen your understanding of these concepts and more, consider exploring the Complete Guide to Software Testing & Automation by GeeksforGeeks . This course provides comprehensive insights into all aspects of software testing, helping you not only differentiate between severity and priority but also master the techniques needed to prioritize and fix defects efficiently, ensuring a smooth and reliable software release process.

Severity vs Priority

Below are the differences between severity and priority:

Examples of Priority and Severity Combination

There are possible combinations of priority and severity:

1. High Severity High Priority: Consider an example of a web application where the if after filling in the login details, the user cannot click the login button then this is the case of high severity and high priority.

• High Severity: If the login button is not clickable then the whole application is blocked and none of the functions can be accessed by the user
• High Priority: If the login button is not clickable this means that the application is not letting any user log in then what is the use of such an application? Such defects are high-priority defects as the users will avoid such applications and businesses will be impacted.

2. High Severity Low Priority: Consider the example of the application being used on the older versions of Internet Explorer say IE8. This is a case of high severity and low priority.

• High Severity: The fault, in this case, is of high severity because when the application is accessed on the older version, the page will not load properly and a few fields and text will be overlapped thus whole application will be impacted.
• Low Priority: The defect is of low priority because very few actual users use IE8 or older versions so the fix can wait.

3. Low Severity Low Priority: Consider the example of the help or faq section of the website where the theme or font style of a section of the page does not match with that of the rest of the page.

• Low Severity: The defect is of low severity as the defect is not affecting the website functionality.
• Low Priority: The defect is of low priority as not many users will access this particular section of the website so the fix can wait.

4. Low Severity High Priority: Consider the example when there is a typo on the website. For example, the case of the school website where the 'Admission Form' is misspelled as 'Admission from'.

• Low Severity: The defect doesn’t break functionality-the page and form still work; it’s a UI/text issue.
• High Priority: It’s business-critical and user-facing (core CTA), hurts credibility and conversions (admissions), so it must be fixed immediately.

Defect Triage

Defect triage is the process where each defect is prioritized based on its severity, frequency, risk, etc. The goal is to evaluate, prioritize, and assign the resolution of defects. This is mainly used in agile project management. The defect triage meetings frequency depends on a number of factors:

• Project schedule.
• Overall project health.
• The number of bugs in the system.
• Impact on schedules of team members' availability.

The defect triage process can be summarized as:

1. Defect Review: This step involves reviewing all the defects including the defects that were rejected by the team.
2. Defect Assessment: This step involves an initial assessment of the defects based on the content and respective priority and severity settings.
3. Defect Assignment: This involves prioritizing the defects, and assigning the defects to the correct release by the product manager.