Bug (CMMI)

You can learn how to fill in the details of a Bug work item in this topic. A bug communicates that a potential problem is located in the code that your team is developing. For more information, see Working with Bugs.

For information about how to create this type of 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

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 increase 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 illustrations show:

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

     Note

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

   • In the State list, leave the default value, Proposed.

     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 Changing the State of a Bug later in this topic.

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

   • In the Triage list, choose the triage substate.

     Valid values are Pending (default), More Info, Info Received, and Triaged. This field identifies a level of triage for Bugs that are in the Proposed state.

   • In the Blocked list, choose Yes if an issue is blocking progress toward the resolution of the Bug.

   • In the Area and Iteration lists, choose the appropriate area and iteration.

     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 the Root cause list, choose the cause of the error.

     You can specify one of the following values: Coding Error, Design Error, Specification Error, Communication Error, or Unknown.

2. On the REPRO STEPS tab, provide as much detail as another team member needs to understand the problem that must be fixed.

3. On the SYMPTOM tab, describe the code defect or unexpected behavior that was found..

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

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

   • In Found-in environment, describe the software setup and configuration where the Bug was found.

   • In How found, describe how the Bug was found.

     For example, a Bug might have been found during a customer review or through ad hoc testing.

5. On the FIX tab, describe the proposed change to fix the Bug.

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

6. On the OTHER tab, specify one or more of the following types of information:

   • In the Found in list, choose or type the name of the build in which the potential 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, 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 Original Estimate, type the number of hours that are required to fix the Bug.

7. On the TEST CASES and ALL LINKS tabs, you can create links from the Bug to other work items, such as Tasks, Change Requests, Test Cases, and other Bugs.

   On the ATTACHMENTS tab, you can attach specifications, images, or other files that provide more details about the Bug to be fixed.

   For more information, see the following sections later in this topic:

   • Linking the Bug to Other Work Items

   • Adding Details, Attachments, or Hyperlinks to a Requirement

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

   Note

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

Linking a Bug to Other Work Items

By creating relationships between bugs and other work items, you can track dependencies and find relevant information more quickly. From the work item form for a bug, you can create a work item that is automatically linked to the bug, or you can create links to existing work items.

You use the Test Cases and All Links tabs to create links for specific types of work items and specific types of links. For more information about the restrictions for each tab, see Linking Work Items [CMMI].

To create a task, bug, change request, test case, or other work item and link it to a bug

1. Open the work item form for the bug, and perform one of the following actions:

   • To create and link to a test case, choose the Test Cases tab, and then choose New.

   • To create and link to any other type of work item, choose the All Links tab, and then choose New.

   The Add new Linked Work Item dialog box opens.

   

2. In the Link Type list, leave the default value, or choose one of the following options:

   • To create a link to a test case, choose Tested By.

   • To create a link to any other type of work items, choose Related or another type of link that represents the relationship that you want to track.

3. In the Work Item Type list, choose the type of work item that you want to create.

4. In Title, type a short but specific description.

5. (Optional) In Comment, type additional information.

6. Choose OK.

   A form for the type of work item that you specified opens with the information that you provided.

7. Specify the remaining fields as the following topics describe:

   • Task (CMMI)

   • Change Request (CMMI)

   • Test Case (CMMI)

   • Issue (CMMI)

   • Risk (CMMI)

   • Review (CMMI)

8. Choose Save Work Item.

To link several existing work items to a bug

1. Open the work item form for the bug, and perform one of the following actions:

   • To link to one or more test cases, choose the Test Cases tab, and then choose Link to.

   • To link to one or more work items of other types, choose the All Links tab, and then choose Link to.

   The Add Link to Bug dialog box opens.

   

2. In the Link Type list, leave the default value, or choose one of the following options:

   • To create links to test cases, choose Tested By.

   • To create links to any other type of work item, choose Related or another type of link that represents the relationship that you want to track.

3. Choose Browse.

   The Choose Linked Work Items dialog box appears.

   

4. Type the items in Work item IDs, or browse for the items to which you want to link.

   You can also run a team query to locate the work items to which you want to link. These queries include Active Bugs, Change Requests, Open Tasks, Open Test Cases, and Open Tasks.

5. Select the check box next to each work item that you want to link to the requirement.

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

6. (Optional) Type a description for the work items to which you are linking.

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

   Note

   Both the bug and the work items 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 on the Description, ReproSteps, System Info, Fix, or History tabs.

• 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 one of the following tabs: ReproSteps, Details, System Info, or Fix.

2. Type the information that you want to add.

   In most fields, you can format text to provide emphasis or capture a bulleted list. For more information, see Requirement Field Reference (CMMI).

3. Choose  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 or press CTRL-V to paste a file that you have copied.

   • Choose  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, type additional information about the attachment. To close the Attachment dialog box, choose OK.

2. Choose  Save Work Item.

To add a hyperlink to a bug

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

   

2. In the Link Type list, choose Hyperlink.

3. In Address, perform one of the following tasks.

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

Resolving and Closing Bugs

A team can track the progress of a bug by setting its State to one of the following values:

• Proposed

• Active

• Resolved

• Closed

When a team member creates a bug, it is in the Proposed state by default. When the team accepts a bug for the current iteration, the team changes the state of the bug to Active and may create tasks to implement it. When a team member fixes the bug, he changes its state from Active to Resolved. When the fix has been verified, a team member changes 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 or closed for other reasons, as described later in this topic.

For more information about the data fields that you can use to track work item states, see Assignments, Workflow, and Planning (CMMI).

To change the state of a bug

1. Open the work item form for the bug.

2. In the State list, choose Active, Resolved or Closed.

   • If you change the state from Proposed to Active, the Reason field changes to Accepted.

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

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

3. Choose Save Work Item.

Typical workflow progression: A team member creates a bug in the default state, Proposed, with the default reason, New. A team member changes the state from Proposed to Active with the default reason, Accepted. A team member changes the state from Active to Resolved when he fixes the bug or determines that it cannot be fixed. A team member changes the state from Resolved to Closed when he verifies that the bug is fixed or determines that it cannot be fixed. Atypical transitions: A team member changes the state from Proposed to Closed with the default reason, Rejected. A team member changes the state from Active to Proposed with the default reason, Investigation Complete. A verification test for the bug fails. Therefore, a team member changes the state from Resolved to Active with the default reason, Not fixed. During regression testing, a team member finds that a closed bug is recurring and changes the state from Closed to Active.

Bug State Diagram

Proposed (New)

The following data fields are automatically captured when a team member creates a bug:

• Created By: Name of the team member who created the bug.

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

From Proposed to Active

A team member can resolve an active bug for the reasons that the following table describes:

The following data fields are captured when a team member changes the state of a bug to Active:

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

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

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

From Proposed to Closed

A team member can close a bug that is in the Proposed state because of the reasons that the following table describes:

The following data fields are captured when a team member closes a bug:

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

Active

The team should fix only those bugs that are in the Active state. the bug remains in the active state as the team is investigating and fixing it.

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 a team member changes the state of a bug 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.

From Resolved to Closed

The only supported reason for closing a bug is Verified.

The following data fields are automatically captured when a team member changes the state of a bug 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.

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 or closed for other reasons, as the following table describes.

From Resolved to Active

A team member can reactivate a bug from a resolved state for one of the reasons that the following table describes:

The following data is automatically captured when a team member reactivates a bug from a resolved state:

• 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 the state of 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 a team member reactivates a bug from a closed state:

• 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

Work Item Field Reference for Visual Studio ALM

Artifacts (CMMI)

Other Resources

Work Items and Workflow (CMMI)