Defect Life Cycle in Software Testing


Defect Life Cycle

From creation to closure, a defect goes through different phases. All together these are called defect life cycle.

When a tester creates a defect its status is new. Generally tester assigns this defect to no one. On next defect triage meeting project team decides the responsible developer and assign the defect to that developer. Then the defect status changes to assign.

After getting the defect developer analyses it and if he found the defect is duplicate (already raised before) or the defect is not valid, then he/she can reject the defect. Developer should provide valid comments in the defect to justify why he/she is rejecting it. After rejection tester should understand and agree why the defect is rejected. If tester is not agree with the developer then tester can reopen the defect again. Now at this point of time generally project management schedule a meeting with both testing team, development team and business analyst to conclude the situation.

If the defect is on such functionality which is not implemented yet then developer can defer the defect for next release. But for this he/she must need approval from project management.

If the defect is a valid defect developer changes the status to ‘open’ and starts working it.

Developer should always fixes the code in development environment. After fixing the code in development environment, developer changes the defect status as ‘Fixed

After getting confirmation from Testing team and project management, developer migrates the new code in QA environment. After code migration developer changes the defect status as ready for retest.

So now QA/testing team can start retesting the defect.

After retesting if the functionality is working as expected, tester can close the defect with valid retesting log as attachment. If the functionality is still not working tester can reopen the defect again.


  • A rejected defect cannot be closed.
  • A closed defect cannot be reopened again (unless approved by management)

Process of raising a defect:

While raising a defect a tester should provide the below details:

  1. Defect summary
  2. Defect description
  3. Test Data
  4. Steps to reproduce
  5. Attachment (screen shots)

Defect severity:

Urgent: Testing is blocked due to the defect. Need to be fixed by less than a day.

High: Testing of some functionality is blocked and also defect impact is more on the system. Need to be fixed by one or two days.

Medium: Testing is not blocked but functionality impact is medium. Need to be fixed by two to three days.

Low: Less impact on system. Need to be fixed by four to five days.

Arijit Naskar

Arijit Naskar is a Software Developer and QA, also founder of a popular tech tutorial & how-to website since 2014. He loves to explore new technologies and writing blogs.

You may also like...