How to Set Defect Priority and

Severity (with Defect Triage

Process)
Filing defects is a very integral part of the Software Testing Life Cycle. There are several
best practices defined for effective defect reporting over the internet or in organizations.
One of the important aspects of the defect life cycle on a generic level includes
defect tracking. The reason this is important is because test teams open several defects
when testing a piece of software which is only multiplied if the particular system under test
is complex. In such a scenario, managing these defects and analyzing these defects to drive
closure can be a daunting task.
In line with defect maintenance processes, when any tester files a defect- apart from the
method/description to reproduce the issue seen, he has to also furnish some categorical
information which would aid in accurate classification of the defect. This in turn would help
in efficient defect tracking / maintenance processes and would also form the basis for
quicker defect turnaround time.
The two main parameters that form the basis for effective defect tracking and
resolution are:

Defect priority
Defect Severity

These are often a confused concept and are almost used interchangeably amongst not only
test teams but also development teams. Theres a fine line between the two and its
important to understand that there are indeed differences between the two.
Lets understand briefly the theoretical definitions of the two parameters in the next section.

What is Defect Priority and what is Defect Severity?

Priority by the English definition is used in the comparative of two things or conditions,
where one has to be given more importance than the other(s) and has to be tackled
with/resolved first before proceeding to the next one(s). Therefore in the context of defects,
priority of a defect would indicate the urgency with which it would need to be fixed.

Severity by the English definition is used to describe the gravity of an undesirable

occurrence. Hence when it comes to bugs, severity of a bug would indicate the effect it has
on the system in terms of its impact.
Priority and Severity levels
Priority and Severity have some classifications amongst them that aid in determining how
the defect must be handled. A lot of different organizations have different defect logging
tools, so the levels might vary.
Lets take a look at the different levels for both Priority and Severity.
Priority:
As already discussed priority determines how quickly the defect turnaround time must be. If
there are multiple defects, the priority decides which defect has to be fixed and verified
immediately versus which defect can be fixed a bit later.
While opening a defect, the tester generally assigns the priority initially as he views the
product from the end user perspective. In line with these, here are different levels:

Priority 1 Critical (P1): This has to be fixed immediately within 24 hours. This

generally occurs in cases when an entire functionality is blocked and no testing can
proceed as a result of this. Or in certain other cases if there are significant memory
leaks, then generally the defect is classified as a priority -1 meaning the program/
feature is unusable in the current state.
Priority 2 High (P2): Once the critical defects have been fixed, a defect having

this priority is the next candidate which has to be fixed for any test activity to match
the exit criteria. Normally when a feature is not usable as its supposed to be, due
to a program defect, or that a new code has to be written or sometimes even
because some environmental problem has to be handled through the code, a defect
may qualify for a priority 2.
Priority 3 Medium (P3): A defect with this priority must be in contention to be

fixed as it could also deal with functionality issues which is not as per expectation.
Sometimes even cosmetic errors such as expecting the right error message during
the failure could qualify to be a priority 3 defect.
Priority 4 Low (P4): A defect with low priority indicates that there is definitely an
issue, but it doesnt have to be fixed to match the exit criteria. However this must
be fixed before the GA is done. Typically, some typing errors or even cosmetic errors
as discussed previously could be categorized in here. Sometimes defects with priority
low are also opened to suggest some enhancements in the existing design or a
request to implement a small feature to enhance user experience.

Severity:
Severity is a parameter to denote the implication of defect on the system how critical
defect is and what is the impact of the defect on the whole systems functionality? The
severity is a parameter set by the tester while he opens a defect and is mainly in control of
the tester. Again different organizations have different tools to use for defects, but on a
generic level these are the following severity levels:

Critical / Show Stopper (S1): A defect that completely hampers or blocks testing

of the product/ feature is a critical defect. An example would be in case of UI testing

where after going through a wizard, the UI just hangs at one pane or doesnt go
further to trigger the function. Or in some other cases, when the feature developed
itself is missing from the build.
Major or Severe (S2): A major defect occurs when the functionality is functioning

grossly away from the expectations or not doing what it should be doing. An example
could be: Say that a VLAN needs to be deployed on the switch and you are using a
UI template that triggers this function. When this template to configure VLAN fails on
the switch, it gets classified as a severe functionality drawback.
Moderate/ Normal (S3): A moderate defect occurs when the product or application
doesnt meet certain criteria or still exhibits some unnatural behavior, however the
functionality as a whole is not impacted. For example in the VLAN template deploy
above, a moderate or normal defect would occur when the template is deployed
successfully on the switch however there is no indication being sent to the user.

Low or Minor (S4): A minor bug occurs when there is almost no impact to the
functionality, but is still a valid defect that should be corrected. Examples of this
could include spelling mistakes in error messages printed to user or defects to
enhance the look and feel of a feature.

EXAMPLES OF SORTING DEFECTS WITH PRIORITY AND SEVERITY

High priority, high severity: Any defects due to which the testing cannot continue

at any cost or causes a severe system failure fall under this category. Say for
example clicking on a particular button doesnt load the feature itself. Or performing
a particular function brings down the server consistently and causes data loss. The
red lines in the above figure indicate these kind of defects.
High priority, low severity: Defects which have to be fixed but do not affect the

application come under this category. Say for example the feature is expected to
display a particular error to the user with respect to its return code. In this case,
functionally the code will throw an error, but the message will need to be more
relevant to the return code generated. The blue lines in the figure indicate these
kinds of defects.
High Severity, low priority: Defects which have to be fixed but not immediately.

