Defect management

Software testing lays down the mechanism for finding defects in an application, product or
system. A Defect is a deviation between the actual and expected outcomes. A mistake in the
source code indicates Error. The error uncovered by a tester becomes a Defect. The defect
recognized by the dev team turns into a Bug. If a product build doesn’t pass the acceptance
criteria, then it proves to be a Failure.

Hence, all these testing terms revolve around the defect. Let’s understand it in more details.

Defect In Manual Testing

A defect is an anomaly which causes a deviation between the expected and actual results. It
could be an error discovered once the application got deployed into production. Some software
could show potential issues with both the internal and external features. Hence, any variance in
the behavior of the functionalities of a product or software got to be a defect in manual testing.

Defect Vs. Wrong, Miss, Error, Bug, Failure, And Fault

In Software Testing, Defect has many names such as Wrong, Miss, Error, Bug, Failure, and
Fault. Let’s find out what all of these are:

1. Wrong-

Wrong indicates the incorrect implementation of the customer requirements. A manual tester will
record it as a defect because of the deviation from the given specification.

2. Miss-

Miss shows that one or more customer requirements got missed in the implementation. It is also
a deviation from the original specifications. The tester would also log it as a defect to

3. Error (mistake) -

An error could arise because of a coding mistake by the developer, he misunderstood, or the
requirement was not clear enough. For example, a developer may misinterpret a design flow, or
he might use an incompatible data type which results in an Error. Some actions like insufficient
array limit, loop getting into the infinite loop or invalid syntax cause to errors. If a tester catches
any of these, then he or she will log a defect for the same.

4. Bug (Fault, Problem) -

A bug occurs because of some coding error and leads a program to malfunction. It may also lead
to a functional issue in the product. These are fatal errors that could block a functionality, results
in a crash, or cause performance bottlenecks. Such errors got treated as Bugs in manual testing.

5. Failure-

A failure indicates a fatal issue in software or in its module which is making the system
inoperative or unresponsive. Such an error in the software which the end customer reports are a
Failure. The manual testers also discover many failures during the development cycle.

https://youtu.be/yAtIBswQ-P8

Severity & Priority in Testing: Differences & Example

What is Severity?

Severity is defined as the degree of impact a Defect has on the development or operation of a
component application being tested.

Higher effect on the system functionality will lead to the assignment of higher severity to the
bug. Quality Assurance engineer usually determines the severity level of defect

What is Priority?

Priority is defined as the order in which a defect should be fixed. Higher the priority the sooner
the defect should be resolved.

Defects that leave the software system unusable are given higher priority over defects that cause
a small functionality of the software to fail.
Defect Severity and Priority Types

In Software Testing, Defect severity can be categorized into four classes:

●​ Critical: This defect indicates complete shut-down of the process, nothing can proceed
further.

For example: In the email service provider like Gmail, after typing the correct Username and
the password, instead of logging in, the system crashes or throws the error message, this defect is
classified as critical as this defect makes the whole application unusable.

●​ Major: Any Major feature implemented that is not meeting its requirements/use case(s)
and behaves differently than expected, it can be classified under Major Severity.
However, certain parts of the system remain functional

For example: In the email service provider like Gmail, when you are not allowed to add more
than one recipient in the CC section, this defect is classified as the Major defect as the major
functionality of the application is not working properly. What is expected the behavior of the CC
section in the mail, it should allow the User to add multiple Users. So when the major
functionality of the application is not working properly or when it behaves differently than
expected, it is a major defect.

●​ Minor: It causes some undesirable behavior, but the system is still functional

For example: In the email service provider like Gmail, there is option called “Terms and
Conditions” and in that option there will be multiple links regarding the terms and condition of
the website, When one among the multiple links, is not working fine, it is called as Minor
severity as it only affects minor functionality of the application and it doesn’t have big impact on
the Usability of the application.

●​ Low: It won't cause any major break-down of the system

For example: In the email service provider like Gmail, You would have noticed the “License
page”, if there is any spelling mistakes or misalignment in the page, this defect is classified as
Low.
Defect priority can be categorized into three classes:

●​ Low: The Defect is an irritant but repair can be done once the more serious Defect has
been fixed
●​ Medium: During the normal course of the development activities defect should be
resolved. It can wait until a new version is created
●​ High: The defect must be resolved as soon as possible as it affects the system severely
and cannot be used until it is fixed

Tips for determining the Severity of a Defect

●​ Decide the frequency of occurrence: In some cases, if the occurrence of a minor-defect

