TFS has several built-in reports readily available for the selected process template. Some of these reports are specific to defects, and some are specific to testing while others are common to work items. These reports collect metrics based on the work items, Test Results, and builds. Each report has filter options to select the iteration, area, time period, work item types, and states. The following sections explain a few of the out-of-the-box reports available in TFS.
This report is used to track progress in the overall bug status, such as new bugs, resolved bugs, and closed bugs. The report shows the cumulative count of bugs based on priority, severity, and state of the bugs. The details for the report can be filtered using start and end dates, iteration and area paths, bug state, priority, and severity.
This report is very useful to get an overview of the status of the testing phase, such as how soon defects are getting fixed and tested, the priority of defects being fixed and closed, the defects count based on severity and priority, and the module which is showing the most defects which can be useful in determining the quality of work.
The report provides a detailed graphical view by plotting the number of active, closed, and resolved defects against a timeline. At a given time the report will show the total count of defects based on the state.
The other pie chart displays active bugs by priority or severity with legends that show the priority/severity values.
Active/Resolved Bugs by Assignment is a horizontal bar chart that displays the total bugs assigned to team members and the total bugs resolved by them.
This report is useful to determine the readiness of the test cases for execution. This report can be generated once the team starts defining the test cases. A test case has three different states, Design, Ready, and Closed. The test case is directly assigned with Design status once a team member starts defining the test. It becomes ready only when the test case is complete, reviewed, and approved by the team. It gets closed only after the testing. The Design and Ready statuses of the test case provides information on how quickly the team is creating test cases and getting them ready for execution.
This report contains an area graph to show the number of test cases in Design and Ready status over a period of time. The main objective of this report is to show how many test cases are ready to be run, how many are still incomplete, when would the test cases be ready, and would that be before the end of the iteration.
This report also provides filters to generate the report based on iteration date range, area, priority, and state.
This report is very useful to track the progress through projects with multiple iterations. This report provides a graphical view of the number of stories closed, progress in hours for each iteration, and number of bugs per iteration. To get accurate reports, the project team should plan the iterations, user stories, area and defect logging in such a way that everything is tracked and on time.
The number of stories denotes user stories that are closed.
The progress in hours shows horizontal bars which show the original estimate, actual hours, and then the hours remaining based on the roll-up of hours defined for tasks. The tasks are created during the project schedule, and include the duration and start and end date planned for completion. This report is generated based on the task allocation and the tasks planned for each iteration.
The bugs with the numeric values and bars denote the number of active, resolved, and closed defects within each iteration for the project.
These reports help us to determine the health of the project at any time. For example, an unhealthy project is one in which the user stories are not closed within the iteration, or if there is a wide difference between the estimated and actual hours, or the number of defects and defect rate are not decreasing after multiple iterations. A healthy project would be the one with better progress on all of the iterations and within the estimated schedule.
These are the reports readily available for determining the project status and quality:
- Bug status report: This report provides the total bug count based on the severity, priority, and state to track progress in resolving and closing bugs.
- Bug trends report: This report is used for tracking the bugs that are discovered and resolved over time. This is very useful in larger teams working towards discovering new bugs, and resolving and closing bugs.
- Reactivations report: It is used to determine how effectively the team is fixing the bugs. Reactivation refers to reopened bugs that were resolved or fixed prematurely.
- Build quality indicators report: It is used to collect the test coverage, code churn, and bug counts for a specific build. This is helpful to find the quality of a build before releasing the code.
- Build success over time report: It summarizes the build and Test Results for a set of build definitions for one or more projects over time. The reports provide day-by-day information for builds failed, builds succeeded with no tests, tests failed, tests passed with low coverage, and builds passed.
- Build summary report: It provides information about Test Results, test coverage, code churn, and other details of each build.
- Burn down and burn rate report: It shows the trend of how much work is completed and how much remains over a period of time. Burn rate specifies the rate at which the work is completed and the required rate for remaining work.
- Remaining work report: It is useful to track the progress of work and identify if the task completion is on track or is there any delay.
- Stories overview report: It lists all user stories and how much work each story requires. Also provides the completed work status, status of tests for the story, and bugs raised against each story.
- Stories progress report: It shows the status and progress of tasks defined to implement the story.
- Unplanned work report: It determines the work that is added at a later point to the iteration after the start of an iteration. These works are called unplanned work to distinguish them from work and tasks planned before the start of the iteration. The work could be a new requirement or test case, or any type of new work item.
- Test case readiness report: It is to identify how many test cases are defined and ready to execute.
- Test Plan progress report: It is used to determine how much of the testing is complete and how much remains to be done. Also provides information on how many tests have passed, failed, and blocked. This report is useful to find out if the testing will be complete on time or not.