by Rashi Arora

Software testing methodologies and defect management techniques have taken an immense leap in the last couple of years and continue to do so by adding new perspectives to successful software development.  Despite this, there always seems to be a lingering ambiguity about certain parameters of defect tracking.  Defect Priority and Defect Severity are two of these.

Defect Priority and Defect Severity are two entirely distinct ways of categorizing software defects which influence the order in which the defects should be fixed.  Many times the defects are categorized by using only one of these. It’s not a very common practice to use both of these terminologies and not everyone does so.  This is essentially due to the confusion in understanding the meaning and significance of each of these.   But there is a significant difference, and both the terminologies if used, give precise information to defect definition.

Let’s learn more about these differences here!

  • Defect Severity primarily refers to the impact a defect creates in hindering the intended functionalities of the software. This also includes the probability of its occurrence. Both impact and probability compositely decide a defect’s severity.
  • Defect Priority refers to the urgency required in fixing/addressing the defect. Priorities for fixing defects keep changing based on project’s stages/phases.  Testing priorities take precedence during early stages followed by the priorities of the client when the project is nearing its completion

Defect Severity can be categorized as

a)      Critical /Showstopper/S1: These include the catastrophic bugs that could potential crash the system and there is no workaround for them. All testing efforts are completely suspended until these are fixed. For e.g. – memory leaks , data loss , security issues

b)      Major/S2: These bugs affect the major functionalities of the system affecting major modules. There can be workarounds available in this case and testing efforts are suspended for only the affected modules once such defects are encountered

c)       Minor/S3: These defects affect small individual functionalities of the system that have a workaround. Testing is not significantly impacted here.

d)      Trivial/S4: These are essential cosmetic defects that do not impact any functionality and do not require a workaround. Testing is not impacted in such cases.

Defect Priority on the other hand is categorized as

a)      High: High Priority bugs require immediate fixing as these may impact test execution or critical functionalities considerably

b)      Medium: Medium priority refers to the bugs that need fixing soon. These impact important functionalities but test execution is not impacted and there can be a workaround to carry that further.

c)       Low: These defects are the ones that do require fixing but not before high and medium ones are fixed. 

Confusion in understanding the above terminologies leads to conflicts between the testing and the development teams due to incorrect categorization and acceptance.  But using the above information as guide can assist both the teams in interpreting the defect details correctly and thereby making appropriate on-time efforts to deliver a product of high quality.