Bug (Agile)

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 (Agile).

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.

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. 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:

    • In Title (required), type a phrase that describes the code defect that was found.

    • In the Assigned To list, choose the name of the team member who is responsible for fixing the bug, or leave this field blank to be assigned later during triage.

      Note Note

      You can assign work items only to members of the Contributors group.

    • In the Area and Iteration lists, choose the appropriate area and iteration, or leave these fields blank to be assigned later during a planning or triage meeting.

      Note Note

      The project administrator for each team project defines area and iteration paths for that project so that the team can track progress by those designations. For more information, see Create and Modify Areas and Iterations.

    • In Stack Rank, type a number that indicates the relative importance of the bug compared to the other bugs in the same iteration.

    • In the Priority list, choose the value that indicates the importance of the bug, where 1 is most important and 4 is least important.

      By default, the value of this field is 2.

    • In the Severity list, choose the value that indicates the impact of the bug on the project.

      By default, the value of this field is 3 - Medium.

  2. On the REPRO STEPS tab, 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.

  3. On the SYSTEM INFO tab, specify one or more of the following types of information:

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

      Note Note

      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. On the HISTORY tab, 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.

  5. (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 Bug later in this topic.

  6. On the work item toolbar, choose Save Save Work Item.

    Note Note

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

By linking bugs to test cases, you support the accuracy and completeness of many reports that are defined for MSF for Agile Software Development.

To link an existing test case to a bug

  1. On the Test Cases tab, choose Add Links Link to.

    The Add Link to Bug dialog box opens.

  2. In the Link Type list, leave the default value of Tested By, which is the only type of link that is supported for links that you add from the Test Cases tab.

  3. In Work item IDs, type the ID of one or more test cases to which you want to link the bug, or choose Browse to locate the test case to which you want to link. You can choose the My Test Cases team query to locate test cases and then select the check box next to the test case to which you want to link.

    For more information, see Find Work Items to Link or Import.

  4. (Optional) Type a description for the test case to which you are linking.

  5. Choose OK.

  6. Choose Save Save Work Item.

    Note Note

    Both the bug and test case to which you linked it are updated.

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

  1. Choose the Details tab.

  2. In Steps to Reproduce, type information.

  3. (Optional) In History, type information.

    You can format text to provide emphasis or capture a bulleted list. For more information, see Titles, IDs, Descriptions, and History Field Reference.

  4. Choose Save Save Work Item.

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.

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

    • Choose Add Attachment  Add, and then choose 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, choose OK.

  2. Choose Save Save Work Item.

To add a hyperlink to a bug

  1. On the All Links tab, choose Add Links Link to.

    Specify hyperlink address
  2. In the Link Type list, choose Hyperlink.

  3. In Address, type the address of the target of the link.

    If the target is a Web site, type the URL, or copy it from your Internet browser and paste it into the Address box. If the target is a server location, type the address in the form of a UNC name.

  4. (Optional) In the Comment box, type additional information about the hyperlink.

  5. Choose OK, and then choose Save Save Work Item.

When a bug has been fixed, you change its State from Active to Resolved. When the fix has been verified, you change its state from Resolved to 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 Field Reference.

To resolve or close a bug

  1. Open the work item form for the bug.

  2. In the State list, choose 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 choose a different option.

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

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

  3. Choose Save Save Work Item.

Typical workflow progression:

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

  • A team member changes the state of a bug from Active to Resolved to 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

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.

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 user story 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.

The team member who is assigned to fix the bug resolves it when it is fixed. Or, a team member might determine that the bug should be resolved for other reasons, as the following table describes.

The only supported Reason for closing a bug is Verified.

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

  • Closed By: Name of the team member who closed the bug.

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

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

You can specify one of the reasons in the following table when you reactivate a bug from a resolved state:

Reason

When to use

Additional actions to take

Not fixed

When the resolution is unacceptable or if the fix was incorrect.

Provide details about why you denied the resolution or why the fix did not work correctly. This information should assist the next person who owns the bug in resolving it appropriately.

Test Failed

When a test demonstrates that the bug still exists.

Provide details about which test failed and in which build.

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

  • Activated By: Name of the team member who reactivated the bug.

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

A team member can change a closed bug to active if the problem or code defect that it describes reappears or was not fixed previously.

You can specify one of the reasons in the following table when you reactivate a bug from a closed state:

Reason

When to use

Additional actions to take

Regression

When the bug reappears in later builds of the code.

None.

Reactivated

When the bug was closed in error or for some other reason.

None.

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

  • Activated By: Name of the team member who reactivated the bug.

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

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft