| DEFECT LIFE CYCLE | | | | is working on a bug to find solution |
| Defect Tracking: Once any defect has been | | | | - As Designed: This is an intended functionality as per |
| detected, at once that defect must be reported to | | | | the system requirement. |
| the development team so that it must be | | | | If the development team at once started working |
| ‘FIXED’. | | | | on a defect they set the status of a defect as |
| The initial stage of the defect is ‘NEW’, | | | | ‘WIP’ (work in progress) and if they are |
| and once the tester examines that defect he/she | | | | waiting for some technical feedback to start their |
| set that defect to one of the following status | | | | work they set the status of the defect as |
| - Duplicate: By duplicate we mean the existing bug is | | | | ‘DEVWAITING’. Once the defect is fixed by |
| already having a duplicate bug. | | | | a development team they set the status of defect |
| - Invalid Bug: When the bug in some way is not valid | | | | as ‘Fixed’ and it means the defects is ready |
| as per the design of the system. | | | | to Retest. After retesting, if the developer still feels |
| - Deferred: Some time the bug is expected to be | | | | that the defect exists then the ‘REOPENED’ |
| fixed in future releases due to some reason such as | | | | status is assigned to that defect and same cycle |
| low priority of bug, lack of time etc. | | | | repeats again but if the developer feels that the |
| - Document: A part from the open status if any | | | | defect which is fixed satisfied the requirement then |
| other status has been set to the bug to which | | | | they assigned ‘CLOSE’ status to that |
| development team does not agree then they set the | | | | defect. |
| status of a bug as Document. | | | | References: |
| - Open: The open status indicates that the developer | | | | 1. |