Teams WIT Tools : Reporting

Team Foundation Server 2010 - Relational Warehouse and Cube Schema Changes

sunder — Sun, 17 May 2009 02:15:47 GMT

Team Foundation Server 2010 is a BIG release for us by all counts. We have made conceptual changes; Brian introduced some of the key concepts in TFS 2010 that includes the concept of Team Project Collections (TPCs). These changes required a lot of infrastructure support that we built from the ground up and changes to all the subsystems including the warehouse adapters, relational warehouse schema and the Analysis Services cube schema.

As our Beta 1 release approaches, I wanted to outline the changes to the relational warehouse and cube schema. These are, unfortunately, breaking changes. While we will provide an updated set of out-of-the-box reports (details below), these schema changes will affect your custom reports. By custom reports, I mean SQL Server Reporting Services (SSRS) or Excel pivot table/chart reports you may have authored against the warehouse or cube.

Read the rest of the post: http://blogs.msdn.com/sunder/archive/2009/05/16/team-foundation-server-2010-relational-warehouse-and-cube-schema-changes.aspx

Sunder Raman

Program Manager, Team Foundation Server

Previous State and State Change Count

nericson — Wed, 29 Apr 2009 22:06:00 GMT

Today I am going to look at two interesting fields in the Warehouse related to Work Items – Previous State, and State Change Count.

The Previous State field stores the state a Work Item was in before it entered its current state. This field is in the [Work Item] table in the relational/dimensional Warehouse and in the [Work Item] Dimension in the Cube.

The State Change Count measure counts the number of changes in State between a Work Item revision and its previous Revision (actually instead of 0 it will have a value of NULL – so it will either have a value of 1 or NULL). It is in the [Work Item History] table in the relational/dimensional Warehouse and in the [Work Item History] measure group in the Cube.

The easiest way to understand their values is with an example. In this example we are going to create a new Work Item and then edit it several times. The table shows the values in the Warehouse (of course all of these are not in the same table in the Warehouse – but showing it like this makes the example simpler).

1. Create a new Work Item.

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1

The Previous State is NULL because prior to Revision 1 the Work Item had no state. The State Change Count is 1 because the Revision changed from state NULL to state Active.

2. Modify a field other than state (i.e. Title)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2

The State the Work Item was in, before it was in its current state, is still NULL. The state of Revision 2 didn’t change from Revision 1 so the State Change Count is NULL.

3. Modify the state (i.e. Resolve the Work Item)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2
1	3	Resolved	Active	1	1/3

Now the State the Work Item was in before it was in its current state is Active. The state changed so the State Change Count is 1.

4. Modify a field other than state (i.e. Title)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2
1	3	Resolved	Active	1	1/3
1	4	Resolved	Active	NULL	1/4

5. Modify the state (i.e. Reactivate the bug)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2
1	3	Resolved	Active	1	1/3
1	4	Resolved	Active	NULL	1/4
1	5	Active	Resolved	1	1/5

Alright I think it is clear what the values will be for these fields… now what good are they?

The Previous State serves as a cache of state the work item before it entered the current state. Without this one would have to walk back work item revisions until you found one that had a different state. The Previous State can be used to answer questions like:

For my Work Items that are currently Active, how many of them have been reactivated (Previous State = Resolved)? A large number of reactivated Work Items may indicate developers are not doing enough unit testing.

The State Change Count gives us a way to quickly identify revisions where the state changed. Using this along with the Previous State you can identify things like resolved rates per day or incoming rates per day. For example if you looked for Work Item revisions with State = Resolved, Previous State = Active, and State Change Count = 1 you would get those revisions that were resolved – and the dates. Note that if a work item was reactivated then resolved again you would get it back two times – this may or may not be what you want for your report.

[Cross Posted from blogs.msdn.com/nericson]

TFS Warehouse Work Item Tracking Compensating Records

nericson — Sat, 21 Mar 2009 01:56:00 GMT

Compensating Records

What are compensating records?

First a little background. Whenever a work item is updated a new revision is created. These revisions are moved over to the Warehouse and stored in the various Work Item Dimension and Fact tables. Each revision will be in the Warehouse – however each date will not have a revision. Something like (ignoring actual schema for now):

