All human beings are bound to make mistakes in their real lives. In the world of software, these mistakes are called as bugs or defects. Most of the times, people working on a software project such as business analyst, tester, programmer, technical writer and many other people involved in a project can add to many defects in a test case, code, user guide, requirement specifications and so forth. Due to the shortcomings of all such people, a project often encounters bugs too often.
Defect life cycle is a cycle which a defect goes through during its lifetime. It is related to the bugs found during testing.
We all know that bugs are an indispensable part of a project and they can occur at any phase. The errors are limited to testing phase or execution phase only. Often it is seen that bugs grow with age; one small error can lead to a whole network of errors crawling in a project which certainly is not considered as good way to handle projects. As a responsible project handler, you must know that in order to remove defects from the roots; we should make sure that the projects are checked throughout during the life cycle. Ultimately, on ignoring the small defects, it might complicate the project and increase the time taken to rectify the errors.
The Defect Life Cycle is used to represent a journey of the defect cycle, displaying the beginning and end of the defect developing in a project. The cycle may vary from one project to another depending on the organization and the tools used while creating a project.
Governed by the software testing processes, the defect life cycle is used to seek a bug during the testing process.
The defect cycle provides a diagrammatic representation of a journey of a bug in stages. It is elaborated below:
A bug is titled as new when it is acknowledged for the first time. As, its state is unknown it is called as new. In this stage, the prospective of the bug is unknown and is yet to be validated.
On posting a bug by a tester, the lead member of team takes responsibility of approving the bug in this stage. Post the approval, the bug is assigned to the developer team. In this stage, the bug is not yet resolved it is just been assigned to a concerned team.
In this stage, the team starts working on the fixation of bug related issues. While addressing the bug, the developed investigates thoroughly in order to determine the causes of the bug. At this stage, the developer has all the rights to reject or defer it.
At this stage, the concerning defects undergoes a process of testing as it is found to be fixed. The process of analyzing begins in this stage.
This stage implies that the bug is repeatedly tested by the intelligent team of QA. In this stage, the troubling bug undergoes a scrutiny check.
At this stage, the bug is resolved completely after being verified by the QA team. Post this stage, the bug is closed if the defect is no more to be a defect.
Sometimes, when the defect is found to be unresolved the team of QA is ordered to carry over the process of rectifying the bug. This usually happens when the developer is unsuccessful in providing a solution of the bug. Then the tester has all the rights to resume with the entire process again.
Sometimes, a defect cannot be addressed in the current life cycle; then it is postponed or kept aside for future release.
The defect can be rejected on the basis of following grounds such as duplicate or repetitive bug, Not a defect, or non-reproducible bug.
Using the defect life cycle, the testers can actually identify a defect at any stage. While experimentally testing a case you can seek a hidden defect. The defect life cycle plays a crucial role in bringing out defects from an operation. The testers are recommended to strictly adhere to the complete process without getting disoriented at any stage.