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:
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.
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.
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:
Typical priority level classifications are:
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: