Bug (GovDev)

You can learn how to fill in the details of a bug work item in this topic. For information about how to create a bug work item, see Work Items and Workflow (GovDev).

Required Permissions

To view a bug, you must be a member of the Readers group or your View work items in this node must be set to Allow. To create or modify a bug, you must be a member of the Contributors group or your Edit work items in this node permissions must be set to Allow. For more information, see Managing Permissions.

Defining a Bug

A bug communicates that a potential problem exists in the code that your team is developing. When you define a bug, you want to accurately report the problem in a way that helps the reader to understand the full impact of the problem. You should also describe the actions that you took to find the bug so that other members of the team can more easily reproduce the behavior. The test results should clearly show the problem. Clear, understandable descriptions affect the probability that the bug will be fixed.

The work item form for a bug stores data in the fields and tabs that the following illustration shows:

Work Item Form for Bug

When you define a bug, you must define the Title in the top section of the work item form and type text in the Symptom box on the Details tab. You can leave all other fields blank or accept their default values.

To define a bug

  1. In the top section of the work item form for a bug, specify one or more of the following fields:

  2. On the Details tab, specify one or more of the following types of information:

    • In Steps to Reproduce, provide as much detail as needed so that another team member can understand the problem that must be fixed.

      You can format the content that you provide in this field.

    • In the History box, provide as much detail as you want.

      You can format the content that you provide here.

      Every time that a team member updates the bug, its history shows the date of the change, the team member who made the change, and the fields that changed.

  3. On the System Info tab, specify one or more of the following types of information:

    • In the Found in Build list, click or type the name of the build in which the defect was found.

      NoteNote

      Each build is associated with a unique build name. For information about how to define build names, see Customize Build Numbers.

    • In Integrated in Build, do not specify a build when you create the bug. When you resolve a bug, type the name of the build that incorporates the code or fixes a bug.

    • In System Info, describe the software environment in which the bug was found.

  4. (Optional) Link the bug to another work item, such as a test case or another bug.

    For more information about these activities, see Linking a Test Case to a Buglater in this topic.

  5. On the work item toolbar, click Save Save Work Item.

    NoteNote

    After you save the bug, the identifier appears in the title under the work item toolbar.

Linking a Test Case to a Bug

Linking a Use Case to a Bug

Adding Details and Attachments to a Bug

You can add information to a bug that helps others reproduce or fix the bug. You add details to bugs in the following ways:

  • Type information in the Steps to Reproduce or History fields.

  • Attach a file.

    For example, you can attach an e-mail thread, a document, an image, a log file, or another type of file.

  • Add a hyperlink to Web site or to a file that is stored on a server or Web site.

To add details to a bug

To add an attachment to a bug

  1. On the Attachments tab, perform one of the following actions:

    • Drag a file into the attachment area.

    • Click Paste, or press CTRL-V to paste a file that you have copied.

    • Click Add Attachment Add, and then click Browse. In the Attachment dialog box, type or browse to the name of the file that you want to attach.

      (Optional) In the Comment box, you can optionally type additional information about the attachment. To return to the Attachments tab, click OK.

  2. Click Save Save Work Item.

Resolving and Closing Bugs

When a bug has been fixed, you change its State from Activeto Resolved. When the fix has been verified, you change its state from Resolvedto Closed. Any team member can change the state of a bug. Also, a bug that cannot be fixed can be resolved for other reasons as described later in this topic. For more information, see Assignments and Workflow (GovDev).

To resolve or close a bug

  1. Open the work item form for the bug.

  2. In the State list, click Resolved or Closed.

    • If you change the state from Active to Resolved , the Reason field changes to Fixed .

      Verify that the value for Reason is correct, or click a different option.

      For more information, see From Active to Resolvedlater in this topic.

    • If you change the state from Resolved to Closed, the Reason field changes to Verified .

  3. Click Save Save Work Item.

Typical workflow progression:

  • A team member creates a bug in the Activestate with a default reason of New.

  • A team member changes the state of a bug from Active to Resolvedto indicate either that the bug has been fixed or for some other reason.

  • A team member tests a bug that has been marked as fixed, verifies that it has been fixed, and changes the state of the bug from Resolved to Closed .

Additional workflow transitions:

  • A team member finds that a resolved bug is not fixed or a test fails and changes the state of the bug from Resolved to Active.

  • During regression testing, a team member finds that a closed bug is recurring and changes the state of the bug from Closed to Active.

Bug State Diagram

Bug state diagram

Active (New or Build Failure)

A team member creates the bug, provides a descriptive title, and, in Description, adds as much detail as possible about the bug. The bug remains in the active state as it is being investigated and fixed.

From Active to Resolved

You can specify one of the reasons in the following table when you resolve a bug:

Reason

When to use

Additional actions to take

Fixed (default)

After you fix the problem that the bug identifies, run unit tests to confirm that the problem is fixed, and check in the changed code.

Link the bug to the changeset when the fix is checked in.

Deferred

When the bug will not be fixed in the current iteration. The bug will be postponed until the team can reevaluate it for a future iteration or version of the product.

(optional) Move the bug to a future iteration or the backlog, and maintain it in an active state.

Duplicate

When another active bug reports the same problem.

Create a link to the bug that remains active so that the team member who created the duplicate bug can more easily verify the duplication before closing the bug.

As Designed

When the bug describes an expected condition or behavior of the system or is outside the acceptance criteria for either the application area or the use case that the bug affects.

None.

Cannot Reproduce

When team members cannot reproduce the behavior that the bug reports.

None.

Obsolete

When the bug no longer applies to the product. For example, a bug is obsolete if it describes a problem in a feature area that no longer exists in the product.

None.

The following data fields are automatically captured when the state of a bug is changed from active to resolved:

  • Resolved By: Name of the team member who resolved the bug.

  • Resolved Date: Date and time when the bug was resolved, as recorded by the server clock.

  • State Change Date: Date and time when the state of the bug was changed.

Resolved

Closed

See Also