Defect /Bug Life Cycle

Defect / Bug

A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.

Defect / Bug / Incident / Issue: The meaning for these words is same; any functionality not working as per requirements.

Error: Any mistake in the program is an error; the error can be caused because of Syntax / Logical Error / Runtime Error.

Failure: If the application / software is not satisfying the customer need it is failure product.

Life cycle of Bug:

Report New Defect: When any functionality is not working as per requirement the tester can report a defect to developers

The Defect Report has the fields like DefectID, Summary, Detected By, Date Found, Assigned To, Severity, Module, Build Ver, Priority, Status, Reproducible, Fixed By, Environment, Expected Result, Actual Result, Comments

Defect Life Cycle

Bug status description:



Following are various stages of bug life cycle. The status caption may vary depending on the bug tracking system you are using.

1) New: When a Tester files new Defect.

2) Deferred / Postponed: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred

3) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

4) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.

5) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.

6) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.

7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action.

8) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.