Defect Priority, Defect Severity and their Differences

A Software Test Defect is one of the most important QA artifact of the testing process. Software QA Testers routinely log defects as soon as they notice any deviations in the system's behavior. Every defect is reported with a set of attributes that give the information that lets a programmer or another tester reproduce it. Of these attributes, defect priority and defect severity are the most important ones. Lets understand what each one signifies, and where they do differ in...

Defect Priority

Defect Priority signifies how important it is to fix this defect. Can the fixing of the defect wait? Is it a show-stopper, if it is not fixed, nothing can be used / tested kind? The defect priority should signify the pace at which the fixing of this defect is expected. The typical values which defect priority takes in order of importance are:

• Show-stopper - this needs to be fixed right now, everything else can wait, the build cannot be released with this defect
• Urgent - needs to be fixed before any other high, medium or low defect should be fixed
• High - should be fixed as early as possible
• Medium - should take precedence over low priority defects
• Low - fixing can be deferred until all other priority defects are fixed
  

Given a number of defects of the same severity, its the priority on whose basis the team will pick up the defects for fixing. For example suppose the team has 3 open defects, all are of the same severity, but one defect (D1) is Show-stopper, one (D2) is of medium priority and one (D3) is of low priority. The team will pick the D1 defect for fixing first as that has the highest urgency of fixing (show-stopper), followed by D2 (Urgent), and finally D3 (Low).

As such it is important that an accurate determination is made of the correct priority of any defect at the time of logging.

Defect Severity

Defect Severity signifies the criticality of the defect. It signifies the impact the defect is having on the functioning of the system as a whole. Severity takes different values depending upon the magnitude of the impact / failure the defect us causing. The more catastrophic the failure and greater the impact to the test case, the greater the severity of the defect. The typical values defect severity takes in order of impact are:

• Critical - this defect is causing system failure. Nothing can proceed further
• 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
• Average - is causing some undesirable behavior, however system / feature is still usable to a high degree
• Minor - is more of a cosmetic issue. No serious impedance to system functionality is noted

Different software / test organizations use different scales for representing defect priority (P0, P1, P2, P3 & P4) and defect severity (S1, S2, S3, S4) etc, but the underlying concept is the same.

Now lets come to the question of whether defect priority or defect severity remain constant over the lifetime of a defect or test cycle? The answer surprisingly is a NO. Defect priority and defect severity can both change over a period of time. More so in the case of defect priority. For example consider a defect related to the misspelling of the product name in the title / logo screen of an application. Assuming this defect has been found 6 months before a release, the tester assigns it a low priority (as it is a cosmetic change) and low severity (causes no issues with the system's functioning). Now lets race ahead by 5 and 1/2 months, and we have the product being released in 2 weeks to the users. Will the defect still have low priority? It will not, the team will jack up the priority to Urgent to have it fixed asap, as the product cannot be released with a mis-spelled title as that would speak low about the quality of the system.

Now lets come across the differences between defect priority and defect severity. Are they always same? If a defect has high priority, will its severity too be high? And vice-versa too? The answer is again an emphatic NO. Both of them are unrelated to each other. Defect priority and defect severity are both independent of each other. You can easily have highly severe defects with low priority, and low severity defects with high priority. Consider the following examples to make this more clear:

Defect with a High Priority, but Low Severity
A misspelling or typographical error that is present on a screen. This has minimal user impact, and can be fixed very quickly.

Defect with a Low Priority, but High Severity
A system crashes while using the legacy feature of "Abc Functionality" when used with a non-recommended browser (say FireFox). Severity wise this defect is high as it causes the system to crash, but priority wise the team decided to mark it low as it has been reported on a non-recommended browser, and the feature which is being used is a legacy feature which is not used very frequently, if at all by the majority of the user base.

Test Exercise

Now that you are clear with the concept of Defect Priority and Defect Severity, how about tackling this exercise. Assuming we have 5 defects with the below mentioned defect priority and defect severity, in what order would you fix them?

Defect Number	Defect Priority	Defect Severity
D1	High	Minor
D2	Low	Critical
D3	Medium	Critical
D4	High	Major
D5	Show-stopper	Minor

Let me know in what order would you fix these defects. Enter your order in the form of a comment below along with the reasoning you considered.