ID	Revision	Date	Remaining Work
1	1	4/10/2009	50
1	2	4/15/2009	40
1	3	4/20/2009	30
1	4	4/25/2009	20

Now if you wanted to ask a question about work items on a specific date then one way you can answer your question is to get the latest revision of the work item created before that date.

For example say you want to know the Remaining Work for a Work item on 4/22/2009. You could get all the work items whose Date is <= 4/22/2009 (Revisions 1, 2, and 3); then from these find the one with the largest Revision (Revision 3). This gives you a Remaining Work of 30.

However this requires you to do a MAX in your query and doesn’t work particularly well in the Cube. So we have added compensating records. These records are primarily used for running sum computations. Each one effectively negates, or compensates, the previous revision of that work item.

For example, using the same data from above:

1. 4/10/2009 – Work Item 1 is added.

ID	Revision	Date	Remaining Work	Record Count	Is Compensating
1	1	4/10/2009	50	1	No

2. 4/15/2009 – Work Item 1 is revised.

ID	Revision	Date	Remaining Work	Record Count	Is Compensating
1	1	4/10/2009	50	1	No
1	1	4/15/2009	-50	-1	Yes
1	2	4/15/2009	40	1	No

3. 4/20/2009 and 4/25/2009 – Work Item 1 is revised.

ID	Revision	Date	Remaining Work	Record Count	Is Compensating
1	1	4/10/2009	50	1	No
1	1	4/15/2009	-50	-1	Yes
1	2	4/15/2009	40	1	No
1	2	4/20/2009	-40	-1	Yes
1	3	4/20/2009	30	1	No
1	3	4/25/2009	-30	-1	Yes
1	4	4/25/2009	20	1	No

Now you can answer the same question as above by getting all the revisions of work items older than 4/22/2009 (Revisions 1, 1’, 2, 2’, and 3) and summing their Remaining Work. This gives you a Remaining Work of (50 + -50 + 40 + -40 + 30) = 30. This should be faster than without the compensating records (and it makes the Cube happy!).

What about that Record Count column?

You can apply the same running sum logic to the Record Count to get the number of work items as of a date. So you could ask how many work items were there on 4/22/2009. Again we sum up the values for all rows with a Date <= 4/22/2009 and we get (1 + -1 + 1 + -1 + 1) = 1. Not terribly exciting with our data, but you can see how if we had more work items this could be useful.

Again – with TFS

Alright so let’s look at some example using the TFS 2008 schema. Say I want to get the number of Active and Resolved Work Items assigned to me as of a given date. First thing I need to know is what tables I should look at:

Info needed in query	Warehouse Table
Active and Resolved Work Items	[Work Item] filtered on [System_State]
Assigned to me	[Work Item History] or [Current Work Item] joined to [Person] on [Work Item History].[Person] = [Person].[__ID] or [Current Work Item].[Person] = [Person].[__ID]
Work Items as of a date	[Work Item History] filtered on [Date]

Putting this together I see I need [Work Item History], [Work Item], and [Person]. So let’s build the query:

SELECT wi.[System_State]

,SUM([Record Count]) AS [Count]

FROM [Work Item History] AS wih

LEFT JOIN [Work Item] AS wi

ON wi.[__ID] = wih.[Work Item]

LEFT JOIN [Person] AS p

ON p.[__ID] = wih.[Assigned To]

WHERE [Date] < CONVERT(DATETIME, '2009-03-19', 126) AND

p.[Person] = N'Nick Ericson' AND

wi.[System_State] IN ('Active', 'Resolved')

GROUP BY wi.[System_State]

System_State	Count
Resolved	2
Active	6

I can change the query slightly to get a better query plan (please send any further optimizations along – I’ll add them):

SELECT wi.[System_State]

,SUM([Record Count]) AS [Count]

FROM [Work Item History] AS wih

LEFT JOIN [Work Item] AS wi

ON wi.[__ID] = wih.[Work Item]

WHERE wih.[Assigned To] = (SELECT TOP 1 [__ID] FROM [Person] WHERE [Person] = N'Nick Ericson') AND

wih.[Date] < CONVERT(DATETIME, '2009-03-19', 126) AND

