Difference between Severity and Priority of a defect has been the most common question for Software Testing job interviews. This is one topic; even very senior managers have conflicting views sometimes.
Defect Severity
Defect Severity signifies degree of impact the defect has on the development or operation of a component application being tested. It is the extent to which the defect can affect the software. The severity type is defined by the Software Tester based on the written test cases and functionality.
Defect Severity may range from Low to Critical
- Critical – this defect is causing system failure. Nothing can proceed further. It may also be called as a show stopper
- Major – highly severe defect, is causing the system to collapse, however few parts of the system are still usable, and/or there are a few workarounds for using the system in the collapsed state too
- Medium – is causing some undesirable behavior, however system / feature is still usable to a high degree
- Low – is more of a cosmetic issue. No serious impedance to system functionality is noted
Defect Priority
Defect priority signifies the level of urgency of fixing the bug. In other words Priority means how fast/ how soon it has to be fixed. Though priority may be initially set by the Software Tester, it is usually finalized by the Project/Product Manager.
Defect Priority may range from Low to Urgent
- Urgent: Must to be fixed before any other high, medium or low defect should be fixed. Must be fixed in the next build.
- High: Must be fixed in any of the upcoming builds but should be included in the release.
- Medium: should take precedence over low priority defects and may be fixed after the release / in the next release.
- Low: Fixing can be deferred until all other priority defects are fixed. It may or may not be fixed at all.
Differences between Defect Severity and Defect Priority
|
Severity
|
Priority
|
|
Severity is associated with standards/functionality.
|
Priority is associated with scheduling.
|
|
Severity refers to the seriousness of the bug on the functionality of the product. Higher effect on the functionality will lead to assignment of higher severity to the bug.
|
Priority refers to how soon the bug should be fixed.
|
|
Generally, the Quality Assurance Engineer decides the severity level.
|
Priority to fix a bug is decided in consultation with the client/manager.
|
Examples;-
- Let us assume a scenario where “Login” button is labeled as “Logen”:
The priority and severity for different situations may be expressed as:-
· For GUI testing: it is high priority and low severity
· For UI testing: it is high priority and high severity
· For functional testing: it is low priority and low severity
· For cosmetic testing: it is low priority and high severity
- Low Severity, Low Priority
Suppose an application (web) is made up of 20 pages. On one of the pages out of the 20 which is visited very infrequently, there is a sentence with a grammatical error. Now, even though it’s a mistake on this expensive website, users can understand its meaning without any difficulty. This bug may go unnoticed to the eyes of many and won’t affect any functionality or the credibility of the company.
- Low Severity, High Priority
· While developing a site for Pepsi, by mistake a logo sign of coke is embedded. This does not affect functionality in any way but has high priority to be fixed.
· Any typo mistakes or glaring spelling mistakes on home page.
- High Severity, Low Priority
· Incase application works perfectly for 50000 sessions but beings to crash after higher number of sessions. This problem needs to be fixed but not immediately.
· Any report generation not getting completed 100% – Means missing Title, Title Columns but having proper data enlisted. We could have this fixed in the next build but missing report columns is a High Severity defect.
- High Severity, High Priority
· Now assume a windows-based application, a word-processor let’s say. As you open any file to be viewed it in, it crashes. Now, you can only create new files but as you open them, the word-processor crashes. This completely eliminates the usability of that word-processor as you can’t come back and edit your work on it, and also affects one of the major functionalities of the application. Thus, it’s a severe bug and should be fixed immediately.
· Let’s say, as soon as the user clicks login button on Gmail site, some junk data is displayed on a blank page. Users can access the gmail.com website, but are not able to login successfully and no relevant error message is displayed. This is a severe bug and needs topmost priority.
Fantastic description….
very nice explanation …
Very Helpful
Thank you all….
useful
thanks
good explanation
very well explained…!!!!
ty so much
Best ans I was searching for.. Thanks a lot!
Good one.Really helpfull
your explanation very help full to me
Tysm
Nice article, but there may be another way of looking at this.
Although these two terms have been used to describe defects since the beginning of software development and testing, there are still many discussions on how to set these two defect terms.
I have been in the testing field for over 20 years, using many different testing tools and in many different organizations both public and private from which I have developed a way to define these fields based on the test phase that has been very affective and that both business and development teams can agree with.
Severity:
• Severity is set based on the technical aspect of the failure during all test phases.
Priority:
• During SIT – set to indicate the fix order of the defects, when there are multiple defects for any given severity level.
• During UAT – set based on the business requirement.
• Combined SIT/UAT – set based on QA and Business agreement.
Development Fixed and Delivered
• During SIT the development team will fix defects based on severity and then priority.
• During UAT or combined SIT & UAT the development team will fix defects based on Priority.
That's good piece of information.
Thanks dear…