Bug Life Cycle

Defect life cycle or bug life cycle is a very important point, each and every tester should know about it. Main target of tester is not only find the bug/ defect in the software but also also keep the track of that bug till its closer. So bug life cycle is a life cycle of bug from its origin to its closer. Origin point is when tester find a bug and closer or closing point is when tester re-retest and close it.

Below shown diagram is a the Bug life Cycle. 

See how bug goes through a number of phases in his entire life. We are going to discuss each phase one by one.

NEW :

When tester execute its test cases and output of that test case is not as expected then tester can say he has got a bug. Means a variance between the expected result and actual result is called bug. So the tester need to get fix this bug but he cant fix that bug by himself, developer need to fix this. But do tester directly go to developer and tell them ? like hey developer I found the bug, fix this soon. The answer is no. Tester need to submit this bug to his Team Lead first and team lead will assign the developer to fix the bug after his analysis.

Important : when tester finds a bug then it is in NEW state.

OPEN :

Once the bug is submitted by the tester them team leads work get started. Team lead need to verify the submitted bug. Team lead need to do some entry checks, you will get a idea by looking below image. 

Following actions need to performed by the team lead.

REJECTED:

The bug is marked as a rejected when that bug is invalid. Meaning of invalid is, some time tester may misunderstood the functionality and can mark feature as a bug, in that case that bug is rejected by team lead after evaluation.

Important: when tester report a bug but which is a feature of software then team lead mark it as rejected.

DUPLICATE :

If bug is a valid bug then team lead will check whether that bug is already reported by other tester or not. If it is reported by other tester then team lead mark it as DUPLICATE. If that bug is not reported by other tester then team lead look for scope.

As we know, we are working in a team. There is a chances that the same software or same module is assigned to more than one tester, in that case similar bug can be found by many tester. So team lead need to ensure that, same bug should not get reported twice or may be more than that.

Important: if same bug is reported by two or more tester then second reported bug is marked as DUPLICATE.

DEFERRED:

If that bug is not a duplicate bug then team lead will check that bug for DEFERRED status.

If the bug is not a part of current release then that bug can be marked as deferred. Means suppose you are working in agile methodology and they have divided the project requirement into a small builds which are called sprints, say they divided the project requirements into the 10 sprints, like sprint 1, sprint 2…..up to the 10 sprint. And currently you are working on sprint 1 but the bug you have found is related to the future sprints say it related to the sprint 2. but the next release is for sprint 1. in such a scenario team lead mark that bug as DEFERRED. DEFERRED bug is a bug but it need to resolve in future release.

Important: when a bug is a part of future release then it is marked as DIFERRED.

ASSIGNED:

When that raised bug is valid, unique and part of current release then team lead assign that bug to developer. 

FIX:

Here developer start working on bug to fix it. Developer make proper changes to fix the change. And make available that change for testing.

RE-TESTING:

After fixing of the bug that feature/functionality is available for the testing, here tester executes those failed test cases and verify now that feature is producing proper output or not.

CLOSED:

When that bug is fixed and re-tested and found working fine then tester mark it as close.

RE-OPENED:

There are two situation In which we need to re-open the bug.

Situation1: when developer fix the bug and tester re-test it and after re-testing if same bug is present or developer said he fixed the bug but still same bug is present then tester re-open the bug and again assign that bug to developer for fixing.

Situation2: there are some cases where the fixed bugs are again appears, in that situation we need to re-open that closed bug and assign it to the developer again.

So this is all about bug life cycle, you may find different bug life cycle diagram on different resources but this one is easy to explain once you understand the diagram.

<< PREVIOUS || NEXT >>