Bug Life Cycle

As software professionals, we are familiar with the word ‘bug’. It refers to the flaws in the program that make it to behave in ways it is not supposed. In this post, I have written about the bug life cycle.

What is a bug?

Before launching into the life cycle part, let us understand the word

Here are some simple definitions of Bug/Defect:

• Bug is the fault or flaw in a program that causes it to behave abruptly. Bugs are ideally found by developers (during unit testing) or by Test Engineers (during testing phase).
• In simple words, when there is a difference in expected result and actual result while testing the program/application, it results in a defect/bug.
• When the actual result does not meet the end user expectations, it results in a defect/ bug.
• When developed application is not according to the details specified in SRS, it results in a defect/ bug.

When a bug is found by a tester, he needs to convey the information to the developer. In order to do this, testers prepare bug reports which consist of the following fields:

1. Bug ID: Each bug has a unique ID for identification.
2. Date: This column contains the date of testing, bug logged date and other such information.
3. Bug Description: It’s a short description of the bug.
4. Build Version Number: The number of build version, in which it is found.
5. Steps to reproduce the Bug: These are detailed steps to reproduce the bug.
6. Reported by: Name of the tester who has raised the bug.
7. Assigned to: Name of the developer, who worked on it.
8. Status: Status of the bug, whether it is new, assigned, open, closed etc.
9. Severity: Based on the severity, it tells us the impact of the bug on the application.
10. Priority: Based on the priority, it tells the urgency to fix the bug.

Priority & Severity of the bugs:

Priority indicates the frequency of bug occurrence. Priority is associated with the schedule. There are several types of priorities:

1. Urgent: These type of bugs must be fixed in next build.
2. High: These type of bugs must be fixed in one of the upcoming releases but must be included in the release.
3. Medium: These bugs can be fixed after the release (next release)
4. Low: These are considered as deferred bugs. They may or may not be fixed.

Priority is mentioned as:

• P1: Urgent
• P2: High
• P3: Medium
• P4: Low

Severity means the impact of the bug on the system.

There are several types of severity such as - Critical, Major, Minor and Trivial.

1. Critical: This defect affects critical data or function. These type of bugs do not have a workaround. For eg: Unsuccessful Installation.
2. Major: This defect affects a major functionality or major data. These type of bugs have a workaround which are not difficult. For eg: Functionality of one module is not working, but the process can be completed by following other lengthy steps, so it has a workaround.
3. Minor: The defect affects minor functionality. This type of a defect has an easy workaround. It won’t affect any major functionalities or critical data. For eg: A simple function that is not working in one module can be done through the other module.
4. Trivial: The defect don’t affect any functionality or does not need a workaround. These type of defects don’t impact the productivity. For Example: spelling mistakes, layout discrepancies.

Severity is mentioned as:

S1: Critical
S2: Major
S3: Minor
S4: Trivial

Bug Life Cycle:

Here are some simple steps to understand the bug life cycle:

1. When a new bug occurs, the test engineer checks whether this is a new, deferred or duplicate type of a bug. Test lead/project manager also verifies the newly logged bug.
2. If the new bug is the same as an existing one, he/she marks the bug as duplicate and closes the bug.
3. If the new bug is a deferred type, he closes the bug. Deferred Bugs are bugs which are expected to be fixed in the next release or the logged bug priority is too low in the current release.
4. If the bug is new, test Engineer assigns the bug to the responsible person (developer).
5. The developer fixes the assigned bug and reassigns it to the Test Engineer.
6. Test Engineer retests the fixed bug and marks the status according to that.
7. If the bug is reproduced then the Test Engineer rejects the fix. He marks the status as re-opened and reassigns it back to developer. The developer fixes the bug again and assigns it to Test Engineer for retesting.
8. If the bug is fixed/ resolved, the Test Engineer marks the bug as resolved and closes the bug.

This is how the Bug Life Cycle works. The process of reassigning is continued till the bug gets resolved. The Bug Life Cycle image given below makes things clearer: