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. |
In Build |
This field displays the build number where the bug was found. |
Affected Area |
The Affected Area is used to group the bug by feature or team in the project hierarchy. The Affected Area must be a valid node in the project hierarchy. |
Planned Iteration |
The Planned Iteration 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. |
Change Description |
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 Date |
Identifies when the bug was created. |
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. |