Life Cycle of a Software Bug

Once a bug(defect or error) is found, it should be communicated to the developers who can fix it. Once the bug is fixed/resolved, the fix should be verified by the testers and should be closed.

The following topics are discussed in this page
Bug Information:Information that should be captured in the bug so that developers can clearly understand the bug and fix it.
List of Bug statuses:
Lifecycle of some types of bugs:
Analysis of bugs:Bugs logged during a testing phase a invaluable source to improve the existing testing processes.

Bug information

The following information should be captured in the bug so that developers can clearly understand the bug, get an idea of it's severity, and reproduce it if necessary.Also the developer should mention in the bug, the cause of the problem, steps he has taken to fix it/fix description, steps he has taken to verify the fix and any information that helps to prevent such issues in future.

Bug ID : A unique identifier(number) of the bug

Bug status: In the long road between logging bug and fixing it, the status of a bug communicates where it is.Eg: New,Assigned,fixed,closed etc.
A list of different bug statuses are mentioned below along with their descriptions.

Application details: Details of the application like application name, version, URL, database details etc.

Component and/or subcomponent: The part of the application in which the bug was found by tester

Enviroment details: Such as Operating system, hardware platform etc.

Severity/Criticality:

Priority: For bugs of same severity, this field can be used to decide which one's to fix first.

Test case name/number/identifier:

Subject: One-line description of the bug

Bug Description: A detailed description of the bug

Reproducible steps: A step by step description to reproduce the bug

Data used:

Additional information: File excerpts,error messages,log file excerpts, screen shots that would be helpful in finding the cause of the problem or fix it.

Tester name:

Tester contact details:

Bug reporting date and time:

Assigned to: Developer to which the bug is assigned.

Description of problem cause:

Description of fix:

Code section/file/module/class/method that was fixed:

Date of fix:

Version of the file that contains the fix:

List of Bug statuses

New: When a bug is found, the tester logs the bug and the status of ‘New’ is assigned to the bug.

Assigned: The development team verifies if the bug is valid. If the bug is valid, development leader assigns it to a developer to fix it and a status of ‘Assigned’ is set to it.

Additional information Requested: When developer/dev_lead needs more information from tester to understand the bug

Not Reproducible: When dev lead could not reproduce the bug

Not a Bug: Invalid bug(a bug that does not require any code fix)

Duplicate Bug: Already a bug is logged for the same issue

Deferred: The fix of the bug is postponed to some future release.

Fixed but not patched: The bug is resolved but the fix is yet to pushed to testing instance.

Ready for retesting : The fix is pushed to testing instance and ready for retesting by tester

Closed,fix verified: The tester verifies the fix and the bug is resolved completely

Closed,Not a bug: The tester verifies the bug and finds the bug does not require code fix

Closed,Duplicate bug:

Reopened: The tester verifies and finds the bug is not fixed(either completely or partially)

Lifecycle of some types of bugs

Valid bug: New -> Assigned -> Fixed but not patched -> Ready for retesting -> Closed,fix verified

Invalid bug: New -> Not a Bug -> Closed,Not a bug

Duplicate bug: New -> Duplicate Bug -> Closed,Duplicate bug

Reopened bug: New -> Assigned -> Fixed but not patched -> Ready for retesting -> Reopened -> Fixed but not patched -> Ready for retesting -> Closed,fix verified

Analysis of bugs

Bugs logged during a testing phase a invaluable source to improve the existing testing processes.The holygrail for any testing team is zero customer bugs.Once a product is released, majority of the customer bugs come within 6months to 1 year of product usage.
But immediately after a testing of product is over the following can be done.

-Testing Team should analyze all the invalid/duplicate/could_not_be_reproduced bugs and come up with measures to reduce their count in future testing efforts.

Once customer bugs start pouring in the following can be done.

-Testing Team should analyze each and every customer bug,find out why they have missed them in their testing effort and take appropriate measures.