Software testing is entirely about finding defects in applications, right? Apparently, this can be considered as the principal goal of all the QA practices. However, all the defects diverge from each other. It cannot be stated if some are more important than others, yet it’s possible to locate and fix them all.

1. How Severe
Is Your Bug?

2. Software testing is entirely about finding defects in applications, right?
Apparently, this can be considered as the principal goal of all the QA
practices.
However, all the defects diverge from each other. It cannot be stated if
some are more important than others, yet it’s possible to locate and fix
them all.
Rendering to Murphy’s Law, a line of code will include a defect it can,
hence even the apps that comprise one line of code will include at least
one issue.
And considering the fact that a tester usually tests large and intricate
solutions, there will be oodles of defects.
However there still stand limitations for budget and deadlines that force
testers to categorize and prioritize the traced bugs so that the most urgent
ones are dealt first while the minor issues can be doled out later.

3. How to Define Severity?

4. How to Define Severity?
Severity is basically a parameter to denote the impact of defect on the
application/ system, to determine how critical the defect is and what is its
impact on the whole system’s functionality.
The severity of a defect is related to technical aspect of the product and
decides on how bad the bug is for the system. It can be defined by the
tester based on the written test cases and functionality.
Each technique of classification necessitates categories. Stages of defect
priority are almost same and used all through the industry, though they
might differ marginally from a company to another.
We, at BugRaptors, use the following classification.
Feature: A feature defect is when a feature is missing from the application.
Block: This defect may block functionality and hence disturb the testing
process.

5. How to Define Severity?
Crash: A crash defect may cause the application close abruptly or crash
and may also affect other aspects of the application.
Major: A major severity defect causes a noticeable failure or departure
from requirements.
Medium: A medium severity defect affects unimportant functionality or
non-critical data. It has an easy workaround.
Minor: A minor severity defect does not cause a failure in execution of
the product but is required to be mended.
Text: The text defect neither affects the functionality or data, nor the
efficiency or the productivity of the application but is merely an
inconvenience and needs to be mended before the release.
Tweak: Tweak defect means the minutest issue that needs to be
resolved.

6. How to Define Priority?
Defect Priority states the order in which a defect should be fixed. Higher
the priority the faster the defect should be resolved.
Defects and bugs are prioritized on the basis of the following:
 Immediate
 Urgent
 High
 Normal
 Low
Immediate And Urgent Priority Defects: These are the defects that disrupt
the functionality of an application/ software critically and are to be treated
instantly.
For example: Complete failure of a feature, unsuccessful installation

7. How to Define Priority?
High Priority Defects: These are the defects that must be resolved as
soon as possible as they can affect the system severely and might not
allow its use until it is fixed.
Normal Priority Defects: These are the defects that should be resolved
in the normal course of the development activities. These can also be
altered after a new version is created as they do not stagnate the
working of the application.
Low Priority Defects: A low priority defect can be an irritant but can be
mended once the more serious defects have been fixed.

8. How Can Defects Be
Classified?
To begin with, a tester needs to measure the impact.
Remember, even the slightest cosmetic defects can be repeated all
over the product and will be a major concern to the end users.
This way even the tiniest typo can no longer be reflected as a low-
priority issue and will be classified elsewhere due to the impact it will be
causing.
Also, we follow a tiny checklist to make things little relaxed. The testers
answer these listed questions and are able to determine the severity of
the actual defect easily.
Does the defect you have come across cause the application test to
crash?
Can the system in the test recover from the crash?
Can the system recover by itself, without obligatory external efforts or
third-party interactions?

9. Define if the defect is present or reflects in other sections of the system?
If yes: are those sections linked to any other sections?
Will the same arrangements authorize you, as a tester to repeat the
defect easily, but in a different system?
Is the defect replicable despite of the changes in the configurations?
How many users are affected? All the users or just the categories that
fall under this risk?
Is the defect recurring?
How often does it re-occur?
What caused it? Which inputs can lead to the defect taking place?
The depth of the impact can be deliberated through the isolation of the
defect. This is how you will be able to determine and highlight both the
occurrence and the sequence of the events that lead to the defect taking
place.