wi.[System_State] IN ('Active', 'Resolved')

GROUP BY wi.[System_State]

One thing I should note that can be confusing is that I am passing in 2009-03-19 00:00:00.000 for the Date. Most people would consider this not to be 19^th, but instead the 18^th (or so barely the 19^th that we shouldn’t use it for determining how many bugs were Active on the 19^th). However in the Warehouse we truncate the times off of the Date field. So if a work item was marked active at 6 PM on the 19^th the Date field in the Warehouse will have 2009-03-19 00:00:00.000. This is a long way of saying that 2009-03-19 is the 19^th, not the 18^th.

Alright getting the counts for someone on a given day was fairly straight forward. You may want to add in some logic to return Active and Resolved counts of 0 when the query returns NULLs – but this depends on how you will build your report.

Trending

How about a trend report? You basically need to execute the queries from the section above over a range of dates. We can use a Cross Apply here (again send along your optimized queries):

SELECT d.[Date] AS [Date], ca.*

FROM [Date] AS d

CROSS APPLY

(

SELECT wi.[System_State]

,SUM([Record Count]) AS [Count]

FROM [Work Item History] AS wih

LEFT JOIN [Work Item] AS wi

ON wi.[__ID] = wih.[Work Item]

WHERE wih.[Assigned To] = (SELECT TOP 1 [__ID] FROM [Person] WHERE [Person] = N'Nick Ericson') AND

wih.[Date] < d.[__ID] AND

wi.[System_State] IN ('Active', 'Resolved')

GROUP BY wi.[System_State]

) AS ca

WHERE d.[__ID] BETWEEN CONVERT(DATETIME, '2009-03-19', 126) AND CONVERT(DATETIME, '2009-03-21', 126)

Date	System_State	Count
3/19/2009	Active	6
3/19/2009	Resolved	2
3/20/2009	Active	7
3/20/2009	Resolved	2
3/21/2009	Active	7
3/21/2009	Resolved	2

[Cross Posted from blogs.msdn.com/nericson]

How Microsoft/DevDiv uses TFS - Chapter 6 (Addendum)

Gregg Boer — Wed, 14 May 2008 14:45:00 GMT

In my previous post, some people asked how we went about creating the report I talked about.

I asked the fellow who created this report internally. Here was his response, which I'm passing on to you. (Thanks Doug!)
NOTE: I've also attached the .RDL file he forwarded along.

being quote>

Here is the query which gets current values along with the value of completed & remaining work from some prior date (and the prior date is parameterized). The reason for the .[All] on the custom measures which get the work from N days ago is to deal with the scenarios where title or product unit or state etc had a different value on the prior date. In effect we are saying: give me the value of completed & remaining work from N days ago without regard to whether the value of those other fields match the filter we are applying to the current values (e.g. current state etc).

WITH

MEMBER [Measures].[ValueOfCompletedWorkAsOfNDaysAgo] AS

(

   [Measures].[Microsoft_VSTS_Scheduling_CompletedWork],

   [Work Item].[Microsoft_DeveloperDivision_Classifications_Group].[All],

   [Work Item].[Microsoft_DeveloperDivision_Classifications_Project].[All],

   [Work Item].[System_Title].[All],

   [Work Item].[System_State].[All],

   [Work Item].[Microsoft_DeveloperDivision_Features_RiskLevel].[All],

STRTOMEMBER(@MDXDateForWorkCompletedSinceDate)

)

MEMBER [Measures].[ValueOfRemainingWorkAsOfNDaysAgo] AS

(

   [Measures].[Microsoft_VSTS_Scheduling_RemainingWork],

   [Work Item].[Microsoft_DeveloperDivision_Classifications_Group].[All],

   [Work Item].[Microsoft_DeveloperDivision_Classifications_Project].[All],

   [Work Item].[System_Title].[All],

   [Work Item].[System_State].[All],

   [Work Item].[Microsoft_DeveloperDivision_Features_RiskLevel].[All],

STRTOMEMBER(@MDXDateForWorkCompletedSinceDate)

)

MEMBER [Measures].[FeatureEndDate] AS

EXTRACT(

NonEmpty(

        [Microsoft_DeveloperDivision_Features_DateEnd].[Date].[Date] *

        [Work Item].[System_Id].CurrentMember,

        [Measures].[Current Work Item Count]

    ),

    [Microsoft_DeveloperDivision_Features_DateEnd].[Date]

).Item(0).Member_Value

SELECT

Non Empty

{

   [Measures].[FeatureEndDate],

   [Measures].[Current Work Item Microsoft_VSTS_Scheduling_CompletedWork],

   [Measures].[Current Work Item Microsoft_VSTS_Scheduling_RemainingWork],

   [Measures].[ValueOfCompletedWorkAsOfNDaysAgo],

   [Measures].[ValueOfRemainingWorkAsOfNDaysAgo]

} ON COLUMNS,

NonEmpty(

STRTOSET(@WorkItemMicrosoftDeveloperDivisionClassificationsGroup, CONSTRAINED) *

STRTOSET(@WorkItemMicrosoftDeveloperDivisionClassificationsProject, CONSTRAINED) *

    [Work Item].[System_Id].[System_Id] *

    [Work Item].[Microsoft_DeveloperDivision_Features_RiskLevel].[Microsoft_DeveloperDivision_Features_RiskLevel] *

    [Work Item].[System_Title].[System_Title],

    [Measures].[Current Work Item Count]

) DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS

FROM [Current Work Item]

WHERE

(

   [Work Item].[System_WorkItemType].&[Orcas Feature],

STRTOSET(@WorkItemSystemState, CONSTRAINED)

)

<end quote

Demo - tutorial: Building a TFS report using Report Designer

Ameya — Sat, 23 Feb 2008 07:38:38 GMT

I gave a talk to an internal team sometime last year on building TFS reports. The talk was recorded and I rediscovered that video a few days ago.

I did a couple of report-building demos during the talk. Here's one of them:

Ameya Bhatawdekar

Program Manager, Team Foundation Server

As of Today TFS Cube Report in Excel

nericson — Tue, 12 Feb 2008 03:50:27 GMT

This walk through shows you how to get started using Excel to build a TFS report displaying Cube data relative to today.

When you build a report using an Excel Pivot Table often you want to filter that data by a date relative to today. For example you would like to see the number of Active Work Items as of today or the number of Work Items resolved this week. However in an Excel Pivot Table you cannot filter on a dynamic value, so every time today changes (i.e. tomorrow) you need up manually update the filter.

One way to get around this is to using the Cube Functions in Excel 2007. A couple caveats are that this makes the report harder to author and the rows/columns displayed in the report is statically defined. Often this is fine.

Example

I would like a report showing the number of Active Work Items assigned to and the number resolved by some set of people this week.

There are really two different bits of information we want (the Active Work Item Count and the Resolved Count) for each person. I will go through getting each bit of information separately.

(1) Active Work Item Count

To get the Active Work Item count as of today for a person we can use the Current Work Item Count Measure and filter/slice by the Work Item State and Assigned To. Translating this slightly:

We want the Cube Value of the Current Work Item Measure sliced by the Work Item State = Active and Assigned To Alias* = <someone>.

Current Work Item Measure = [Measures].[Current Work Item Count]

Work Item State Active = [Work Item].[System_State].&[Active]

Assigned To Alias = [Assigned To].[Alias].&[<someone>]

So for Nick Ericson (alias = nericson) we want:

=CUBEVALUE(<Name of Cube Connection>,"[Measures].[Current Work Item Count]","[Assigned To].[Alias].&[nericson]","[Work Item].[System_State].&[Active]")

Of course the member expressions (i.e. "[Assigned To].[Alias].&[nericson]") can be replaced with cell references making the report easier to manage. For example to replace "[Assigned To].[Alias].&[nericson]" with a cell reference:

1) In cell B15 (or wherever) put:

=CUBEMEMBER(<Name of Cube Connection>,"[Assigned To].[Alias].&[nericson]")

2) Then replace "[Assigned To].[Alias].&[nericson]" in the CUBEVALUE function with B15 (or reference it another way, such as $B$15, depending on your preference).

* Why did I use the Assigned To Alias?

