Each work item in TFS contains an All Links Tab where you can see all the links to this work item grouped by relationship type.
There are other tabs that just show specific links like Implementation, Change Requests, Test Cases. These tabs are filtered to only show certain types of relationships and the work items that can have this relationship.
It’s very easy to create your own Tab that shows specific links and the work item types that you want the user to include.
As an example lets create a Review Tab on the Requirement work item in the CMMI Process Template so we can see the Design Reviews associated to this requirement.
Open up the CMMI process template using the Process Template editor that comes with the TFS Powertools.
Lets create a custom link type to be used for Reviews. From the Process Editor select Methodology | Work Item Tracking | Link Types and click the new Button. Fill in the New Link type to represent a Reviewed By/Reviews relationship.
Save the Link Type and open the Requirement Work Item type editor.
In the Layout tab right click on the TabGroup node and select New Tab Page from the context Menu. You can right click on that new tab page and select Move Up or Move Down to change it’s order in the Tab control.
Change the Label on the New Tab Page to Reviewed By.
Right click on the Tab Page – Reviewed By and select New Control. Fill in the Control property grid with label, name and type information.
Now select the Control Settings field and click on the button in that field with the ellipses.
From here you can control the links that can be added and viewed with this control.
There are three filters that can be applied.
Work Item Type Filters: Allows you to select the type of work items the can be selected. You can choose to Include All work item types or Include/Exclude a subset of them. For our example we will select Include and check the Review Work item Type.
Work Item Link Filters: Allow you to force a specific work item link type. You can include/exclude all or include/exclude a subset. For our example we’ll Include the new Reviewed By link type we created.
External Link Filters: These are for the non work item links. You can include or Exclude the following external link types.
Fixed in Changeset
Result Attachment
Source Code File
Test Result
Workitem Hyperlink
See my blog entry on Requirements in TFS for an example on using the External Links.
For our example we will set this to Exclude All this way none of the external links will be allowed.
You can also select what columns you would like to show in the list of related work items. I’ll add Called By and Called Date to the selected Columns.
Now with a project created from this process template the Requirement will have a Reviewed By tab that allows users to add Reviews with the link type Reviewed By.
In the blog Functional/System testing with Visual Studio/Test Manager we talked about unit testing. Testers in the near future are going to need unit testing skills. Now that is a very scary statement given 70% of testing is done manually. Now is the time to start learning by taking programming courses, unit testing courses, pairing with developers to learn and searching the web.
In the Visual Studio magazine Jeff Levinson article Take Unit Testing to the Next Level talks about how to add unit tests to requirements to show test coverage. Jeff supplies code you can download and instructions on creating simple unit tests then how to link them to requirements. If you have Visual Studio give it a try.
Thanks Jeff
Testa 
New Agile book by Ken Schwaber and Jeff Sutherland can be pre-ordered at Amazon for a great discounted price.
About the book from Amazon:
A radical approach to getting IT projects done faster and cheaper than anyone thinks possible
Software in 30 Days summarizes the Agile and Scrum software development method, which allows creation of game-changing software, in just 30 days. Projects that use it are three times more successful than those that don't. Software in 30 Days is for the business manager, the entrepreneur, the product development manager, or IT manager who wants to develop software better and faster than they now believe possible. Learn how this unorthodox process works, how to get started, and how to succeed. Control risk, manage projects, and have your people succeed with simple but profound shifts in the thinking.
The authors explain powerful concepts such as the art of the possible, bottom-up intelligence, and why it's good to fail early—all with no risk greater than thirty days.
I highly recommend reading this book.
Testa 
Team Foundation Server (TFS) and Visual Studio(VS) excels when it comes to requirements traceability. Depending on what process you are using in TFS your stakeholders needs are documented in a work item called one of the following: requirements, user stories, use cases or backlog items. For this blog I am using the term requirement.
What is requirements traceability?
Continuous knowledge of the life of a requirement from conception to creation to design to development to verification to implementation and change. The ability to trace a requirements state and/or status at any time during a project.
First step in making requirements traceable.
In Visual Studio other work items are used to identify work that needs to be done to a requirement before it can be deemed done. There are different work item types depending on the process template you are using, however all contain the following: Task, Test Case, Shared Step, Bug. Additional work items can be added if not in your process template like Review, Issue, Change Request to name just a few. All these work items can be linked to the requirement they are helping to fulfill. Visual Studio 2010 introduced the concept of hierarchy by which a work item is linked to another work item using a linked type. The work item task is a child of a requirement, two requirements can be related, a test case tests a requirement. Work items like tasks may be linked to show predecessor or successor of another task. To learn more about choosing link types to effectively track your project click here MSDN Library.
Linked type listing:
Example of a requirement with linked work items:
What can be traced?
In Visual Studio during diagram modeling requirements and other work item types can be attached to objects in the model. During modeling you can either create or link requirements. This allows you to trace work items like requirements from a model diagram.
Example of a Use Case model with requirements linked:
Within the requirement work item I can see all other linked work items and information about them like state, assigned to. Knowing the state of work items linked to a requirement tells me the state and status of the actual requirement itself.
Development when checking in code to VS source control can be forced to associate what requirement or other work item their code relates too. Code check-ins create a Change Set that contains information about the check in and gets linked to the work item(s) associated during a check-in. When fixing bugs this is a nice feature.
In Visual Studio I can create queries to show any type of traceability report. Examples: Requirements to Tests Matrix, Requirements to Tasks, Requirements to Issues, Test Cases with Bugs to name just a few. Queries can also be exported or opened in excel, sent to someone thru email or opened in Microsoft Project. Queries exported to excel allows for adding additional excel reporting features like a Pivot Charts.
Requirements to Test Matrix – is there test cases for each requirement
Visual Studio comes with many reports that trace Requirements showing linked tasks and remaining work left, test case results state and many more scenario’s. Remember depending on what process template you are working with will determine the reports you see.
Example:
Checkout MSDN library for lots more information on Requirements Traceability in TFS & VS.
Testa 
If your reading this blog you likely understand what functional testing and you may use the term system testing.
Wikipedia defines these terms as:
“System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic”
“Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.”
If you have read Agile Software Engineering with Visual Studio (by Sam Guckenheimer & Neno Loje) you will have heard about “reducing waste”. Identified as tasks that reduce waste are functional and system testing. These two tasks can be done during code development through unit tests reducing the cost of bug fixes, bug analysis, creating a suite of automated tests and automated regressions tests and reducing the number of people involved in testing and the bug. In some teams developers and testers have been testing the same thing one through unit tests and then again later by a testers. This is duplication of work effort that is a expensive waste.
In Visual Studio there are unit testing tools and third party add in tools that developers can use to create very robust unit tests. You maybe thinking “the developers do not test the same “stuff” that testers do”. Your right, I agree. However since the team is encouraged to make changes to reduce waste why don’t we testers help them. In Visual Studio we can create test cases that are associated to the requirement/user story work item that describes what needs tested. We can pair up with developers to help them write robust unit tests to cover all the testing including boundary, error and data testing.
There are people that believe the future of the “software testers” is about to make a big change. Testers will need to be able to write and execute unit tests themselves therefore requiring the basics of coding and the ability to add assertions (validation) to the unit tests. (Check out MSDN’s Verifying Code by Using Unit Tests topics. ) I believe this will be a reality in the future but I also believe it will evolve. If you want to start now pair up with your developers to help them create unit tests that execute both the “happy path” and boundaries of an individual method, class or component. Help them to create system integration tests. Getting expose to how unit tests are designed and coded will help you move into the future. In addition having knowledge of what has been unit tested reduces test duplication later. TFS and Visual Studio help us with all this through work item traceability.
Example of work item traceability:
Example of a Test Case and Associated Automation:
Visual Studio has the tools that will help us move into the future with confidence and the security we’ll need. Humans in general are not adapt to change but change we must. I am one of those people that embraces change and excels in change but then I have had Visual Studio in my pocket!
- Kent Beck
The role of professional testing will inevitably change from “adult supervision” to something more closely resembling an amplifier for the communication between those who generally have a feeling for what the system must do and those who will make it do.
Kent Beck author of Test-Driven Development (Addison Wesley 2002), 86.
Visual Studio – my companion, my mentor, my stability, my aid, my reporter, my success
Testa 
(stay tuned, next blog I will show you how easy it is to create a unit test!)
An update is available that includes the following:
Support for multi-line test steps in Microsoft Test Manager
Changes to the 2010 client to allow it to work with a TFS 11 Server
KB2522890 – Team Explorer Crashes when opening build from TFS 2008
KB2552300 - Gated Check-ins fail with the “Preserve local Changes” option
KB2561827 – DiffMerge closes with unhandled exception when comparing two files.
Here is the update: http://go.microsoft.com/fwlink/?LinkID=212065&clcid=0x409
Testa 
Microsoft is making improvements to Lab Manager in TFS11. Brain Harry explains in this blog the primary addition of “Standard Environments” that enables the use of VM Ware with Lab Manager. Brian’s blog goes through how it all works and more.
Brain Harry’s blog.
Testa 
If you are using Microsoft Test Manager you will notice that the work item Test Case does not contain the field Reason. This statement really isn’t true, there is a reason and it is being set for you but not displayed.
The field Reason indicates why a work item is in a particular state. By default the reason field is being set. States Active and Ready only have one reason which get sets by default for you. The state Closed has three options however since it is not displayed by default reason is be set to “Obsolete”. The other reasons available for the closed state are “Deferred” and “Duplicate”.
There maybe other reasons that you are closing a Test Case or setting the state to ready. One example is Test Case reviews. For this scenario you may want to add a reason that indicates the Test Case is in the state of ready “For Review” then a second “Review Done.
We can customize the available reasons but that is for another blog. Below are instructions on how to add the field Reason to display in your work item Test Case.
How do I get the field Reason to display:
1. In the main toolbar of Visual Studio select Tools > Work Item Types > Open WIT from Server
2. Connect to Team Project Collection window opens where you select the collection then click the Connect button.
3. Select Work Item Type window opens where you select a Team Project and the work item Test Case. Click Ok
4. The Work Item Type editor opens as displayed below and you can scroll through to see all the fields available. Reason’s reference name is System.Reason and it is a string data type.
5. Click on the Layout tab where we will add the field Reason to the Test Case.
6. You are looking at a preview of the form layout. Find Group > Column > Group-State > Column. Right click on the second Column and select New Control.
7. The window pane to the right displays. Find Field Name in the adjoining cell click the dropdown arrow and select System.Reason from the listing. Find Label in it’s adjoining cell enter the label you want to display on the Test Case, likely Reason.
Under Column you will see Control – Reason added to the bottom of the listing you can move it up under Control-&State if you want. Where it is in this view is where it will display in the work item.
8. Save your changes and refresh TFS depending on how often TFS is being updated the field Reason will display as below in your Test Case work item.
Testa 
Come out to the Metro Toronto User Group on February 15th. Colin Bowern and I will be showing you how to customize your build process with TFS 2010 and use MS Deploy to automate your web app deployment.
Customizing the TFS Build process and automatically deploying your web app.
When: Wednesday February 15, 2012 at 6:00pm
Where: KPMG, 333 Bay Street, 46th Floor, Toronto
See you there.
Have you ever wanted to have a build that kicks off a bunch of other builds. I recently had such a need, we wanted to have independent build definitions for a bunch of apps. However when you are responsible for deployment you just want to run a bunch of builds at once. If every app is a .net application it’s easy to create one build that builds all the apps.
However in this instance we have two different build process’s. One for .net apps and one for VB6 COM applications. So we created a master build that can kick off multiple build definitions each having a different build process.
First thing is to strip down the Default build Process to it’s bare minimum. Here is what the Build Process looks like.
If you are familiar with the default build process you will recognize the first few items.
The ForEach is the new part. I will explain that in a minute. First we need a new Argument to the build process that will hold the build definitions you want to queue.
Name – BuildDefinitions
Direction – In
Type – String[ ] (Array of Strings)
and a new Variable for the output.
Name – BuildRetVal
Type – IQueuedBuild
Scope– RunOnAgent
You will need to get the Community TFS Build Extensions from Codeplex. If you don’t know how to get started using these, there is plenty of help on that subject here.
To Queue up a bunch of builds drag in a ForEach and iterate over the BuildDefinitions parameter you added.
Inside the ForEach drop in a QueueBuild from the community TFS Build Extensions.
Here is how you fill in the paramaters of the QueueBuild Activity.
Build Controller - BuildDetail.BuildController
BuildDefinition - BuildDetail.BuildServer.GetBuildDefinition(BuildDetail.TeamProject, item)
BuildServer - BuildDetail.BuildServer
Priority - Microsoft.TeamFoundation.Build.Client.QueuePriority.Normal
Process Parameters - Microsoft.TeamFoundation.Build.Workflow.WorkflowHelpers.SerializeProcessParameters(New Dictionary(Of String, Object) From {{"AgentSettings", AgentSettings}, {"Verbosity", Verbosity}})
Result - BuildRetVal
In my example I pass the Agent settings and verbosity through to the called definition. That way I can control them from the master build. In our case we wanted each child build to run on the same agent as the master build so we can accomplish that by passing in the AgentSettings to override those defined in the build definition.
We also passed in the Drop Location and used it in the child so that the child builds each dropped their binaries under the master builds drop folder. Again a choice we made for our situation.
Once you have the process we can define a build definition for the master build. Add all the Build Definition Names you want and the Master build will kick them all off for you. It should look like this.
