Defect Management Process

Defect Management is a systematic process to identify and fix bugs. A defect management cycle
contains the following stages:

1) Discovery of Defect
2) Defect Categorization
3) Fixing of Defect by developers
4) Verification by Testers
5) Defect Closure
6) Defect Reports at the end of Sprint

1. Discovery of Defect

A Defect (bug, problem, issue) in Software Testing is a variation or deviation of the software
application from end user’s requirements or original business requirements. A software defect is
an error in coding which causes incorrect or unexpected results from a software program which
does not meet actual requirements.
 In the discovery phase, ideally QA team should be able to identify all possible defects, at
least blockers & high priority ones. This means that we should always focus on finding defects
before merging the actual changes from our testing branch into develop (master) branch code.

2. Defect Categorization

Defect categorization help the software developers to prioritize their tasks. That means that
this kind of priority helps the developers in fixing those defects first that are highly crucial.

Blocker The defects need to be fixed immediately because it

may cause grate damage to the product

High The defect impact the product's main features

Medium The defects causes minima deviation from product

requirements

Low The defect has very minor affect on the product

requirements

All defects identified (low/medium/high priorities or blockers) are usually reported in

separate defect JIRA tickets. There will still be some cases when we will gather similar issues
that have low/medium priorities into one single ticket but blockers & high priority ones should
be always raised as separate tickets.

On our project reporting of bugs is done through JIRA Bug tickets. Each Bug ticket that is
raised should contain the minimum details required, which are:

 Title – Every bug or defect has it’s unique identification number

 Defect Description – This includes the abstract of the issue.
 Product Version – This includes the product version of the application in which the
defect is found.
 Detail Steps – This includes the detailed steps of the issue with the screenshots
attached so that developers can recreate it.
 Date Raised – This includes the Date when the bug is reported
 Reported By – This includes the details of the tester who reported the bug like Name
and ID
 Status – This field includes the Status of the defect like New, Assigned, Open, Retest,
Verification, Closed, Failed, Deferred, etc.
 3. Defect Resolution

Defect Resolution in software testing is a step by step process of fixing the defects. Defect
resolution process starts with assigning defects to developers, then developers schedule the
defect to be fixed as per priority, then defects are fixed.

4. Verification

After the development team fixed and reported the defect, the testing team verifies that the
defects are actually resolved.

5. Closure

Once a defect has been resolved and verified, the defect is changed status as closed. If not,
you have send a notice to the development to check the defect again.

Defect Life Cycle

A Defect life cycle, also known as a Bug life cycle, is a cycle of a defect from which it goes
through covering the different states in its entire life. This starts as soon as any new defect is
found by a tester and comes to an end when a tester closes that defect assuring that it won’t get
reproduced again.

Defect Workflow on Sky City project

 Defect States

#1) New: This is the first state of a defect in the Defect Life Cycle. When any new defect is
found, it falls in a ‘New’ state, and validations and testing are performed on this defect in the
later stages of the Defect Life Cycle.

#2) Assigned: In this stage, a newly created defect is assigned to the development team for
working on the defect. This is assigned by the project lead or the manager of the testing team to a
developer.

#3) Open: Here, the developer starts the process of analyzing the defect and works on fixing
it, if required. If the developer feels that the defect is not appropriate then it may get transferred
to any of the below four states namely Duplicate, Deferred, Rejected, or Not a Bug-based upon
the specific reason.

I will discuss these four states in a while.

#4) Fixed: When the developer finishes the task of fixing a defect by making the required
changes then he can mark the status of the defect as ‘Fixed’.

#5) Pending Retest: After fixing the defect, the developer assigns the defect to the tester for
retesting the defect at their end, and till the tester works on retesting the defect, the state of the
defect remains in ‘Pending Retest’.

#6) Retest: At this point, the tester starts the task of working on the retesting of the defect to
verify if the defect is fixed accurately by the developer as per the requirements or not.

#7) Reopen: If any issue persists in the defect then it will be assigned to the developer again
for testing and the status of the defect gets changed to ‘Reopen’.

#8) Verified: If the tester does not find any issue in the defect after being assigned to the
developer for retesting and he feels that if the defect has been fixed accurately then the status of
the defect gets assigned to ‘Verified’.

#9) Closed: When the defect does not exist any longer then the tester changes the status of
the defect to ‘Closed’.

Few More:

Rejected: If the defect is not considered as a genuine defect by the developer then it is
marked as ‘Rejected’ by the developer.
Duplicate: If the developer finds the defect as same as any other defect or if the concept of
the defect matches any other defect then the status of the defect is changed to ‘Duplicate’ by the
developer.
 Deferred: If the developer feels that the defect is not of very important priority and it can get
fixed in the next releases or so in such a case, he can change the status of the defect as
‘Deferred’.
Not a Bug: If the defect does not have an impact on the functionality of the application then
the status of the defect gets changed to ‘Not a Bug’.
 6. Defect Reporting

Defect Reporting in software testing is a process in which test managers prepare and send the
defect report to the management team for feedback on defect management process and defects’
status. Then the management team checks the defect report and sends feedback or provides
further support if needed. Defect reporting helps to better communicate, track and explain
defects in detail.

Defect Metrics

How to measure and evaluate the quality of the test execution?

In the above scenario, you can calculate the defection rejection ratio (DRR) is 20/84 = 0.238
(23.8 %).

Another example, supposed the Guru99 Bank website has total 64 defects, but your testing team
only detect 44 defects i.e. they missed 20 defects. Therefore, you can calculate the defect leakage
ratio (DLR) is 20/64 = 0.312 (31.2 %).

Conclusion, the quality of test execution is evaluated via following two parameters

The smaller value of DRR and DLR is, the better quality of test execution is. What is the ratio
range which is acceptable? This range could be defined and accepted base in the project target or
you may refer the metrics of similar projects.

In this project, the recommended value of acceptable ratio is 5 ~ 10%. It means the quality of test
execution is low. You should find countermeasure to reduce these ratios such as

Improve the testing skills of member.

Spend more time for testing execution, especially for reviewing the test execution results.