We can specify an Assigned To person using either their identifier (i.e. [Assigned To].[Person].&[25]) or their Alias (i.e. [Assigned To].[Alias].&[nericson]). A person’s identifier in the cube is not necessarily static - it can change if the Reporting Relational Warehouse is rebuilt. We can work around this by either querying the Relational Warehouse to get the ID or updating the report if the Warehouse is rebuild, but it is easier here to use their alias. Hopefully that doesn’t change very often.

(2) Resolved Count this week

First off we need to understand what it means for a work item to be Resolved this week. I only want to count work items that are Resolved and stay resolved. So I will not count those that become reactivated. Those that are reactivated and assigned back to me will reappear in the Active Work Item Count above.

To find the Resolved Count this week for a person we can use the Current Work Item Count measure again and filter/slice by Work Item Resolved By and the Resolved Date. Translating slightly:

We want the Cube Value of the Current Work Item Measure sliced by the Work Item Resolved By = <someone> and Resolved Date (week) = <this week>.

Current Work Item Measure = [Measures].[Current Work Item Count]

Work Item Resolve By = [Work Item].[Microsoft_VSTS_Common_ResolvedBy].&[<someone>]

Resolved Date (week) = [Microsoft_VSTS_Common_ResolvedDate].[Year Week Date].[Week].&[<this week>]

<this week> can be found in Excel using:

=TODAY()-WEEKDAY(TODAY(), 2).

We need to convert it into the correct format which can be done using (where B9 = cell with formula above):

=IF(LEN(YEAR(B9))=1,"0"&YEAR(B9),YEAR(B9))&"-"&IF(LEN(MONTH(B9))=1,"0"&MONTH(B9),MONTH(B9))&"-"&DAY(B9)&"T00:00:00"

So for Nick Ericson we want (where B10 = cell above):

=CUBEVALUE(<Name of Cube Connection>,"[Measures].[Current Work Item Count]","[Work Item].[Microsoft_VSTS_Common_ResolvedBy].&[Nick Ericson]", "[Microsoft_VSTS_Common_ResolvedDate].[Year Week Date].[Week].&["&B10&"]")

Repeat this for the other people and you have the data needed to produce the report above.

FAQ #6: How do I change the frequency that the reporting warehouse updates?

sbhatia — Thu, 07 Feb 2008 03:34:26 GMT

This tip comes from Markus Hain:

The default update frequency is 3600 seconds (1 hour), below are the steps to change the time.

1. Log on to the application tier of Team Foundation Server.

2. Start Internet Explorer.

3. In the Internet Explorer Address box, type http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx.

4. On the ControllerService page, click ChangeSetting.

5. In the settingID box, type RunIntervalSeconds.

6. In the newValue box, type the new number of seconds, and then click Invoke.

This opens a confirmation web page which indicates that the RunIntervalSeconds setting was changed.

Radius 90 v2 from 90 degree software has Analysis Services Support!

sbhatia — Sun, 03 Feb 2008 06:37:00 GMT

Last month, 90 degree software released their Radius 90 v2. The Radius tools are all about making report design and analysis simple.

Radius 90 has an easy-to-use Fluent UI style made popular by Office.

One of the key additions was the support of Analysis Services -- which means that we can now point it at the TFS OLAP cube and use it to create reports.

A key feature of Radius is that when you load up an existing report, it can shred that report into the queries and parameters that are part of it. The user can then share and re-use those in other reports.

They are offering a 15-day trial version. Check it out and share your feedback!

-Siddharth

New content on creating custom reports

Ameya — Wed, 05 Sep 2007 18:19:00 GMT

There is new content on MSDN on building custom reports. Allen Clark has more details about it on his blog post: http://blogs.msdn.com/vstsue/archive/2007/08/29/new-content-available-on-creating-custom-reports.aspx

Understanding the TFS Cube

Jimmy Li — Tue, 01 May 2007 01:25:00 GMT

The initial learning curve for the TFS Cube is pretty steep. It is quite overwhelming to figure out the relationships between the large number of dimensions and measure groups in the TFS cube at first. In this blog entry I will explain some of the most commonly used perspectives and show how you can easily create Excel reports from them.

*Note* that this blog entry is still relevant to you even if you don't have perspectives on your cube. What I cover here will help you better understand the cube schema. In the demos below I connect Excel to cube perspectives. However you can create the exact same reports by connecting to the Team System Cube.

