Identifying a defect plays a major role in software development. This follows a cycle of process called Defect life cycle. The process starts when a bug or defect is found and stops when the defect is closed or rectified. The bug has different states in the Life Cycle. The Life cycle of the bug is shown diagrammatically.
Identifying a defect plays a major role in software development. This follows a cycle of the processes and is called Defect life cycle. The process starts when a bug or defect is found and stops when the defect is closed or rectified. The bug follows different stages in its Life Cycle. The Lifecycle of the bug can be explained as follows:
Bug or defect life cycle crawls through the following stages or status:
- New: When a defect is logged and posted for the first time. It is mentioned as new.
- Assigned: Once the tester has posted the bug, the lead of the tester approves that the bug is genuine. He then assigns the bug to the corresponding developer and the developer team. It’s state given as assigned.
- Open: This is the state at which the developer starts analyzing and fixing the bug.
- Fixed: At this stage, the developer makes the necessary changes in the program and verifies it so that it performs the task.
- Retest: Here the tester once again performs the testing of the changed code which developer has given. It is to ensure whether the bug is fixed or not.
- Verified: After the retest process, if the tester found no bug then, he changes the status to be verified.
- Reopen: The status will be set as reopened if the bug continues to exist even after the bug is fixed by the developer, the bug goes through the life cycle once again.
- Closed: Once the bug is fixed, it is then again tested by the tester. If the tester feels that the bug no longer there in the software, then he changes the status of the bug to be “closed”. This state means that the bug is fixed, tested and approved.
- Duplicate: Duplicate status is given to a bug if it behaves exactly as another bug which we already know.
- Rejected: The status of the bug is changed to rejected if the developer feels that the bug is genuine in his/her context.
- Deferred: The bug is changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this stage might be of many factors such as the priority of the bug may be low, lack of time for the release or the bug may not have a major effect on the software.
- Not a bug: If there is no change in the functionality of the application then not a bug status will be given. For an example: If a customer asks for some change in the UI of the application like the change of colour of some text then it is not a bug but just some change in the looks of the application.
Reference: istqbexamcertification.com/what-is-a-defect-life-cycle/