The first thing is that you need to understand the CQ Schema. You do not need to use the CQ Designer – you can learn everything you need just by creating queries. So to begin with you need to know what you want to migrate (obviously) but we’re talking about what the work item types are and their relationships to other work item types (records) in CQ. For this example, I will show you how to migrate a “ChangeRecord” with a related “WorkRecord”. These will be migrated to a Requirement work item in TFS with a child Task work item.

Figure 1 shows a small portion of the ChangeRecord type in ClearQuest.

The critical thing to note about this is that we are not referencing the WorkRecord as part of the relationship at all. We are referencing the WRList “Field_Reference” field type. And that’s another – ClearQuest is case sensitive. Note that as you create your XML configuration file.

Once you have this information you need to create the queries (yes, you need at least two queries to perform a migration with links). The first query should be the first part of the link (in this case the “Parent” part of the relationship) and should return only those records that are going to be Parent work items. In this case the query will return only ChangeRecords. The second query, should, obviously be the child part of the query. The query used in this example will return WorkRecords which have ChangeRecord “parents”.

Next you need to set the queries to use in the Integration Platform like so:

After this comes the mappings. This is a straightforward mapping exercise. Here you will note the mappings I mentioned previously. The last part, setting the link type has to be done in the XML itself. Select the XML tag at the bottom of the settings form.

By default (and this is really important – if you do not follow this step, the migration will succeed but the linking will fail) there is a single line that reads as follows:

<LinkTypeMapping LeftMigrationSourceUniqueId="79841a53-d698-4107-a2df-5ff935e0e0c9"
 LeftLinkType="ClearQuestAdapter.LinkType.Duplicate"
 RightLinkType="Microsoft.TeamFoundation.Migration.TFS.LinkType.WorkItemToWorkItem"
 RightMigrationSourceUniqueId="c80d3b9a-a40e-4aa7-bfb2-7828971ac4f0" />

You can, in most cases safely delete this line, but don’t do it yet! First, if you are going to keep it, copy it. You want the Unique ID’s from both the left and right migration sources. Once you copy it change the link types as follows:

<LinkTypeMapping LeftMigrationSourceUniqueId="79841a53-d698-4107-a2df-5ff935e0e0c9"
 LeftLinkType="ClearQuestAdapter.LinkType.ReferenceListFieldRecordLink.ChangeRecord.WRList"
 RightLinkType="System.LinkTypes.Hierarchy"
 RightMigrationSourceUniqueId="c80d3b9a-a40e-4aa7-bfb2-7828971ac4f0" />

There are two differences to note as highlighted. The first is that the reference link for CQ must specify the work item.work item list. In other words, the relationship isn’t ChangeRecord.WorkRecord but rather ChangeRecord.list type as shown in the first figure. The second item is that the WorkItemToWorkItem link is a hold over from the TFS 2008 migration provider. We’re passed that obviously. To convert the link from whatever link type in CQ to TFS simply use the TFS link type (to get a list of these, do a witadmin exportlinktype and take a look at the resulting file).

Please note that none of this is documented in the Integration Platform documentation. Hopefully this will be updated soon with this information. For now, this is how to do it.

Enjoy!

To enable it, go to the test settings and select Code Coverage (there are some options but you don’t need to set anything).

You do need to create an automated build (if you aren’t doing automated builds now, you need to be doing it NOW – it’s the fastest way to improve quality). After you set the settings and associate the automated build, run your manual test. When you’re finished, close the Test Runner and click the Analyze Test Runs page.

Make sure you have the View: Manual runs selected and double-click your completed test run. This opens up the test run summary.

Expand the Attachments node and you will see a data.coverage file (note that you ran more than one .NET application during the test run you will see multiple files). Double-click it to open it. This will open Visual Studio to display the code coverage results.

This screenshot shows all of the methods in the executable and the covered and not covered blocks.

Double-clicking a method brings up the file with code coloring enabled.

Brilliant!

Now teams can ensure that they are covering all of their code with their functional tests as well as with their unit tests.

Getting feedback from our customers, stakeholders, product owners and others can be a sometimes painful process – and if you aren’t co-located it’s even more difficult. Remembering what happened in a session is harder still – you forget to take a note on something and then you can’t remember what the customer said and you have to follow up with them. Into this, Microsoft is releasing a new Feedback Management tool.

To explain the process, it’s helpful to look at some of the new stuff related to work items and the process flow in Dev11 (I’ll cover details of new work items later so for now you can just ooohhhh and aaaahhhh the cool new Metro UI ).

