Home » Software Testing » Defect Life Cycle in Software Testing

Defect Life Cycle in Software Testing

Many of the testers are often confused and have questions with the various stages of the defect and their importance in the defect life cycle. As we know, there is always a strong affinity between a tester and a defect so as defect life cycle.

Hence, to address these questions, here in this post , we would be discussing regarding what is a defect, different stages of the defect ,their sequence and their importance.

Before we would be going deeper into the life cycle of the defect, we need to understand the actual meaning of the defect.

Basically, Software Defect or a Bug is a condition which does not meet a software requirement. A software requirement could be specified in the requirement specification or an end-user expectation. Defect is an error or a flaw which produces unexpected or incorrect behaviors in the system. Generally, Defects can be generated during requirement analysis, design, implementation or testing phase.

After a defect has been found out, it goes with various stages during its lifetime which is commonly known as Defect Life Cycle .It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced again.

Here in this picture we can easily understand the end to end workflow of the defect stages:-

   captue1

Now, Lets walk through the different stages of the defect life cycle one by one:-

  1. New :-  When a defect has been found out and tester has logged the defect in the defect management tool for the first time, then the state of the defect would be “New”.It is set by testing team.
  2. Open :- When a new logged defect has been reviewed by QA lead and if the defect is valid, the state of the bug would be “Open” and it is ready to be assigned to development team and if the bug is invalid QA lead would mark it as “Closed”.
  3. Assigned:- When QA lead assigns the defect to the corresponding developer, the state of the defect would be marked as “Assigned”. Developer should start analyzing and fixing the bug at this state.
  4. Rejected / Invalid :– When the developer feels that the bug is not genuine/valid, he rejects the bug. Then the state of the bug is marked as “rejected”.Also, in some defect management tools ,it is stated as “Not a Bug”.
  5. Could not reproduce:- When developer is not able to reproduce the bug by the steps mentioned in Steps to Reproduce by QA then developer can mark the bug as ‘CNR’ (Could Not Reproduced”). In this stage QA should provide detailed reproducing steps to developer.
  6. Need More information:- If developer is not clear about the steps to reproduce provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps.
  7. Ready to test / Fixed:- When developer makes the necessary code changes , the defect has marked as “Fixed”. The developer now passes the defect to the testing team to verify so he changes the state as “Ready to Test”.
  8. Verified:- When tester retest the bug and found it fixed/non-reproducible, he/she marks it as “Verified”.
  9. Reopened:- If the tester while verifying the defect found that, the defect is still reproducible or partially fixed then the defect would be marked as “Reopened”.Now the developer has to look again into this defect.
  10. Duplicates:- If the defect logged is repeated twice or the two defects reported has alike results and steps to reproduce, then one defect status is changed to “DUPLICATE” and it should be linked to the another similar defect.
  11. Deferred:- If there are some issues or hurdles in the current sprint, then the defect would be taken in upcoming releases instead of the current release then it is marked as “DEFERRED”.
  12. Closed:-  If the defect has no issues further and it is properly verified, then the tester or test lead would mark the defect as “Closed”.

Some Important Points to Ponder regarding Defect Life Cycle Implementation:-

  • We must make sure that the entire team understands what each defect status exactly means. Also,the defect life cycle should be properly documented.
  • We must ensure that each individual in the team clearly understands his/her responsibility in regarding of each defect.
  • We must ensure that enough detail should be entered in each status change.

4 thoughts on “Defect Life Cycle in Software Testing”

  1. as i am new in testing and wanted to learn manual as well as automation currently joined as a qa so can u please suggest me the most used automation tool (open source)..?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: