LifeCycle Of A Testing Bug

New

When a bug is detected in an application, it is assigned a status called ‘New’. This implies that the defect found is yet be approved or studied. Following this, proper defect documentation is submitted to the development team so that they can reproduce and fix this defect. This ‘NEW’ defect further undergoes many status updates.

Assigned

The defects assigned a status ‘New’ are further put through approval study by the test lead, project lead or development lead to check if it is valid or not. In case the bug is found valid it is assigned to a member of the development team by Test Lead/Project Lead or Manager. This is where the ‘New’ status is changed to ‘Assigned’. The developer further fixes this defect and updates the status to ‘Complete’.

Open

At this stage, the development team begins scrutinizing the bug. After the ‘Assigned’ stage or at this level the bug is further categorized into states such as Duplicate/ Deferred/ Dropped/ Not a bug.

Deferred

At times, the ‘Assigned’ bug status may be updated to ‘Deferred’ by the Project Manager or Project Lead .This happens due to the following reasons:

• If the bug is found to have a minor or not much important fix or if it is found during the end of the release.
• If the bug is not associated with the current build.
• If the defect seems to get fixed by the next release.
• Often the customer thinks of changing the requirement. Thus the status is changed to “deferred” and planned to be fixed by next release.

Dropped Or Rejected

If the bug assigned or opened is logged due to certain misinterpretation (a reference to some old requirements or features) despite the system working in accordance with the specifications then the Team leads or developers marks such bug ‘Rejected’. Along with the status update, the team lead should provide a specific reason for the above action.

Duplicate

The defect which is repeated twice or the one which is corresponding to the same concept of the bug is changed from an ‘Opened’ status to ‘Duplicate’ by the development team.

Fixed

Once the necessary changes in the code are performed and verified by the developer then the status of the bug is changed to ‘Fixed’. This bug is then passed onto the testing team.

Pending Retest

Once the developer has fixed the defect he/she gives a part of the code in particular for retesting. Since the test is to be performed at the tester’s end it holds a ‘Pending Retest’ status.

Retest

The Tester performs retesting at this stage to check the existence of defect fixed by the developer and alter the status as ‘Re-test’.

Reopen

If the defect is found to exist fully or partially after the retest, then the tester updates it using defect retesting document with the status back to ‘Reopen’. Again the bug is driven through the same procedure lifecycle to be fixed and completed again.

Verified

Luckily, if after retesting the bug fixed by the developer no defect is spotted in the software, then the bug is said to be fixed and the status assigned at this stage is ‘Verified’.

Closed

If the Tester or the Test Lead finds that the bug no longer exists then the status of the bug is changed to ‘Closed’. This makes the end of the bug life cycle.

At times certain variations are found related to the statuses in the cycle. These are

• Cannot be fixed: If the bug is not technology supporting, or there is a certain problem of the product the status of a bug is termed as ‘Cannot be fixed’. Sometimes this happens if the cost of fixing a bug is high.
• Need more information: If a developer is not able to coordinate with the tester by working according to the assigned steps then the developer changes the status to ‘Need More Information’.

Although most companies prefer to work on preventing defect which is more effective than decreasing the number of defects yet following a structured plan to remove bugs has proved to be helpful across many organizations.