This figure shows the new User Story work item (this is the web based view but you will be happy to note that the Team Web Access view and the Visual Studio view are identical). This tab shows the Storyboards tab. Storyboards a new feature implemented through Microsoft PowerPoint (I will cover this in a later post also). The Storyboard is where you first lay out what the user interface looks like and how the flow of the feature moves.

Another new tab is the Feedback tab.

On this tab, team members can request folks to provide feedback on a feature. This is designed to be used once there is a user interface that the user can interact with so this could be used multiple times throughout the development of the story. Feedback is another type of work item in Dev11.

This is a completed feedback work item which contains feedback (how to do this is coming up next). The item can be requested by someone, feedback submitted by someone and then reviewed by someone. The user can provide ratings and comments which you can see on the right-hand side. Once feedback is requested of a user the user can spool up the Feedback Manager (this is a separately installed tool but we have no information on licensing at this point – we hope this will be available to all users). When the Feedback Tool is launched it looks like the following:

If you are familiar with Microsoft Test Manager (MTM) this is built on the same framework and provides a subset of the capabilities. The reviewer will see the stories that they need to provide feedback on listed up above and they can select the story (click on it) and it will show the description tab of the story (shown below):

As the user goes through the application, they can enter text, perform screen captures (yes, you can use the screen capture tool of your choice – I prefer Snagit – clicking the Settings button will allow you to configure this) and annotate those screen captures. It records video, audio (even when using remote desktop – a nice feature that was well thought out) and saves all of that information to the feedback work item for review by the team.

Providing feedback on an application has never been so easy and should be welcomed by many teams as a way to integrate their users deeper into the development process and to get accurate and timely feedback that can quickly and easily be referred to.

In a strict world of Scrum you have a Product Backlog and when you begin a sprint you move the items that you are committing to into the Sprint Backlog and then you pull your work from there – almost like a Kanban system but not quite, because the Work In Progress (WIP) limits are at a higher level and in general it tracks work at a higher level than Kanban does as well as several other differences.

The major problem we continuously run into is the complexity of the network and the hardware involved in the work that we do. To add to the complexity is the fact that different teams (which we have no influence over) take longer to do work than we do and they are governed by a strict set of Service Level Agreements (SLA) which you will often find in large companies where some of the core work, such as server maintenance or data center maintenance, is subcontracted.

Scrum, combined with the team size gave us the perfect ability to hide our problems which was not a good thing. What would happen is that teams would run into a problem in, say, the development environment and set things in motion to solve the problem (opened a ticket with the server team) and would then move on to the QA environment. The problem would occur in the QA environment and then move to the Pre-Prod environment – all the while this problem still occurred. But because the team kept pulling items from their queue to work on, they were “busy” all of the time and reporting good progress – but not actually completing anything.

I should note that some of the user stories were straight technical stories – software being installed for instance to get various environments up and running.

The problem here was two-fold. The first is that the way the user stories were constructed, installing software and moving code from Dev to QA to Pre-Prod were all part of a single user story – it was just different parts of the requirement and Scrum doesn’t track down at the task level. The second part is that the “in progress” bucket can be huge – it is up to the practitioner to break the story down into a manageable level. So lo and behold we were building up a huge amount of technical debt that turned out to be fatal for this iteration. What happened versus what should have happened?

What happened?

First a team of 15+ people is too big for a 15 minute standup each morning. 15 people x approximately 3 minutes each = 45 minutes. That’s a bit outside of 15 minutes and our team is actually larger than 15 people. So what did we do?

Mistake #1

We eliminated the 15 minute standup meetings in favor of a once weekly team meeting.

There were other forces involved in this decision – at any large company there are going to be a lot of meetings and the team was suffering from “meeting fatigue”. As the Scrum Master I didn’t want to add to it and I couldn’t figure out how to keep the meetings to 15 minutes regardless. This, of course, led to the second problem.

Mistake #2

In a larger team meeting, people are concerned that they will be looked on negatively if they keep reporting problems. So they don’t – or they under-report the magnitude of the problem.

Our iterations are one month long. This took me two months of looking back at the data to realize. Once I figured it out, I committed mistake #3.

Mistake #3

Private conversations regarding the problems people are experiencing do not allow the team to focus their energies on the problem at hand – it becomes an individual firefighting experience.

We have a lot of very talented people on our team. By having one on one meetings with individuals who were having problems I was getting right back into the problem that mistake #1 was designed to solve – the number of meetings skyrocketed as I had to deal with a whole bunch of problems one on one. In addition, I wasn’t able to bring the knowledge of the entire team to bear on a problem – I had to schedule more meetings to do investigation instead of just having everyone pitch in at once.

To be honest, some problems – specifically those that rely on external forces – can only be solved by escalation to management. And this lead to Mistake #4.

Mistake #4

I didn’t recognize the negative impact of the groups culture – which is, they were not rewarded for bringing problems to light. The team members felt management didn’t care – that they just wanted the problem solved but they didn’t want to know about it.

I am not management – I never will be. But because of my role team members felt that reporting problems to me was the same as reporting them to management. Which they were highly reluctant to do. This lead to Mistake #5.

Mistake #5

The team members had enough work in their queue that they could simply move on to something else. By not updating their status correctly I had no visibility of this.

What they essentially did was to try to handle the problem on their own, reported that everything was okay and on track when in fact that was far from the truth. They kept hoping that things would come back on track which they never did because no effective intervention ever took place. This effectively let us hide waste. There was one more problem that came out of all of this.

Mistake #6

We didn’t recognize quickly enough that the handoffs between team members were difficult and not working well at all.

In Scrum, one person is generally responsible for a user story from beginning to end – there is a concept of ownership. We tried to do that – as the Scrum Master I had the ownership. Why not a Product Owner you might ask. Good question – the team was reporting to five product owners at the same time with approximately 8 different statements of work per month. We are a core solutions team so we provide many different solutions for different customers on the same infrastructure. The reason for individual team members not taking ownership is because there were many coordination’s that had to occur to get a single piece of work done because of the specialized skillsets required to get the work done (we recognize the need to grow the skillsets but that can’t be done overnight). Essentially there was no coordination or collaboration in the handoffs of work or even the scheduling for when work would be done.

Those are the big six mistakes that I feel, in retrospect, that I made as a scrum master with this particular team. So, what did we do about it and how did it work? I can’t tell you how it worked because this is a work in progress and this is the first month we are doing this but I’ll post back with a follow up.

Countermeasures we put in place

Solution #1 – Implement a Scrum of Scrums

The immediate step was to appoint two additional Scrum Masters and “break” the team up into three autonomous teams (that is, each team is self contained – the mix of resources is such that each team has someone with the specialized skills needed to work a particular technology or type of solution).

This was done so that the Scrum Masters could more effectively deal with problems since they were only overseeing a small number of team members. And oversee is too strong a word, the Scrum Masters did perform some work as well. This freed up my time to do some more work since I was now the Scrum Master for only 6 people (including myself). This immediately led to another quick solution…

Solution #2 – Reinstated the daily stand-ups

The smaller teams allowed each Scrum Master the ability to hold daily standups that actually last only 15 minutes.

The standups are four days a week plus one team meeting that lasts one hour. The Scrum Masters also have a once a week coordination standup meeting. We ask the same three questions but reserve the right to extend the meeting to coordinate resources to meet special demands.

Solution #3 – A “true” Kanban approach

Individuals are assigned only one requirement at a time – the other requirements are held in an iteration backlog and are assigned to the generic resource of “Product Manager”. We do not discuss these items with the team members at all during our iteration planning meeting.

This had a whole bunch of ramifications. The first is that we would not commit to a full iterations worth of work – we created a monthly “roadmap” which said, “these are our goals for the month which we will try to reach”. The upside to this approach is that our iteration planning meetings went from 7 hours to 2 hours. Nice. The downside to this approach is that our team is currently really unable to make a commitment and stick to it. We had not been doing it for the last year so this is really no change from the status quo but it leads to another benefit:

When a problem is encountered it is surfaced and dealt with in a 24 hour period. What do I mean by this? Well, since team members are only allowed to work on one item at a time (a WIP limit of 1 as it were) when something goes wrong and they cannot fix it themselves we (the Scrum Masters) either find out about it in the next standup meeting or the team member contacts the Scrum Master as soon as the problem is recognized and it can be elevated to management ASAP. Work halts until the problem is solved. We then capture the resolution to these issues and turn around and drive them back into the process.

Note that this is a work in progress and we’re still working out how to best drive the problem resolution back into the process so we avoid the problem in the future.

In addition, this alleviates some of the management role that I was playing because if team members do not escalate problems, they have to explain to their management why they were working on one tiny item with an estimate of 8 hours for a week. It also allows Scrum Masters, through empirical observation to detect problems earlier.

Did I mention that our entire team is virtual and spread out all over the US?

Solution #4 – Reward problems discovered

The last item is to celebrate when a problem is found – the earlier the better.

We are using TFS for our work and created a special area for internally created issues. We encourage team members to report issues with the process as they find them. We review these issues each iteration and take one to improve upon as part of our work structure. It remains to be seen how effective this will be but it’s a start.

Conclusion

I debated whether or not to share this experience and in the end decided that there must be other teams running into these problems. I’ve been doing this for 5 years now (stricter focus on process and methodology that is) and I knew all about these problems and yet I let the politics of the organization suck me right back into things that I have coached other teams for years on how to avoid. Talk about feeling dumb.

And I had tried other things along the way but kept running into the same problems because I could not trust the team to do things in the way they needed to be done. While I still have that problem, I was also part of the problem because I was not explicit enough in explaining to the team why we needed things done.

Hopefully, this post will help other people who might be in the same situation.

The various tables are TreeIDPairs, TreeNodes, xxTree and the views are TreePairs, TreePathParts, TreesAreUsed and TreesWereUsed. All of these views and tables have problems with them in one way or another. For example, the TreePairs view has columns called Name (all values are a ‘\’) and AboveID (all values are ‘0’) – not very useful. The TreesAreUsed contains the full Area Path but no Iteration Path. The xxTree has both but I preferred to not rely on that table (anything with an ‘xx’ to start the table name tells me it either is, or may be, deprecated). So I wrote my own query which I thought might be helpful to others.

