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

In this topic	Related topics
Defining a Bug Linking the Bug to Other Work Items Adding Details, Attachments, or Hyperlinks to a Bug Changing the State of a Bug	Process Guidance Working with Bugs Workbooks Triage Workbook (CMMI) Dashboards and Reports Bugs Dashboard (CMMI) Bug Status Report Bug Trends Report Reactivations Report Field Reference Titles, IDs, Description, and History (CMMI) Assignments, Workflow, and Planning (CMMI) Areas and Iterations Fields that Track Bugs, Issues, and Risks (CMMI) Linking Work Items (CMMI) Attachments

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

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

   • In the Assigned To list, click 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 Area and Iteration lists, click 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 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.

   • In the Triage list, click 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, click Yes if an issue is blocking progress toward the resolution of the Bug.

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 Details tab, provide as much detail as another team member needs to understand the problem that must be fixed.

   • In Symptom (required), 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 System Info tab, describe the software environment in which the Bug was found.

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

6. On the Fix tab, describe the proposed change to fix the Bug.

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

7. On the Other tab, specify one or more of the following types of information:

   • In the Found in list, click 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.

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

9. 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 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, click the Test Cases tab, and then click New.

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

   The Add new Linked Work Item dialog box opens.

   

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

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

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

3. In the Work Item Type list, click 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. Click 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. Click 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, click the Test Cases tab, and then click Link to.

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

   The Add Link to Bug dialog box opens.

   

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

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

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

3. Click 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. Click OK, and then click 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, Repro Steps, 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. Click one of the following tabs: Repro Steps, 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 Titles, IDs, Description, and History (CMMI).

3. 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, type additional information about the attachment. To close the Attachment dialog box, 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, 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. Click OK, and then click  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, click 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. Click 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:

Reason	When to use	Additional actions to take
Accepted	When the triage committee approves the bug for implementation in the current iteration.	Assign the bug to the team member who will implement it.
Investigate	When the triage committee determines that the team must investigate the customer impact before deciding whether the team should implement the bug.	Return the bug to the Proposed state when the investigation is finished.

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:

Reason	When to use	Additional actions to take
Rejected	When the triage committee determines that the bug cannot be implemented or the customer no longer needs it.	None.
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.

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:

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 requirement 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 is no longer in the product.	None.

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:

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

Reason	When to use	Additional actions to take
Regression	When the bug reappears in later builds of the code.	None.
Closed in Error	When the bug was closed in error or for some other reason.	None.

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

Artifacts (CMMI)

Other Resources

Work Items and Workflow (CMMI)