Bug Trends report
TFS 2017 | TFS 2015 | TFS 2013
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 Reporting Services Reports.
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 
Reports does not appear when you open Team Explorer and expand your team project node.
You can use this report to answer the following questions:
- How many bugs are 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?
Prerequisites
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 Grant permissions to view or create reports in TFS.
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's 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.
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 the report counts by specifying iteration and area paths or bug state, priority, or severity.
For more information, see Filtering the Report later in this article.
Required activities for tracking bugs
For the Bug Trends report to be useful and correct, the team must carry out 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 Workbooks.
Set 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 the dates of your current iteration cycle.
To change the duration of the iteration
Next to Iteration Start (Date) or Iteration End (Date), select the calendar icon, and then select a date.
Select View Report.
Interpret the report
You can 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 as they relate to:
- All of the current team project activities
- 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.
- 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 go down. As 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 aren't 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.
Filter the report and change 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.
To filter the bugs that are counted in the report
Carry out 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.
Select View Report.
Related articles
Bugs
Workbooks
Bug Status
Reactivations
Reporting Services Reports