Bug Life Cycle

 


Software development comprises various phases which are collectively called Software Development Life Cycle (SDLC). At every step the software evolves into a more advanced product. Software testing happens in the later stage of SDLC. During this phase, the product is checked for errors as well as it is verified against the user requirements. Software bug is defined as any error, flaw, fault, mistake which prevents the software from producing the expected output. Bug is often the result of human errors either in the source code or the design itself. From its discovery to its resolution, a bug passes through various stages, commonly called 'bug life cycle'.

Life Cycle of a Bug

Given below are the stages of a bug life span. Test reports describe in detail the behavior of bug at each stage.

New
This is the first stage of bug life cycle in which the tester reports a bug. The presence of the bug becomes evident when the tester tries to run the newly developed application and it does not respond in an expected manner. This bug is then send to the testing lead for approval.

Open
When the bug is reported to the testing lead, he examines the bug by retesting the product. If he finds that the bug is genuine, he approves it and changes its status to 'open'.

Assign
Once the bug has been approved and found genuine by the testing lead, it is then send to the concerned software development team for its resolution. It can be assigned to the team who created the software or it may be assigned to some specialized team. After assigning the bug to the software team, the status of the bug is changed to 'assign'.

Test
The team to which the bug has been assigned works on the removal of bug. Once, they are finished with fixing the bug, it is sent back to the testing team for a retest. However, before sending the bug back to the testing team, its status is changed to 'test' in the report.

Deferred
If the development team changes the status of the bug to 'deferred', it means that the bug will be fixed in the next releases of the software. There can be myriad reason why the software team may not consider fixing the bug urgently. This includes lack of time, low impact of the bug or negligible potential of the bug to induce major changes in the normal functioning of the software.

Rejected
Although, the testing lead might have approved the bug stating it as a genuine one, the software development team may not always agree. Ultimately, it is the prerogative of the development team to decide if the bug is really genuine or not. If they doubt the presence or impact of the bug, then they may change its status to 'rejected'.

Duplicate
If the development team finds that the same bug has been repeated twice or there are two bugs which point to the same concept, then the status of one bug is changed to 'duplicate'. In this case, fixing one bug automatically takes care of the other bug.

Verified
If the software development team sends the fixed bug back for retesting, then the bug undergoes rigorous testing procedure again. If at the end of the test, it is not found then its status is changed to 'verified.'

Reopened
If the bug still exists, then its status is changed to 'reopened'. The bug then traverses the entire of its life cycle once again.

Closed
If no occurrence of bug is reported and if the software functions normally, then the bug is 'closed.' This is the final stage in which the bug has been fixed, tested and approved.

Bug life cycle is an important concept in software testing. Understanding bug life cycle is important from the point of view of delivering an error free software to the customer.