Team Foundation Server – Test Center and Visual Studio build list management

One of the great things with the Team Foundation server 2010 is the integration between the different parts. In this blog post, I’ll go through the connection between a Test Plan and the Build System.

A Test Plan should be connected to the builds being done in order to reap the most benefits from the system.  The test plan can be connected to the builds through the Properties page on the test plan you are working with, or you can connect it when you start a test run, by choosing “Run with options”.  The builds should also be properly set up, as shown below.

First, let us start with the Test Plan.  When you choose a build to connect to , you get a list of candidates. These candidates are based on the settings given on for each test plan, on its Properties page.

Select the Properties tab for the test plan you are working on.  Locate the section named Builds: The candidates are filtered based on the settings given here. 

Choose the build definition matching the builds you are using for your test.  This will normally be a special manual build, a kind of production build or test build.  See here for some definitions of these terms: http://geekswithblogs.net/terje/archive/2009/10/25/on-branches-and-builds-in-team-foundation-server.aspx 

Also, choose an appropriate Build Quality, like for example “Ready for initial test”.  This requires you to set the corresponding build quality, which is done either on the build page itself or on the build list.

or if you click the build itself, note the drop down near the header where you can set the Build Quality

If you don't like the default build qualities, you may change these to whatever suits you.  You do this from the Visual Studio Team Explorer, Build section, right click this, and select “Manage Build Qualities”:

and you get to this dialogue, where you may modify these:

Ok, done that – go back to the Test Plan Properties.  The next thing to do is to connect the test plan with the build to use for this test run.  G back to the Builds section there.

Choose Modify on the Build in use. You get to the Assign Build page, and it should now look like this:

Sometimes, the Available build doesn’t come up with anything, then do a  Refresh, and it should be there (little green refresh button to the far right).  Press Assign to Plan to set this to the build of your choosing.

You can, as mentioned above, set the build to use when you choose to run your test.  Then choose the Run with options

and selecting it gives you the opportunity to, among a few things more, set the current build.

A Snag and a Trick:

The list of builds to choose from can get rather long.  In order to keep this down, the system for selecting builds gives you only the unassigned builds in  the list.  Earlier builds are not shown.  This is not quite clear in the system, so it is worth mentioning, and sometimes one really has to go back and retest an earlier build.

One do this from the Build filter dialog

Press the Clear All button, and the list is cleared, unfortunately also clearing the Build Definition and the Build quality settings too, so you have to put these back.

Benefits

One of the great benefits from connection the test plan with the builds are that this enables the use of Test Impact analysis.  When you are running a new build, the Test Impact analysis collector will pick out which tests you have to run again based on information collected during your former test run and the change sets that are part of the new build.  This is invaluable when your tests get large, and is THE answer to the questions testers always ask: “Do I need to test it all again?” or “Which tests do I need to run?”.  Now the tester can easily see this for herself using the Recommended Tests page.  The recommended tests page are found on the Track pane of the Test Center.