A perspective defines a viewable subset of a cube that provides focused, business-specific or application-specific viewpoints on the cube. It is a feature only available in the Enterprise Edition of SQL Server. Here are the out of box perspectives, we will explore the first 4 perspectives in this post:

Current Work Item
Work Item History
Code Churn
Test Result
Build
Code Coverage
Load Test

The [Current Work Item] Perspective

Here are the cube dimensions related to the [Current Work Item] measure group:

Use the [Current Work Item] perspective if you would like to analyze the latest Work Item data. For example, you may answer questions such as these:

What is the active bug count by Area?
What is the remaining work by person?
What is the list of active tasks, and how much work is left in each?
Is there any active bugs assigned to my team that have not been modified in the past week?

In short, if you need to analyze the "as of now" work item data in the cube, [Current Work Item] perspective is the right perspective. Beware that the [Work Item History] perspective can answer many of the same questions, but it is much more expensive (slower).

Video: Demo 1 - Active Bug Count by Area

Also use the [Current Work Item] perspective if you would like to analyze Related Work Items. For example, You can answer questions such as these:

List all Tasks with Active related bugs
What tasks are blocked by active bugs assigned to my team?

There is a corresponding 'Related' dimension for every dimension that slices the [Current Work Item] measure group, e.g. [Area] and [Related Area], [Work Item] and [Related Work Item], etc. This allows you to filter and to show attributes for work items and their related work items. Note that the cube is designed for single hop relationships, i.e. work items and their related work items. For multi-hop relationships, e.g. work items and the related work items relating to their related work items, use SQL queries against the Relational Warehouse

Video: Demo 2- All Tasks with Active Related Bugs

The [Work Item History] Perspective

Here are the cube dimensions related to the [Work Item History] measure group:

Use the [Work Item History] perspective to analyze historical work item data.

Use the [Cumulative…] measures and the [Date] dimension to analyze point in time status or to show historical trend. For example, you can answer questions such as these:

Bug count as of a certain point in time
Bug trend over a period of time
Trend of Completed Work per person over a period of time
The average time it takes to close an issue

Note that the [Cumulative…] measures are expensive during query time, shorten the date range if your report takes too long to render.

Although you can use the [Work Item History] perspectives to answer some of the questions concerning the latest work item data, use the [Current Work Item] perspective for greater performance.

Video: Demo 3 - Trend of Completed Work per Person over Time

Use the [State Change Count] measure for rate of change in work item state. For example, you can answer questions such as these:

Incoming bug rate over a period of time
Activation, Resolve and Close rate for over a period of time

Note that [State Change Count] returns the number of state transition events, but not the number of work items in state transition. For example, if we have a bug that was active yesterday, and it was resolved, reactivated and re-resolved today. [State Change Count] will return the resolved rate of 2, even though only 1 bug got resolved.

Video: Demo 4 - Incoming Bug Rate over Time

Video: Demo 5 - Activation, Resolve and Close Rate for Work Items over Time

The [Code Churn] Perspective

Here are the cube dimensions related to the [Code Churn] measure group:

Use the [Code Churn] perspective to analyze historical code churn activities on Version Control. For example, you can answer questions such as these:

How much code churn do we have over a period of time?
How much code churn do we have over a series of build?
How much code churn do we have over a series of changeset?
Who introduced the most churn?
What changesets go into each build?
How much code churn was introduced as the result of resolving a certain work item?

The [Total Churn] measure is defined as [Lines Added] + [Lines Deleted] + [Lines Modified], and it is the measure you should use to answer questions concerning lines of code churned.

Note that the [Total Lines] measure is expensive during query time. Shorten the changeset, build or date range if your report takes too long to render.

Video: Demo 6 - Trend of Code Churn over Build per Person

Video: Demo 7 - Code Churn by Person per Changeset

The [Test Result] Perspective

Here are the cube dimensions related to the [Test Result] measure group:

Use the [Test Result] perspective to analyze published test results.

In Team Test, each test can be run and published against a build multiple times. Each build can contain multiple published runs and each run contains at most 1 published result from each test. Let me illustrate the behavior of the different measures using a simple example:

