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.

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:

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:

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

   • In the Assigned To list, click 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

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

   • In the Reason list, click Build Failure, or leave the assignment as New.

     By default, the value of the Reason field is New. The Resolved Reason field is read-only and captures the value of the Reason field when it is changed from Active to Resolved. For more information about these fields and how you can use them to track workflow, see Resolving and Closing a Bug later in this topic.

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

     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 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, click 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, click 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 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.

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

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

   Note

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

Linking a Test Case to a Bug

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, click 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 click Browse to locate the test case to which you want to link. You can click 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. Click OK.

6. Click Save Work Item.

   Note

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

Adding Details, Attachments, or Hyperlinks 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

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

4. Click  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.

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

   • Click  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 Work Item.

To add a hyperlink to a bug

1. On the All Links tab, click Link to.

   

2. In the Link Type list, click 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. Click OK, and then click  Save Work Item.

Resolving and Closing Bugs

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

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 Resolved later in this topic.

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

3. Click 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

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:

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

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.

From Resolved to Closed

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.

From Resolved to Active

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

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.

Closed

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.

From Closed to Active

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

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.

See Also

Concepts

Triage Workbook

User Story (Agile)

Test Case (Agile)

Other Resources

MSF for Agile Software Development v5.0

Work Items and Workflow (Agile)