WITH FullIterationPath (ID, ParentID, Name, tlevel, hierarchy)
AS
(
    --Anchor definition
    SELECT    a.ID,
            a.ParentID,
            a.Name,
            0 as tlevel,
            a.Name as hierarchy
    FROM    TreeNodes a
    WHERE    ID = 439    --FEC Solution-Products Root
    UNION ALL
    --Recursive definition
    SELECT    a.ID,
            a.ParentID,
            a.Name,
            tlevel + 1 as tlevel,
            cast(hierarchy + '\' + a.Name as nvarchar(255)) as hierarchy
    FROM    TreeNodes a
    JOIN    FullIterationPath b ON b.ID = a.ParentID
)

SELECT    ID,
        ParentID,
        Name,
        tlevel,
        hierarchy
FROM    FullIterationPath

You can also use this to construct the area path as well.

2011-05-24T11:14:55 | Module: Work Item Tracking | Thread: 29 | The following query was found in C:\Users\xxxxxxx\AppData\Local\Temp\TPW_tmpA576.tmp\WorkItem Tracking\Queries\Iteration1Backlog.wiq: Iteration 1/Iteration Backlog
---begin Exception entry---
Time: 2011-05-24T11:14:55
Module: Engine
Event Description: TF30162: Task "Queries" from Group "WorkItemTracking" failed
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: Team Foundation Server encountered an error creating the query Iteration 1/Iteration Backlog from C:\Users\xxxxxxx\AppData\Local\Temp\TPW_tmpA576.tmp\WorkItem Tracking\Queries\Iteration1Backlog.wiq
Stack Trace:
 at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.Execute(ProjectCreationContext ctxt, XmlNode taskXml)
 at Microsoft.VisualStudio.TeamFoundation.ProjectCreationEngine.TaskExecutor.PerformTask(IProjectComponentCreator componentCreator, ProjectCreationContext context, XmlNode taskXml)
 at Microsoft.VisualStudio.TeamFoundation.ProjectCreationEngine.RunTask(Object taskObj)
--   Inner Exception   --
Exception Message: Team Foundation Server encountered an error creating the query Iteration 1/Iteration Backlog from C:\Users\xxxxxxx\AppData\Local\Temp\TPW_tmpA576.tmp\WorkItem Tracking\Queries\Iteration1Backlog.wiq (type WitPcwFatalException)
Exception Stack Trace:    at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.WitPcwTask.QueryTask.AddQuery(String name, String fileName, String path, QueryFolder parent)
 at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.WitPcwTask.QueryTask.ParseQuery(XmlNode node, String parentPath, QueryFolder parent, Boolean execute)
 at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.WitPcwTask.QueryTask.ParseQueryFolder(XmlNode node, String parentPath, QueryFolder parent, Boolean execute)
 at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.WitPcwTask.QueryTask.Parse(Boolean execute)
 at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.WitPcwTask.QueryTask.Execute()
 at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.Parse(ContextWrapper wrapper, XmlNode taskXml, Boolean fExecute)
 at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.Execute(ProjectCreationContext ctxt, XmlNode taskXml)
Inner Exception Details:
Exception Message: TF51005: The query references a field that does not exist. The error is caused by «[System.TeamProject]». (type InvalidQueryTextException)
Exception Stack Trace:    at Microsoft.TeamFoundation.WorkItemTracking.Client.StoredQuery.ValidateWiql(WorkItemStore store, String queryText)
 at Microsoft.TeamFoundation.WorkItemTracking.Client.QueryDefinition.SetQueryTextWithValidation(String queryText)
 at Microsoft.TeamFoundation.WorkItemTracking.Client.QueryDefinition..ctor(String name, String queryText, QueryFolder parent)
 at Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPlugin.PcwPluginComponentCreator.WitPcwTask.QueryTask.AddQuery(String name, String fileName, String path, QueryFolder parent)
Inner Exception Details:
Exception Message: TF51005: The query references a field that does not exist. (type SyntaxException)
Exception Stack Trace:    at Microsoft.TeamFoundation.WorkItemTracking.Client.Wiql.NodeFieldName.Bind(IExternal e, NodeTableName tableContext, NodeFieldName fieldContext)
 at Microsoft.TeamFoundation.WorkItemTracking.Client.Wiql.NodeCondition.Bind(IExternal e, NodeTableName tableContext, NodeFieldName fieldContext)
 at Microsoft.TeamFoundation.WorkItemTracking.Client.Wiql.Node.BindChildren(IExternal e, NodeTableName tableContext, NodeFieldName fieldContext)
 at Microsoft.TeamFoundation.WorkItemTracking.Client.Wiql.NodeAndOperator.Bind(IExternal e, NodeTableName tableContext, NodeFieldName fieldContext)
 at Microsoft.TeamFoundation.WorkItemTracking.Client.Wiql.Node.BindChildren(IExternal e, NodeTableName tableContext, NodeFieldName fieldContext)
 at Microsoft.TeamFoundation.WorkItemTracking.Client.Wiql.NodeAndOperator.Bind(IExternal e, NodeTableName tableContext, NodeFieldName fieldContext)
 at Microsoft.TeamFoundation.WorkItemTracking.Client.Wiql.NodeSelect.Bind(IExternal e, NodeTableName tableContext, NodeFieldName fieldContext)
 at Microsoft.TeamFoundation.WorkItemTracking.Client.StoredQuery.ValidateWiql(WorkItemStore store, String queryText)
--- end Exception entry ---

This is the query that the upload was failing on was the following:

  SELECT [System.Id],
 [System.WorkItemType],
 [System.Title],
 [xxxx.Finance.ActivityID],
 [System.State],
 [System.AssignedTo],
 [Microsoft.VSTS.Scheduling.RemainingWork],
 [Microsoft.VSTS.Scheduling.CompletedWork],
 [Microsoft.VSTS.Scheduling.StoryPoints],
 [Microsoft.VSTS.Common.StackRank],
 [Microsoft.VSTS.Common.Priority],
 [System.IterationPath],
 [System.AreaPath]
 FROM WorkItemLinks
 WHERE ([System.TeamProject] = @project
 AND  [System.AreaPath] UNDER @project
 AND  [System.IterationPath] UNDER '$$PROJECTNAME$$\Iteration 1'
 AND (
 [System.WorkItemType] = 'User Story'
 OR [System.WorkItemType] = 'Bug'
 OR [System.WorkItemType] = 'Task'
 OR [System.WorkItemType] = 'Compliance'
 )
 )
 AND [System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward'
 AND [Target].[System.WorkItemType] = 'Task'
 ORDER BY [Microsoft.VSTS.Common.StackRank], [Microsoft.VSTS.Common.Priority]
 mode(Recursive)

The error, it turns out, is invalid and if you try to track it down you’ll be hopelessly disappointed. The problem is that this is a hierarchical query and because of copy and paste issues I inadvertently removed the “[Source]. value that is required before the names of the fields in the filter. The correct query should look like the following:

SELECT [System.Id],
 [System.WorkItemType],
 [System.Title],
 [xxxx.Finance.ActivityID],
 [System.State],
 [System.AssignedTo],
 [Microsoft.VSTS.Scheduling.RemainingWork],
 [Microsoft.VSTS.Scheduling.CompletedWork],
 [Microsoft.VSTS.Scheduling.StoryPoints],
 [Microsoft.VSTS.Common.StackRank],
 [Microsoft.VSTS.Common.Priority],
 [System.IterationPath],
 [System.AreaPath]
 FROM WorkItemLinks
 WHERE ([Source].[System.TeamProject] = @project
 AND [Source].[System.AreaPath] UNDER @project
 AND  [Source].[System.IterationPath] UNDER '$$PROJECTNAME$$\Iteration 1'
 AND (
 [Source].[System.WorkItemType] = 'User Story'
 OR [Source].[System.WorkItemType] = 'Bug'
 OR [Source].[System.WorkItemType] = 'Task'
 OR [Source].[System.WorkItemType] = 'Compliance'
 )
 )
 AND [System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward'
 AND [Target].[System.WorkItemType] = 'Task'
 ORDER BY [Microsoft.VSTS.Common.StackRank], [Microsoft.VSTS.Common.Priority]
 mode(Recursive)

Update: Microsoft released a QFE to address the issue outlined below.

Here is a summary of the list of issues fixed by the QFE, to help you decide whether you should apply the QFE:

Issue 1: When you run tests on the test agent that is installed on a computer that has Visual Studio 2010 SP1 installed, the tests may not run, and the following error message is logged:

Attempted to access an unloaded AppDomain. (Exception from HRESULT: 0×80131014)

Issue 2: When you run a playback of a Coded UI Test on certain Windows Presentation Foundation (WPF) controls, a Microsoft.VisualStudio.TestTools.UITest.Extension.UITestControlNotFoundException exception occurs, and then you receive the following error message:

“Search may have failed at ‘<name>‘ <control type> as it may have virtualized children. If the control being searched is descendant of ‘<name>‘ <control type> then including it as the parent container may solve the problem.”

Issue 3: When you try to create a work item from the Test Results pane in Visual Studio 2010 after you connect to a Team Foundation Server (TFS) server, a System.OutOfMemory exception occurs, and the creation operation fails. This issue usually occurs if the TFS server has many builds.

Issue 4: When some tests run in a build operation, some builds that are queued in a TFS server stop responding. Additionally, the following error message is logged in the build log:

Waiting to publish…
Publishing results of test run <build name> to http://<TFS server address>:8080/tfs/DefaultCollection…
The process cannot access the file ‘<directory>\data.coverage’ because it is being used by another process.
Publish failed or canceled.

——————————————————————————————-

As I was preparing for a demo of lab management the other day I did what we tell all of our customers to do – patch everything to latest service packs which of course included TFS SP1 on all of our machines. That includes the TFS server and all build servers and virtual lab environments.

By the way, using the lab prep tool you must manually install SP1 after the VM is prepped otherwise you get a few errors. But I digress.

After I patched everything I ran a test to verify that everything worked. I created a manual test, recorded it and turned it into a CodedUI test with validations. All went smoothly. Then I ran a lab build and got a failure. Looking at the automated test run (MTM > Testing Center > Test > Analyze Test Runs I noticed the following log:

You will note the last three items. Even though the test log shows that the test executed successfully, it did not. If you remove the diagnostic data adapters, the error on line 17 will be removed but the errors on 16 and 18 continue.

It turns out that when SP1 was released, it caused a problem with the test agent running in the lab environment. A simple solution for my needs was to uninstall SP1 from the machines in the lab environment and everything ran fine again – or so I thought. However, when you do this, IntelliTrace does not work because of the mismatch between the external test controller (patched to SP1) and the internal test agent (RTM). Or so I believe right now.

Microsoft has confirmed this to be a problem and they are actively working on a QFE for this. I will drop another post once this QFE is released.

[TestCleanup()]
public void MyTestCleanup()
{
    if (TestContext.CurrentTestOutcome == UnitTestOutcome.Failed)
    {
        Image img = UITestControl.Desktop.CaptureImage();
        img.Save(Path.Combine(TestContext.TestResultsDirectory, "FailureSnapshot.png"));
    }
}

By placing this code in the TestCleanup method, whenever a test fails, the last screen of the test will be captured and saved in the test results directory which will automatically be captured at the end of the test run.

So this is my first post back. My new book, “Software Testing with Visual Studio 2010” has been released. You can get it at Amazon. One of the nuggets inside is a coupon from Northwest Cadence for discounted training classes.

Any feedback on the book is welcome.

In addition, the book Professional Team Foundation Server 2010 has been released which contains a wealth of information. You can read more about that book and get it at Amazon also.

Expect to see a lot more posts and a lot more tips and tricks otherwise I will be hearing from Martin.