MSF for CMMI Process Improvement Visual Studio Team System logo
role icon

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.

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.

(C) 2005 Microsoft Corporation. All rights reserved.

MSF for CMMI Process Improvement: Build 050707