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.

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.

Microsoft Test Manager is a great tool for executing manual tests over a set of known paths through an application. It allows you to create and action test scripts and record to minimise duplication of effort.  At first glance, this seems to be the extent of functional support for testing within the tool – however if we dig a little deeper there’s some real nuggets of gold hidden in there. In this article we’ll talk about how the practice of exploratory testing is supported by the tool and how you can turn an unplanned edge case test into a formalised, repeatable test in a matter of clicks.

Setting the scene for exploration

The test manager interface is primarily geared around the creation and organisation of test cases. Even though we’re not going to be executing a formalised test case in this instance, we’ll still need to have a test case to serve as an aggregation point for our results and collector data. So let’s start by creating a new generic test case. To do this, follow the normal steps for creating a test case up until you’d normally start filling out your steps.

Setting up a test case for exploratory testing

At this point enter a single step describing what you’d like to explore. While this isn’t entirely necessary, it serves as a result indicator for the exploration which we can then use in the manager interface and our reports.

Once you’re happy with your test case let’s put on our safari hats and get to exploring…

Dr Livingstone, I presume?

The scenario from here is elegantly simple. We move into the test runner by running the test case we created and start exploring the application. When you kick off the test, ensure you choose to create an action recording so that you’re capturing the paths through the application you’re exploring.

Remember to check the action recording box

If you happen to come across a bug during the exploration you can mark the test step as failed and raise a bug against it.

This will capture the action log, and any other data from the collectors you’re running and associate it with the bug for the developer to help diagnose the issue. In this particular scenario, the action log serves a second purpose which we’ll get to shortly.

What was once random, is now repeatable

Once we’ve completed the test execution and are back in the test manager, we can navigate to the Verify Bugs screen of the Test tab.

Click the link to the verify bugs page

On this screen we’ll see a list of bugs based on a filter. The filter is adjustable but starts with an ‘assigned to me’ criteria.

Change the filter to capture the bugs you require

If we click on one of these bugs the ‘Create Test Case from Bug’ button will activate.

The 'Create test case' button should activate

If we click this button a new test case will pop up with a set of steps derived from our action recording pre-filled and ready to go. The steps are editable as a normal set, so we can remove any we feel are irrelevant or even apply parameters and generate a set of shared steps if we like.

The test case should be largely pre-populated

Once you’re done editing the steps, save the test case and voila! There is a formal test case that can now be used to verify the path you’ve discovered a bug in. From here you can bring the new test case into the appropriate suite and ensure that as the application evolves this now known path is tested effectively.

Summary

Exploratory testing support in Microsoft Test Manager makes dynamically discovering new paths and bugs in your application more effective by enabling you to record your steps and generate formal test cases from them. This helps to eliminate those hard to reproduce edge cases where you can never quite remember what you’ve done to get to the bug, and will help you on your path to a higher level of software quality.

Tagged: MTM, Testing, VS2010

So, if you’re using Excel 2003 or Project 2003, and hoping for integration with TFS 2010 you’re out of luck.  The Office integration in TFS 2010 is limited to Office 2007 (or higher, I suppose).