Suppose there are 3 tests in the system and they were run and published to 2 builds in the following manner:

Build 1

Run 1-1

Test 1 - Failed

Run 1-2

Test 1 - Passed
Test 2 - Passed

Build 2

Run 2-1

Test 2 - Passed
Test 3 - Failed

Run 2-2

Test 3 - Passed

Here's how each measure would behave:

[Result Count] – counts all published results individually

Returns 1 for Run 1-1
Returns 2 for Run 1-2
Returns 3 for Build 1

[Result Transition Count] – counts the number of times the outcome of tests change between runs within the same build

Returns 1 for Run 1-1 because Test 1's changed no result to Failed
Returns 2 for Run 1-2 because Test 1 changed from Failed to Passed and Test 2 changed from no result to Passed
Returns 2 for Run 2-1 because both Test 2 and Test 3 changed from no result to having a result. Note that results are not carried forward from build to build

[Cumulative Result Count] – counts the latest result of each test in a build

Returns 2 for Build 1, the latest results come from Run 1-2
Returns 2 for Build 2, Test 2's latest result comes from Run 2-1 and Test 3's comes from Run 2-2

[Latest Result] – returns the string version of the latest result for a test

Returns "Passed" for both Test 1 and Test 2 for Build 1
Returns "Passed" for Test 2 and Test 3 for Build 2

Use the following measures to analyze results across Builds:

[Cumulative Result Count] - Ex: How many tests have passed and failed against each build?
[Latest Result] - Ex: What was the latest result for each test over a series of builds?

Video: Demo 8 - Number of Tests Passed and Failed over Build

Video: Demo 9 - Latest Test Result per Test per Build

Use the following measures to analyze results across Runs:

[Result Count] - Ex: How many tests passed and failed against each run?
[Result Transition Count] - Ex: Was there any improvement in pass rate over the previous run? i.e. how many failed tests from the previous run are now passing?

We will skip the details for the following perspectives. Here are their measure group and dimension relationships for your reference:

The [Build] Perspective

The [Code Coverage] Perspective

TFS Report developer resources

Ameya — Tue, 27 Mar 2007 03:57:00 GMT

Mauli, a core reporting team member, has compiled a great reference list of articles, reference documentation, tutorials and blogs for report developers.

From: Mauli Shah

Hi all,

There have been a lot of questions about references for making reports. I’ve been keeping a running list of references that I’ll share with you here. I encourage you all to reply with references that you have found helpful, and material that you’d like to see.

Mauli

Videos/Samples:

Video for creating custom reports: http://teamsystemrocks.com/files/10/team_foundation_server/entry164.aspx

MSDN article on creating SSRS reports: http://msdn.microsoft.com/msdnmag/issues/06/06/DataPoints/default.aspx

Webcasts about SSRS: http://www.microsoft.com/events/series/sqlserverbi.mspx#SQLServerReportingServices

SSRS tutorials: http://msdn2.microsoft.com/en-us/library/ms170246.aspx

SSRS report samples for TFS: http://blogs.msdn.com/tompatton/archive/2006/05/07/591713.aspx

Documentation:

TFS Warehouse documentation: http://msdn2.microsoft.com/en-us/library/ms244696(VS.80).aspx

TFS General documentation: http://msdn2.microsoft.com/en-us/library/ms181232(vs.80).aspx

How to write a warehouse adapter: http://msdn2.microsoft.com/en-us/library/bb130342(VS.80).aspx

How to make a work item field reportable: http://msdn2.microsoft.com/en-us/library/ms194942(VS.80).aspx

SSRS Report Design: Best Practices and Guidelines: http://www.microsoft.com/technet/prodtechnol/sql/2005/rsdesign.mspx

Article for MDX newbies: http://www.mosha.com/msolap/articles/MDXForEveryone.htm

Tutorials for AS, RS, MDX: http://www.databasejournal.com/features/article.php/3593466

Here are some resources that our dev team uses:

This book is good for getting up to speed on MDX basics: Fast Track to MDX

Caveat: The cube they use is very different from the TFS cube.

MSDN on MDX: http://msdn2.microsoft.com/en-us/library/ms145506.aspx

