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

Project Portal
| Bug
### Work Item Database
Overview |
States and Transitions |
Fields |
### Process Guidance |
Activities |
Workstreams |
Bug Fields A bug is a work item that communicates that a potential problem exists or has existed in the product. The goal of opening a bug is to accurately report a problem in a way that allows the reader to understand its full impact. The descriptions in the bug work item 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.
Found In | This field displays the build number where the bug was found.
Area Path | The Area Path is used to group the bug by feature or team in the project hierarchy. It must be a valid node in the project hierarchy.
Iteration Path | The Iteration Path identifies in which iteration the bug will be fixed.
Assigned To | 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. Valid values are High, Medium, and Low.
State | Required. A bug can be in the Proposed, 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.
Fix | A description of the proposed change to fix the problem.
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.
ID | The unique identifier used to identify the task. Team Foundation Server automatically creates the ID when the work item is created.
Symptom | A description of the observed problem.
Steps to Reproduce | Detailed steps for how to reproduce the bug.
Found-in Environment | A description of the setup and configuration where the bug was found.
Root Cause | A description of the cause of the error. Valid values are Coding Error, Design Error, Specification Error, and Communication Error.
How Found | A description of how the bug was found. For example, was the bug found during a customer review? Was it found through ad hoc testing?
Severity | This field is a subjective rating used to assess the impact of not fixing the bug. Valid values are Critical, High, Medium, and Low.
Created By | Identifies who created the bug. This information appears in the History field and not in its own field.
Created Date | Identifies when the bug was created. This information appears in the History field and not in its own field.
Changed By | Identifies the person who last made a change to the bug.
Changed Date | Identifies the date the bug was last changed.
Closed By | Identifies the person who closed the bug.
Closed Date | Identifies the date the bug was closed.
Triage | Indicates if the bug has been triaged.
Blocked | Indicates if progress on resolving the bug has been blocked. If an Issue work item has been opened to track the blocking problem, a link should be made to that work item as well.
Integrated In | Indicates the build that contains the changes that resolve the bug.
Test ID | Indicates the ID number of the test that was run on the bug code. This appears as ID on the Test tab.
Test Path | Indicates the path of the test that was run on the bug code. This appears as Path on the Test tab.
Estimate | An estimate in person hours to implement the fix.
Remaining Work | An estimate in person hours of the work remaining to implement the fix. This information appears on the Details tab.
Completed Work | An estimate in person hours of the time spent to date to implement the fix. This information appears on the Details tab.
Attachments | Contains the files that have been attached to the bug.
Links | This field shows the other work items that have been linked to the bug.
Resolved By | Identifies who resolved the bug. This information appears in the History field and not in its own field.
Resolved Date | Identifies when the bug was resolved. This information appears in the History field and not in its own field.
© 2005 Microsoft Corporation. All rights reserved. MSF for CMMI Process Improvement: 1.00.0000.00 |