Bug Life Cycle in Testing
A bug is an error or flaw in software that causes unintended or unexpected behavior in that software. Whether they have been found or not, all software has bugs. The removal of bugs is highly dependent upon the effectiveness of testing that is performed on the software. The process of finding and fixing bugs can be both inefficient and costly so engaging in activities that prevent defects can be an advantageous use of resources for an organization.
In an organized software development process a bug will go through a standardized life cycle. A bug life cycle is basically the time between detection of the bug through when the bug is fixed and/or closed. During the bug life cycle, a bug is typically assigned several different statuses. The stages in a bug life cycle may vary from one organization to the next depending on testing process being followed and which, if any, defect tools are being used. However, most bug life cycles used are similar to the following: New, Open, Assign, Test, Verified, Deferred, Reopened, Duplicate, Rejected, and Closed.
The stages and flow of these general cycles is depicted in the following diagram:
- bug-life-cycle
Bug Life Cycle Stages
1. New – In this stage, the bug has just been discovered by a tester or less desirable, a user. At this point, the bug has merely been detected and has not yet been approved. When a bug is found, in order to be properly diagnosed and fixed, it is important that the description of the problem is both accurate and detailed. It is best to describe the behavior that occurred and the action that produced it or the action that was performed followed by the expected behavior that did not follow.
2. Open- After the bug has been detected, depending on the structure of the organization, the leader or board must determine whether it is legitimate and either approve or reject it. If approved, the status is updated to “Open”.
3. Assign- Once the bug has reached the “Open” status it can be assigned to a developer or developer team, who now has the responsibility to handle the issue to completion. Some organizations combine the open and assign phases. In these cases, bugs are assigned at the same time that they are opened.
4. Deferred- Rather than being assigned to a developer for immediate resolution, a bug can be deferred. This simply means that it will be fixed in either the next or a later software release. Bugs are often given this status for reasons such as low priority, or lack of time before the next release, or magnitude of its affect on the overall software or system.
5. Rejected- A bug can be rejected if either the leader or the team determines that it is not a valid issue. Since it has already been opened, detailed justification for rejection is required.
6. Test- Once a bug has been fixed, it must be tested. Some organizations split this phase into “Fixed” and “Test” phases. In these cases, when a developer fixes a bug, he or she changes the status to “Fixed” so that the test team will know when it is ready to be verified by the test group. Some organizations provide sub-stages that allow the developer to update statuses of bugs that they are not able to fix. Some examples of these include the following:
- Intermittent Issue: The developer is not able to reproduce the problem and therefore cannot diagnose and implement a solution.
- Insufficient Information: The developer needs more information on the bug from the Tester.
- Won’t/Can’t Fix: If for any reason, it is decided that the bug can’t or simply won’t be fixed.
7. Reopened- During this phase, it may also be determined that the bug still exists and needs to be returned to a previous stage. This is also used when bugs have been partially fixed.
8. Verified- When the bug has been fixed, the test team performs further testing to verify that it is an adequate resolution to the problem.
9. Closed- This is the final stage of the bug lifecycle. Once it has been determined that the bug no longer resides in the software, it can be closed.
Determining Severity in the Bug Life Cycle
During the open and/or assign phases, bugs are often prioritized, so that the ones that have the greatest impact on the software or system are handled before those that have the lowest impact. Again, the levels of severity assigned my vary from organization to organization, but most utilize a priority level system such as the following:
1. Critical: This is reserved for the most severe bugs. These types of bugs hinder functionality and sometimes even prevent further testing. In these cases, there is usually no workaround available and the bug must be fixed immediately. (Alternate Name: Show Stopper)
2. High: In this case, the bug causes the software to not function as designed or expected or may cause some other functionality to fail. Usually, a workaround is available for these types of bugs. (Alternate Name: Major)
3. Medium: In this case, the bug is usually a defect that does not conform to standards or conventions and usually a workaround exists that allows the software to maintain basic functionality. (Alternate Name: Average)
4. Low: Reserved for defects that do not affect the functionality of the system. These are often cosmetic problems. (Alternate Name: Minor)
Bug Life Cycle Implementation Tips
An organized bug life cycle can benefit an organization by making its processes more efficient, which saves a lot of resources, especially time and money. The following are things to keep in mind when implementing a bug life cycle:
- Make sure that the bug life cycle is documented and that each member of the team understands the flow and the meaning of each of its stages/statuses.
- Ensure that everyone on the team clearly understands their role and responsibility in regards to bug resolution.
- Require that all status changes be accompanied by adequate detail. For example, it is not adequate to status a bug as “Rejected” without indication as to why it was thrown out.
- Don’t cut corners. All changes and request should be handled according to the stated process. This is especially important if a tracking tool is being used to obtain metrics that will be used for later analysis.