Lots of trial and error with Report Designer.

Blogs:

Mosha’s blog is great for OLAP/MDX: http://www.mosha.com/msolap

Brian Welcker has a lot of stuff on SSRS: http://blogs.msdn.com/bwelcker/default.aspx

Chris Hays has a bunch of “hacks” for SSRS: http://blogs.msdn.com/ChrisHays/

Ameya’s blog has some good resources and some videos on different report authoring tools (you don’t have to just use Report Designer!): http://blogs.msdn.com/ameyab/

Forums:

TFS Reporting forum: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=480&SiteID=1

TFS General forum: http://forums.microsoft.com/msdn/showforum.aspx?forumid=22&siteid=1

Analysis Services forum: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=83&SiteID=1
Reporting Services forum: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=82&SiteID=1

Excel Discussion Group: http://www.microsoft.com/office/community/en-us/default.mspx?dg=microsoft.public.excel.misc

Visio Discussion Group: http://www.microsoft.com/office/community/en-us/default.mspx?dg=microsoft.public.visio.general&lang=en&cr=US

Team Foundation Server Reporting and Visio 2007

Ameya — Thu, 01 Mar 2007 01:04:00 GMT

Visio 2007 has some very cool new reporting features. I'm very excited about the the PivotDiagram features in particular. PivotDigrams can be used to slice and dice data just like Pivot Tables in Excel. Here's an example of a Visio report that shows the active and resolved bug and task distribution across a number of projects on a server. And, here are a couple of videos that walk you through writing these reports.
Video: Building a Team Foundation Server report using Visio 2007 Part 1

Video: Building a Team Foundation Server report using Visio 2007 Part 2

Let me know if these walkthroughs were useful and if you have any other walkthrough ideas I'd love to hear those as well.

[Cross posted at http://blogs.msdn.com/ameyab]

A cool report authoring tool

Ameya — Wed, 24 Jan 2007 01:51:00 GMT

In V1, the primary report authoring options are 1/ write SQL Server Reporting Services (SSRS) reports using Visual Studio Report Designer (part of the Business Intelligence Studio – or BIDS) 2/use Excel to connect to the cubes and build reports. Users can use also use Report Builder, a report authoring tool that ships with SSRS, but they need to build the appropriate report models first.

Report designer is an apt tool for developers. It provides a set of powerful features for SSRS reports. However, it is not a tool for the casual user, who wants to build ad hoc reports. Excel’s really meant for that purpose.

In addition to these, there are some cool report-authoring tools developed by our partner that provide powerful report authoring capabilities. Recently I had a chance to see Radius – a report designer developed by folks at 90 Degree Software. The tool allows users to author SSRS reports. The UI is very similar to the Office 2007 UI, so folks familiar with Office should feel pretty comfortable. Besides making it easy to develop reports, it allows report components to be reused. Users can “shred” their reports, save the reusable parts to a library. Other users can reuse these report parts in their reports. The V1 release supports building reports against SQL relational DBs and I have been told by the 90 Degree team that support for multi dimension cubes is coming soon. The tool is extensible and dev can write their own extensions to extract data (and build reports) from other data stores. They have already built an add-in that uses the TFS APIs as a data store. Check it out!

[Cross posting to http://blogs.msdn.com/ameyab]

Tell us what you think about TFS Reporting

Ameya — Thu, 18 Jan 2007 22:24:00 GMT

Reporting is a very powerful feature in TFS. It has a lot of capabilities and can provide some very deep and meaningful insights across the development lifecycle. But, some of our customers aren't using the reporting system to its fullest potential.

The reporting team is interested in learning more about what you it is that you want out of the reporting system. We want your feedback on what issues/limitations/pain-points frustrate you the most, what features/changes would excite you, what reports you find useful, what reports you would like to see out of the box, what type of reports you have built, who builds these reports, the reporting authoring experience – what works/doesn’t work, etc. This information will help us chart the course for delivering the reporting features in our next releases that you will find valuable.

Please take 10-15 minutes to give us your feedback. You can access the survey here: http://www.zoomerang.com/survey.zgi?p=WEB22632D8HGS3

Ameya

[Cross posting to http://blogs.msdn.com/ameyab]