is frequent in the code, it can be more severe. So from a user's perspective, it is more
serious even though it is a minor defect.
●​ Isolate the defect: Isolating the defect can help to find out its severity of the impact.
 Priority vs Severity: Key Difference

Priority Severity

●​ Defect Priority has defined the order ●​ Defect Severity is defined as the
in which the developer should resolve degree of impact that a defect has on
a defect the operation of the product

●​ Priority is categorized into three types ●​ Severity is categorized into five types
○​ Low ○​ Critical
○​ Medium ○​ Major
○​ High ○​ Minor
○​ Urgent(optional) it depends on ○​ Low​
the project flow it depends on the project flow

●​ Priority is associated with scheduling ●​ Severity is associated with

functionality or standards

●​ Priority indicates how soon the bug ●​ Severity indicates the seriousness of
should be fixed the defect on the product functionality

●​ Priority of defects is decided in ●​ QA engineer determines the severity

consultation with the manager/client level of the defect

●​ Priority is driven by business value ●​ Severity is driven by functionality

 ●​ Its value is subjective and can change ●​ Its value is objective and less likely to
over a period of time depending on change
the change in the project situation

●​ High priority and low severity status ●​ High severity and low priority status
indicates, defect have to be fixed on indicates defect have to be fixed but
immediate bases but does not affect not on immediate bases
the application

●​ Priority status is based on customer ●​ Severity status is based on the

requirements technical aspect of the product

●​ During UAT the development team fix ●​ During SIT the development team will
defects based on priority fix defects based on the severity and
then priority

UAT: User Acceptance Testing​

SIT: System Integration Testing
 Example of Defect Severity and Priority

Let see an example of low severity and high priority and vice versa

●​ A very low severity with a high priority: A logo error for any shipment website, can be
of low severity as it not going to affect the functionality of the website but can be of high
priority as you don't want any further shipment to proceed with the wrong logo.
●​ A very high severity with a low priority: Likewise, for flight operating website, a
defect in reservation functionality may be of high severity but can be a low priority as it
can be scheduled to release in a next cycle.

Guidelines that every tester should consider before selecting a severity

Severity parameter is assessed by the tester whereas the priority parameter is assessed by the
product manager. For prioritizing the defect, it is imperative for a tester to choose the right
severity to avoid confusion with the development team.

●​ Understand the concept of priority and severity well

●​ Always assign the severity level based on the issue type as this will affect its priority
●​ Understand how a particular scenario or Test Case would affect the end-user
●​ Need to consider how much time it would take to fix the defect based on its complexity
and time to verify the defect
 Why good Bug Report?

If your Bug report is effective, then its chances to get fixed are higher. So fixing a bug depends
upon how effectively you report it. Reporting a bug is nothing but skill and I will explain how to
achieve this skill.

“The point of writing problem report(bug report) is to get bugs fixed” – By Cem Kaner. If a
tester is not reporting a bug correctly, the programmer will most likely reject this bug stating it as
irreproducible.

This can hurt testers moral and sometimes the ego too. (I suggest not to keep any type of ego.
The ego's like “I have reported the bug correctly”, “I can reproduce it”, “Why he/she has rejected
the bug?”, “It's not my fault” etc.,).

What Are The Qualities Of A Good Software Bug Report?

Anyone can write a Bug report. But not everyone can write an effective Bug report.

Characteristics and Techniques include

#1) Having a clearly specified Bug Number: Always assign a unique number to each bug
report. This, in turn, will help you to identify the bug record. If you are using any automated
bug-reporting tool then this unique number will be generated automatically each time while you
report the bug.

#2) Reproducible: If your bug is not reproducible, then it will never get fixed.

You should clearly mention the steps to reproduce the bug. Do not assume or skip any
reproducing step. A bug which is described Step by step is easy to reproduce and fix.

#3) Be Specific: Do not write an essay about the problem.

Be Specific and to the point. Try to summarize the problem in minimum words yet in an
effective way. Do not combine multiple problems even if they seem to be similar. Write different
reports for each problem.
 How To Report A Bug?

This is a simple Bug report format. It may vary depending upon the Bug report tool that
you are using. If you are writing a bug report manually then some fields need to be mentioned
specifically like the Bug number, which should be assigned manually.

Bug Title: A Bug title is read more often than any other part of the bug report. It should say all
about what comes in the bug.

The Bug title should be suggestive enough that the reader can understand it. A clear bug title
makes it easy to understand and the reader can know if the bug has been reported earlier or has
been fixed.

Description: A detailed description of the bug. Bug description helps the developer to
understand the bug. It describes the problem encountered. The poor description will create
confusion and waste the time of the developers and testers as well.

●​ The page URL on which the bug occurred.

●​ Steps to reproduce - clearly, mention the steps to reproduce the bug
●​ Actual result - what is the actual result of running the above steps i.e. the bug
behavior.
●​ Expected result - how the application should behave on the above-mentioned
steps.
●​ Attached image/video - a picture is worth a thousand words. Take a Screenshot
of the instance of failure with proper captioning to highlight the defect. Highlight
unexpected error messages with light red color. This draws attention to the
required area.
●​ Notes(optional)

Reporter: Your name and email address.

Product: In which product you found this bug.

Version: The product version if any.

Component: These are the major sub-modules of the product.

Platform: Mention the hardware platform where you found this bug. The various platforms like
‘PC', ‘MAC', ‘HP', ‘Sun' etc.
Operating system: Mention all the operating systems where you found the bug. Operating
systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also
like Windows NT, Windows 2000, Windows XP etc, if applicable.

Priority: When should a bug be fixed?

Severity: This describes the impact of the bug.

Status: When you are logging the bug into any bug tracking system then by default the bug
status will be ‘New'.

Assign To: If you know which developer is responsible for that particular module in which the
bug occurred, then you can specify the email address of that developer. Else keep it blank as this
will assign the bug to the module owner if not the Manager will assign the bug to the developer.
Possibly add the manager's email address in the CC list.

Defect/Bug Life Cycle in Software Testing

What is Defect Life Cycle?

Defect Life Cycle or Bug Life Cycle is the specific set of states that a Bug goes through from
discovery to defect fixation.

Bug Life Cycle Status

The number of states that a defect goes through varies from project to project. Below lifecycle
diagram, covers all possible states

●​ New: When a new defect is logged and posted for the first time. It is assigned a status as
NEW.
●​ Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug
and assigns the bug to the developer team
●​ Open: The developer starts analyzing and works on the defect fix
●​ Fixed: When a developer makes a necessary code change and verifies the change, he or
she can make bug status as "Fixed."
●​ Pending retest: Once the defect is fixed the developer gives a particular code for
retesting the code to the tester. Since the software testing remains pending from the
testers end, the status assigned is "pending retest."
●​ Retest: Tester does the retesting of the code at this stage to check whether the defect is
fixed by the developer or not and changes the status to "Re-test."
●​ Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug
detected in the software, then the bug is fixed and the status assigned is "verified."
●​ Reopen: If the bug persists even after the developer has fixed the bug, the tester changes
the status to "reopened". Once again the bug goes through the life cycle.
●​ Closed: If the bug is no longer exists then tester assigns the status "Closed."
●​ Duplicate: If the defect is repeated twice or the defect corresponds to the same concept
of the bug, the status is changed to "duplicate."
●​ Rejected: If the developer feels the defect is not a genuine defect then it changes the
defect to "rejected."
●​ Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in
the next release, then status "Deferred" is assigned to such bugs
●​ Not a bug:If it does not affect the functionality of the application then the status assigned
to a bug is "Not a bug".

1.​ Tester finds the defect

2.​ Status assigned to defect- New
3.​ A defect is forwarded to Project Manager for analyze
4.​ Project Manager decides whether a defect is valid
5.​ Here the defect is not valid- a status is given "Rejected."
 6.​ If the defect is not rejected then the next step is to check whether it is in scope.
Suppose we have another function- email functionality for the same application,
and you find a problem with that. But it is not a part of the current release when
such defects are assigned as a postponed or deferred status.
7.​ Next, the manager verifies whether a similar defect was raised earlier. If yes
defect is assigned a status duplicate.
8.​ If no the defect is assigned to the developer who starts fixing the code. During this
stage, the defect is assigned a status in- progress.
9.​ Once the code is fixed. A defect is assigned a status fixed
10.​Next, the tester will re-test the code. In case, the Test Case passes the defect is
closed. If the test cases fail again, the defect is re-opened and assigned to the
developer.
11.​Consider a situation where during the 1st release of Flight Reservation a defect
was found in Fax order that was fixed and assigned a status closed. During the
second upgrade release the same defect again re-surfaced. In such cases, a closed
defect will be re-opened.

Lets Practice

1.​ https://www.phptravels.net/admin

Email: [email protected]​
Password: demoadmin

2.​ http://newtours.demoaut.com/
3.​ http://automationpractice.com/index.php
4.​ https://www.phptravels.net/index.php

Email: [email protected]​
Password: demouser

To Look: https://alphagov.github.io/accessibility-tool-audit/test-cases.html#content