Bug Management

The information in this section is taken directly from the MSF Principles of Application Development course # 1516.

A bug is anything that needs to be addressed and resolved before an application is released. Despite the widely held perception that all bugs are defects, they are not. Defects are a category of bugs, but a bug is any issue that arises from using the application that is being developed. Examples of bugs include:

• Enhancement requests.
• Suggestions that are out of scope for the release.
• Issues that arise over user preferences.
• Unavoidable design consequences.
• Defects.

Bug tracking processes encompass such issues as bug reporting, prioritization, assignment, resolution, and closure. Understanding the exact status of the application at all times is fundamental to the Stabilizing Phase. Bug tracking and its output is the process that provides this exact status. Bugs have to be tracked and managed so that the project team can make necessary tradeoff decisions during the Stabilizing Phase. A large part of stabilizing is managing tradeoff decisions about what the team will fix and what it won't. The team must classify bugs in terms of their priority and their risk so that it can determine the proper form of resolution.

Tracking

Before the bug tracking process begins, some sort of bug repository, typically a database, must be established. Newly found bugs are reported by entering them into the database. Each tester enters the bugs they find. Newly identified bugs should be automatically categorized as active.

As bugs are reported, the Development team leader prioritizes and assigns them to specific developers for resolution. In the Stabilizing Phase, the Development team leader might personally resolve the bugs that will not be fixed.

For each bug that requires a development-based resolution, a developer typically resolves it by fixing it. The developer then tests the fix to ensure that it has been effected and that no new bugs have been introduced in the process. When the active bug has been resolved, its status changes to reflect the method of resolution. Next, a tester must ensure the quality of the fix and ascertain that no new bugs have been introduced. If a new bug has been introduced, the tester enters it into the bug database, thus starting the cycle all over again. If the fix did not successfully resolve the original bug, the Development team leader reactivates the bug. Only when a bug has been successfully resolved is it finally closed. Instead of fixing the bug, the team can always decide to document the bug as part of the released product. Thus, the team chooses to postpone fixing the bug until after the product release.

Classification

Bug classification provides a way of identifying priorities and risk. Classifying bugs encompasses two important issues: severity, which addresses the impact of the bug on the overall application if it is not fixed, and priority, which measures the bug's importance to the stability of the application. It is not enough to report bugs; they must be classified to become actionable.

Typical severity level classifications are:

• Severity 1: System crash This class of bug causes the system to crash, hang, or otherwise stop working, with the risk of total data loss.
• Severity 2: Major problem This class of bug represents a serious defect in the software function, but does not necessarily risk total system failure or data loss.
• Severity 3: Minor problem This class of bug represents a defect in the function of the software, but not one with much risk of lost data or work.
• Severity 4: Trivial This class of bug represents what is primarily a minor cosmetic problem, which most users are unlikely to notice.

Typical priority level classifications are:

• Priority 1: Highest priority A show-stopping bug. The application cannot ship, and the team may not be able to achieve the next interim milestone.
• Priority 2: High priority A major bug. The application cannot ship, but the team may be able to achieve the next interim milestone.
• Priority 3: Medium priority The application can ship, and the team can achieve interim milestones. These bugs are low enough in priority that they tend to be fixed only if there is enough time at the end of the project and fixing them does not create a significant risk.
• Priority 4: Low priority Low priority bugs typically are enhancement requests and bugs that are not worth fixing.

Resolution

Resolving a bug is not the final step in bug tracking. It's an interim step towards closure. Closure occurs only after a tester determines that fixing the bug did not create another problem and that the bug is unlikely to surface again.

Bugs are typically resolved as:

• Fixed The developer has fixed the bug, tested the fix, checked in the code, assigned the fix to a product release number, and assigned the bug back to the tester who reported it.
• Duplicated The bug is a duplicate of another one that is already in the bug database. The duplicate bug is resolved, closed, and linked to the original bug.
• Postponed The bug will not be fixed in the current release, but might be fixed in a subsequent one. This designation is used when the team sees value in fixing the bug but does not have the time or resources to correct it.
• By design The behavior reported is intentional and is called out in the Functional Specification.
• Can't reproduce The developer can't verify the existence of the bug with any level of consistency.
• Won't fix The bug will not be fixed in the current release because the team does not think it's worth the effort, or the management or customer has deemed it unimportant.