Overview |  | Roles |  | Work Items |  | Views |  | Index |  | Glossary |

Project Portal
| Bug
### Work Item Database
Overview |
States and Transitions |
Fields |
### Process Guidance |
Activities |
Work Streams |
Bug Fields A bug is a work item that communicates that a potential problem exists or has existed in the system. The goal of opening a bug is to accurately report bugs in a way that allows the reader to understand the full impact of the problem. The descriptions in the bug report should make it easy to trace through the steps used when the bug was encountered, thus allowing it to be easily reproduced. The test results should clearly show the problem. The clarity and understandability of this description often affects the probability that the bug will be fixed.
Field | Description
--- | ---
Title | Required. The title provides a concise overview of the problem to be fixed. The title should be descriptive enough to allow the triage team to understand what area of the product is affected and how.
Issue | Issue is a Yes or No value indicating if fixing the bug is blocked in some manner. If this field is set to Yes, the scenario will appear on the project manager’s issue report.
Found in Build | This field displays the build number where the bug was found.
Resolved in Build | This field holds the build number in which the bug is resolved.
Test Name | This field identifies the name of the test associated with this bug.
Test ID | This field identifies the ID of the test associated with this bug.
Test Path | This field identifies the path of the test associated with this bug.
Area | The area is used to group the bug by feature or team in the project hierarchy. The area must be a valid node in the project hierarchy.
Iteration | The iteration identifies in which iteration the bug is fixed.
Assigned To | This field identifies the person that the bug is currently assigned to. If the bug requires multiple development fixes, it can be treated like a scenario and assigned to the person who is next in the dependency chain. The bug report is assigned back to the tester when all of the pieces are integrated.
Priority | Required. The priority is a subjective importance rating. Priority 1 indicates the product cannot ship and must be fixed as soon as possible. Priority 2 is an important bug that does not need to be fixed immediately but must be fixed before release. Priority 3 is an optional bug that may or may not be fixed depending on resources, time, and risk.
State | Required. A bug can be in the Active, Resolved, or Closed states.
Reason | Required. The reason a bug is in the current state. For example, a bug can be in the resolved state because it was Fixed.
Description | The description provides an area to describe the problem and the steps to reproduce it.
History | This history is a running discussion about the bug report that accumulates additional written entries as changes are made. Each time a change is made to the bug, an entry is made in the History field describing what change was made and why, as well as any additional pertinent information about the change.
(C) 2005 Microsoft Corporation. All rights reserved. Build 97 |