Bug Trends Report

项目
07/29/2015

You can use the Bug Trends report to help track the rate at which your team is discovering and resolving bugs. This report shows a rolling or moving average of bugs being reported, resolved, and closed over time. When you manage a large team or a large number of bugs, you can monitor the Bug Trends report weekly to gain insight into how well the team is finding, resolving, and closing bugs.

For information about how to access, refresh, or manage reports, see Reports (SQL Server Reporting Services).

Note

This report requires that the team project collection that contains your team project was provisioned with SQL Server Reporting Services. This report is not available if Report Reports does not appear when you open Team Explorer and expand your team project node.

In this topic

Data in the Report
Setting the Duration of the Iteration
Interpreting the Report
Filtering the Report

You can use this report to answer the following questions:

How many bugs is the team reporting, resolving, and closing per day?
What is the overall trend at which the team is processing bugs?
Are bug activation and resolution rates declining toward the end of the iteration as expected?

Required Permissions

To view the report, you must be assigned or belong to a group that has been assigned the Browser role in SQL Server Reporting Services. For more information, see Add users to team projects or Managing Permissions.

Data in the Report

The Bug Trends report calculates a rolling average of the number of bugs that the team has opened, resolved, and closed based on the filters that you specify. The rolling average is based on the seven days before the date for which it is calculated. That is, the report averages the number of bugs in each state for each of the seven days before the date, and then the result is divided by seven. The data is derived from the data warehouse.

The following illustration displays an example of the Bug Trends report.

Example of Bug Trends report

This report displays up to three line graphs, and each graph represents the rolling averages of the numbers of activated, resolved, and closed bugs.

You can filter the report in the following ways:

Change the start and end dates for the report.
Filter the bugs that are counted in the report by specifying iteration and area paths or bug state, priority, or severity.

For more information, see Filtering the Report later in this topic.

Required Activities for Tracking Bugs

For the Bug Trends report to be useful and accurate, the team must perform the following activities:

Define bugs, and specify their Iteration and Area paths.
Update the State of each bug as it is fixed, verified, and then closed.
Specify the Priority and Severity of each bug during triage.

You can use the Triage workbook to quickly update the iteration, area, state, priority, and severity of bugs. For more information, see Triage workbook.

Setting the Duration of the Sprint or Iteration

To understand the bug trends for your current iteration, the start and end dates for the report must match those of your current iteration cycle.

To change the duration of the iteration

Next to Iteration Start (Date) or Iteration End (Date), click the calendar icon, and then click a date.
Click View Report.

Interpreting the Report

You should expect bug rates to vary based on where you are in your product development cycle. The team should find fewer bugs in early iterations than in later iterations. The team should close the most bugs in iterations that are near the end of a product cycle.

You interpret bug rates best by reviewing them relative to all of the current team project activities and the other metrics that the Bug Status and Reactivations reports provide. For example, the team might find bugs especially quickly in poorly written code, in newly integrated code, with improved testing, or during an exceptional event such as a bug bash. On the other hand, bugs are more difficult to find in a high quality product and with ineffective testing. You can use the metrics for code coverage, code churn, and test rates to help further assess the meaning of the bug trends.

As the product stabilizes toward the end of a product cycle, the team should find bugs less frequently.

The Bug Trends report might show one or more of the indicators that the following table describes in the left-hand column. You can review the questions in the right-hand column for areas to address in more detail.

Indicator	Questions to ask
The team is finding about the same number of bugs in successive time periods. If the team finds the same number of bugs week after week or iteration after iteration, you might investigate the underlying cause. Early in the testing cycle, the tests might not be rigorous or advanced enough to find many bugs. In early iterations, this situation is expected. However, as the product matures, tests should exercise broader scenarios and integrations.	Are the test cases adequate to test the user stories that are being developed? Have the tests become stale or are they testing the wrong functionality? Is the test team rigorously testing each user story?
The team is finding many bugs in each time period. The team might find bugs easily in sloppy code, in newly integrated code, with effective testing, or during a specific event, such as a bug bash.	Do the metrics for code coverage, code churn, or test progress indicate a problem with the code or testing?
The team is finding few bugs in each time period. The team might struggle to find bugs in a high-quality solution or with ineffective testing.	Do the metrics for code coverage, code churn, or test progress indicate a problem with the code or testing?
The team is resolving many bugs in each time period. A high resolve rate usually indicates that the team is making good progress.	Are resolved bugs getting promptly closed? The closed rate should resemble the resolved rate. Are bug reactivations remaining within expected boundaries?
The team is resolving bugs quickly but not closing them. Team members who are assigned to verify bug fixes might be spread too thin, or different priorities might keep those team members from closing resolved bugs.	Are test resources overallocated? Should the team revisit test priorities?

Healthy Version of Report

A healthy Bug Trends report shows that the team finds more bugs at the start of a development cycle and fewer bugs toward the end of a release. The team should resolve and close more bugs toward the end of the project.

When the team resolves bugs faster than it finds them, the number of active bugs will start to decrease. When the team starts to find fewer bugs, the product is stabilizing.

Unhealthy Version of Report

An unhealthy Bug Trends report might show that the team is finding bugs more quickly as the ship date approaches and resolving bugs more slowly. In this situation, the team's bug backlog is growing because bugs are not getting fixed, and you might want to investigate the causes. The following illustration shows a report for a team that is finding many bugs, resolving fewer bugs than it finds, and closing fewer bugs than it resolves.

Unhealthy version of Bug Trends Report

Filtering the Report and Changing the Display

You can filter the Bug Trends report or change its display in the following ways:

Change the start and end dates for the report.
Filter the bugs that are counted in the report by specifying iteration and area paths, state, priority, or severity.

The following illustration shows the available filters.

Filters for Bug Trends report

To filter the bugs that are counted in the report

Perform one or both of the following actions:
- In the Iteration and Area lists, select the check box of each iteration or product area to include.
- In the State, Priority, or Severity lists, select the check box of each state, priority, and severity to include.
Click View Report.

通过