Defect Life Cycle in Software Testing - Software Testing Mentor

The development teams follow the Software Development Life Cycle processes while developing any software product. However, the development process is more challenging and always runs smoothly. Different types of defects or bugs arise during the development process when a product is being developed. So, these defects are identified and resolved throughout the development process to deliver a good quality software product. So, in this article, we will discuss these bugs in the software development process, how these are identified during software testing, and how these are resolved.

What is the Defect Life Cycle?

In the Software Development Process, the Defect Life Cycle is the life cycle of a defect or bug that covers a specific set of states in its entire life. The bug life cycle mainly refers to its whole state, starting from a new defect detected to the closing off of that defect by the tester. Alternatively, it is also called a Bug Life Cycle.

The journey of the Defect Cycle varies from organization to organization and from project to project because development procedures and platforms, as well as testing methods and tools, differ depending upon organizations and projects.
The number of states a defect goes through also varies depending on the tools used and processes followed during software testing.
The objective of the defect lifecycle is to efficiently coordinate and communicate the defect’s current status and thus help make the defect-fixing process efficient.

Defect Status

Defect status or Bug status is the current state from which the defect is currently going through. The number of states the defect goes through varies from project to project. The below diagram illustrates all the possible states of the defect:

1. New: When the tester identifies any new defect, it falls in the ‘New’ state. It is the first state of the Bug Life Cycle. The tester provides a proper Defect document to the Development team so that the development team can refer to the Defect Document and fix the bug accordingly.

2. Assigned: Defects that are in the status of ‘New’ will be approved, and that newly identified defect will be assigned to the development team to work on the defect and resolve it. When the defect is given to the developer team, the status of the bug changes to the ‘Assigned’ state.

3. Open: In this ‘Open’ state, the defect is being addressed by the developer team, and the developer team works on the defect to fix the bug. For some specific reason, if the developer team feels the defect is inappropriate, it is transferred to either the ‘Rejected’ or ‘Deferred’ state.

4. Fixed: After necessary code changes or fixing identified bugs, the developer team marks the state as ‘Fixed.’

5. Pending Request: When the defect is fixed, the developer team passes the new code to the testing team for retesting. The code/application is pending for retesting on the Tester side, so the status is assigned as ‘Pending Retest.’

6. Retest: At this stage, the tester starts retesting the defect to check whether the developer has fixed the defect, and the status is marked as ‘Retesting.’

7. Reopen: After ‘Retesting,’ if the tester team finds that the bug continues like previously, even after the developer team has fixed the bug, then the bug status is again changed to ‘Reopened.’ Once again, the bug goes to the ‘Open’ state and goes through the life cycle again. This means it goes for Re-fixing by the developer team.

8. Verified: The tester retests the bug after the developer team fixes it, and if the tester does not find any defect/bug, then the bug is fixed, and the status assigned is ‘Verified.’

9. Closed: It is the final state of the Defect Cycle; after fixing the defect by the developer team when testing, it is found that the bug has been resolved and does not persist, and then they mark the defect as a ‘Closed’ state.

Few More States that also come under this Defect Life Cycle:

1. Rejected: If the developer team rejects a defect if they feel it is not considered genuine, they mark it as ‘Rejected.’ The cause of rejection may be any of these three, i.e., Duplicate Defect, NOT a Defect, Non-Reproducible.

2. Deferred: All defects have a terrible impact on developed software, and they also have a level based on their impact on software. If the developer team feels that the identified defect is not a prime priority and can be fixed in further updates or releases, then the developer team can mark the status as ‘Deferred.’ This means from the current defect life cycle, it will be terminated.

3. Duplicate: Sometimes the defect may be repeated twice, or the defect is the same as any other defect, then it is marked as a ‘Duplicate’ state, and then the defect is ‘Rejected.’

4. Not a Defect: If the defect has no impact or effect on other software functions, it is marked as ‘NOT A DEFECT’ state and ‘Rejected.’

5. Non-Reproducible: If the defect is not reproduced due to platform mismatch, data mismatch, build mismatch, or any other reason, then the developer marks the defect as in a ‘Non-Reproducible’ state.

6. Can’t be Fixed: If the developer team fails to fix the defect due to Technology support, the Cost of fixing a bug is more, lack of required skill, or due to any other reasons, then the developer team marks the defect as in ‘Can’t be fixed’ state.

7. Need more information: This state is close to the ‘Non-reproducible’ state. But it is different from that. When the developer team fails to reproduce the defect due to insufficient steps/documents provided by the tester, the Defect Document needs to be clarified to produce the defect. The developer team can change the status to “Need more information’. The developer team fixes the bug when the Tester team provides a good defect document.