Defect Management : Defect Life Cycle

Humans are imperfect hence the codes they write are also imperfect. Humans are smart too, they find new ways to work on the software to make it work as intended or they hire people like me to help them. So it’s all good :)

Let us first understand the meaning of a bug or a defect. Defect is any flaw in the software system that gives us an incorrect result or we can say that when there is a difference between the expected result and the actual result, there is a defect. Defect is anything about the product that threatens it’s value.

The most common reasons to have bugs in a software are:

1. Ambiguous or unclear requirements
2. Programming errors
3. Communication gap
4. Poor documentation
5. Increased complexity of the software

6. Inability to manage change in the software

Defect Life Cycle

Defect Life Cycle

Defect Life Cycle” can be described as the stages that the bug travels through within the system from it’s detection to elimination. Testers follow some guidelines for a systematic approach towards bug elimination. These guidelines are set by the software testing process or the defect tracking tool used by the organization, hence the defect life cycle may vary from organization to organization.

Different stages in a “Defect Life Cycle” can be generalized as follows:

1. New – Every reported defect has an initial status as ‘New’.

2. Opened – The status of a defect is changed to ‘Opened’ when it is opened by a Test Manager. After opening, the defect is reviewed and if it is not a defect it can be closed directly.

3. Duplicate – If the same defect is already reported by any other tester then it can be closed by changing its status to ‘Duplicate’.

4. Deferred – In some cases the defect is valid but it will not cause any major change in the software. Hence this bug can be fixed in the next version and the status for this defect is changed to ‘Deferred’.

5. Assigned – If after review a particular defect is found valid, it is assigned to the development team to fix it and the status is changed to ‘assigned’.

6. Fixed – Depending on the priority, after the developer makes the required changes to remove the defect from the application, the status of the defect can be changed to ‘Fixed’.

7. Retested – After fixing the defect, the application needs to be retested to confirm the removal of the defect.

8. Reopened / Closed – After retesting, if the bug is still not removed from the system, then it’s status is changed to Reopened but if the bug is fixed and is no more of any concern then it is ‘Closed’.

This entry was posted in Quality Assurance & Testing and tagged , , , . Bookmark the permalink.

Leave a Reply