This can specifically occur during ad-hoc testing. It means that the functionality is
affected to a large extent, but is observed only when certain uncommon input
parameters are used. Say for example a particular functionality can be used only on
a later version of the firmware, so in order to verify this the tester actually
downgrades his system and performs the test and observes a serious functionality
issue which is valid. In such a case the defects will be classified in this category
denoted by pink lines, as normally end users will be expected to have a higher
version of firmware.
Low severity, low priority :These defects are classified in the green lines as shown
in the figure and occur when there is no functionality impact, but still not meeting

the standards to a small degree. Generally cosmetic errors or say dimensions of a

cell in a table on UI are classified in here.

Setting the defect priority and severity

As already mentioned, since different organizations use different kinds of tools for defect
tracking and its related processes- it becomes a common tracking system between various
levels of management and the technical personnel.
Since defect severity is more within the purview of the functionality, the test
engineer sets the severity of the defect. At times the developers part-take in influencing
the defect severity, but mostly its dependent on the tester as he evaluates how much a
particular feature can impact the overall functioning.
On the other hand when it comes to setting defect priority, although initially the defect
originator sets the priority, it is actually refined by the Product Manager as he has
an overall view of the product and how quickly a particular defect has to be
addressed. A tester is not the most ideal person to set the defect priority.
Shocking as this may seem, here are two distinct examples as to why:
Example #1: Consider that there is a situation where the user finds a mistake in the
naming of the product itself, or some problem with the UI documentation. A tester would
normally open a minor / cosmetic defect and may be very simple to fix, but when it comes
to the product look and feel / User experience, it could cause a serious impact.
Example #2: There could be certain conditions under which a particular defect occurs
which may be an extremely rare or no possibility to hit in the customer environment. Even
though functionality-wise this may seem like a high priority defect to a tester, considering
its rarity of occurrence and high cost to fix this would be classified as a low priority
defect.
Hence in effect, the defect priority is generally set by the product manager in a defect
triage meeting, which is discussed in the next segment.

Defect Triage
A commonly heard and experienced situation in test teams is limited availability of
resources. Defect triage is a process which tries to do some re-balancing as a result of this
phenomenon. So when there are a large number of defect and limited Developers/testers to
fix/verify them, defect triage helps trying to get as many defects resolved as possible by
balancing these technical personnel based on defect parameters like priority and severity.

Typically, a defect triage session is attended by the Product Manager, a development lead, a
test lead and sometimes business analysts. In some cases, certain other members may also
be invited to give their opinions and perspectives regarding certain defects. These are
collectively called a triage team.
Defect Triage Process:

Most systems use priority as the main criteria to assess the defect, however a good triage
process considers the severity as well.
Lets take a closer look at the triage process with two examples that weve talked about in
the previous section. In both the examples above, it would actually be the first defect that
would be given a very high priority. Despite it being only a cosmetic defect, the impact of
not fixing would be huge.
The second one on the other hand is a surely functionality defect, however its occurrence is
in only certain conditions which is a seldom practiced customer scenario. Fixing it may need
more time and people, which could be better utilized for other defects. Hence it would deem
lower priority than that of the first and maybe deferral candidate to another release.
Thus the triage process involves triage team siting down together, reviewing all the defects
including rejected defects. They draw an initial assessment on the defects based on its
content, their respective priority and severity settings; with each person in the triage team
presenting their perspective on how to prioritize the defects. The product manager then sets
the priority based on all the inputs and assigns the defect to the correct release I.e. in the
current release or any future release. He also redirects the defect to the correct owner/team
for further action. Rejected defects also are put through a similar analysis. Based on the
reason for rejection, the futuristic action of whether it needs to be deferred or cancelled is
determined.

Suggestions to choose defect severity and priority

correctly
As weve already discussed, the severity parameter is assessed by the tester whereas the
priority parameter is mainly assessed by the Product Manager or basically the triage team.
Even while this is the case, the severity of a defect is definitely one of the governing and

influencing factors for the prioritizing the defect. Hence its important as a tester to select
the right severity to avoid confusion with development teams.
Below are certain guidelines that every tester must try to follow:

Firstly, understand the concepts of priority and severity well. Avoid confusing one

with the other and using them interchangeably. In line with this, follow the severity
guidelines published by your organization / team so that everyone is on the same
page.
Always choose the severity level based on the issue type as this will affect its priority.

Some examples are :

(I) For an issue which is critical, such as the entire system goes down and nothing
can be done this severity should be not be used to address program defects.
(ii) For an issue which is major, such as in cases where the function is not working as
expected this severity could be used to address new functions or improvement in
the current working.
Remember, that choosing the right severity level will in turn give the defect, its due
priority.
As a tester understand how a particular functionality, rather drilling down further

understand how a particular scenario or test case would affect the end user. This
involves a lot of collaboration and interaction with development team, Business
Analysts, architects, Test lead, Development lead. In your discussions you also need
to factor in how much time it would take to fix the defect based on its complexity
and time to verify this defect.
Finally, its always the product owner who possesses the veto power of the release
the defect should be fixed. However since the defect triage sessions contain varied
members to present their perspective on the defect on a case basis, at such a time if
the developers and testers are in sync, it surely helps in influencing the decision.

Conclusion
While opening defects its a testers responsibility to assign the right severity to the defects.
Incorrect severity and hence priority mapping can have very drastic implications on the
overall STLC process and the product as a whole. In several job interviews there are
several questions that are asked on priority and severity to ensure that as a tester you have
these concepts impeccably clear in your mind.

Naveen Lohchab, MSc (IT).

QA Manager RBR IM/IT