Severity and priority of a defect come into play when a defect or bug, detected in the software, is logged into the bug report. Any issue in the software that can impact it or fix it can improve the software in any way is considered as a defect or bug.
So once a defect is logged, it is necessary to set its severity, which is the level of impact the bug has on the software and the priority, which means that ‘how soon the bug is required to be fixed?’.
This information let the development team find out the next most important bug to fix. In this article, we will discuss the difference between Severity and Priority.
What is Severity?
The severity of a defect defines the level of impact it has on the functionality of the software. The tester is the one who decides the severity of the defect.
It is based on the technical aspects of the defect up to what level it is raising obstacles in performing operations on the software.
Along with that, the level of severity also explains the impact of the defect on the quality of the software.
Types of Severity
A defect is considered as critical when it completely stops the working of the rest of the software. This kind of defect prevents a user from accessing other software functionalities and there is no other way to do so. Error in the functionality of Login Page in any website is one such example, as the user cannot operate the software without logging in.
A major defect is also the one that completely stops the functioning of the whole or some components of the system, but there is some alternative path available for the user to access the rest of the software’s functionality and complete the task.
A minor defect does not stop the functioning of the rest of the software but it is assigned to the one that leads to the incorrect and inconsistent behaviour of a functionality. In simple words, the software is working but not correctly or as desired.
A low severity defect is more of an enhancement suggestion that can improve the user experience and efficient working of the software. These defects do not raise any obstacle in the current working of the software and hence regarded as low.
What is Priority?
The priority of a defect explains ‘how soon the defect is required to be fixed?’. It let the development team schedule the resolution of the bug.
It is not only decided on the defect’s impact on the functionality, but also the business and management of the software. The project manager is responsible for prioritising a bug considering the other bugs in the open state.
Types of Priority
A defect that requires urgent resolution is given the highest priority. Such defects stop the workflow of the entire or some important functionality of the software and the user is unable to use the software or functionality until the fix is done.
A high priority defect is required to be resolved as soon as possible since it is affecting the rest of the software adversely and is important for the user’s and client’s business.
Check out the insights of Roles and Responsibilities of Desktop Support Engineer
Such defects can wait for resolution till the next version or build of the software is ready. Currently, they are not raising any big issue and do not have a major impact on the user’s or client’s business. Functionalities that are rarely used can be assigned medium priority.
A low prioritised defect is resolved once all the higher prioritised defects are fixed.
Levels of Severity and Priority
1. High Priority, High Severity
A defect that has a major impact on the user’s and client’s business is kept in this category. Such defects put the testing of the rest of the software on hold and require immediate resolution as there is no alternative available to continue the working.
Payment failure issues is an example of high priority and high severity defects for an e-commerce website.
2. High Priority, Low Severity
The defects that require immediate correction but do not have any impact on the functioning of the software. A mistake in the logo of the website might affect the working of the software and affect the reputation of the client and hence should be fixed soon.
3. High Severity, Low Priority
The defects that affect the functionality of the software but since the features are used rarely by the user, so can be resolved later in the next build or update of the software.
4. Low Severity, Low Priority
The defect that does not affect the functionality of the software but still should be corrected. A mistake in the spelling of some content or correction in the look of the software.
Severity and Priority Difference
|The severity of a defect depends upon the bug itself.||The priority of a defect depends upon its expected impact on the customer’s and client’s business.|
|It is also known as an intrinsic quality of the bug.||It is an extrinsic quality as it depends upon the understanding of the developer, client and project manager that ‘how soon they think the bug should be fixed?’.|
|The defect’s severity is decided by the one who logged it in the bug report, mostly it is the tester.||The developer with the stakeholders decides ‘where the defect should lie in the priority list to get fixed?’.|
|The severity of a bug does not depend upon the other existing bugs, every bug has its level of impact on the software and cannot be altered because of the other.||A bug is given its priority based on the other existing bugs to find out the bug which should be fixed first.|
|Severity once fixed generally does not change until the correction process is completed.||The priority of a bug can be changed during the process by the developer or project manager, as per their understanding and discussion with the stakeholders.|
|Some common types of severity are Critical, Major, Minor, Low, Enhancement.||Some common types of Priority are Immediate, High, Medium, Low.|
|Setting a bug’s severity as critical or medium does not indicate that it will be fixed first.||Setting a bug’s severity as Immediate, High ensures that it will be fixed as soon as possible.|
The level of priority and severity are responsible for the scheduling of the resolution of a bug or an enhancement suggestion. It is important to understand the difference between severity and priority for realising the impact a defect is causing on the software.