A bug life cycle traces the status of a bug from the time it is first found out till its eventual elimination by the testers. During this life cycle, it has to be ensured by the testing team that there should be no chance of bug being reproduced again.
With the flow diagram as a reference, here’s a brief status-wise description of the bug life cycle.
When a bug is detected for the first time in the software, its status is designated as new.
After a testing professional has detected a bug, the lead tester acknowledges its existence and gives his approval to assign the defect to the project manager of the development team.
This is the stage where the bug undergoes thorough analysis by the development team. At this point, the development lead has to make a decision to either reject the initial finding of the testing team in identifying the flaw or defer it’s rectification to another date.
Many a times, a flaw sent to the development team is so innocuous, that it is not even considered a bug and is rejected.
Sometimes due to time constraints, the development team has to categorise certain bugs on a priority basis and may push less critical bugs to the backburner.
There are occasions when a flaw which has been cleared by the QA team or a bug whose nature is pretty similar to a previously dealt flaw resurfaces. Such examples are categorized as duplicates.
After the development team has rectified the flaw with modifications in the form of necessary changes to the program code, it is said to be ready for re testing.
When the bug is not fixed, QA team reopens the bug and it must change the status of being “reopened” and the flaw undergoes in the same cycle once again.
After the flaw has been given a go-ahead by the development team, it needs a final verification in the form of a retest by the testing and QA team.
This is the final state of bug that can be closed after QA retesting. And, finally it can be marked as fixed or closed.