Interested in learning more about MTM? Checkout my Pluralsight course on Microsoft Test Manager.
This is part 1 of an Intro to MTM series. Here is part 2.
This summer, I did two presentations on Microsoft Test Manager. It is still a relatively unknown and unused tool, but when people get exposed to it and see it in action, I can tell that they get excited by it as they start thinking about its possibilities. This series will cover a lot of what I went over in those presentations.
What is Microsoft Test Manager (MTM)?
MTM is a tool introduced along with Visual Studio 2010 and TFS 2010. It is used to create and organize test plans and test cases, and execute manual tests. MTM is built specifically for testers to be able to interact with other members of the team.
Why MTM?
Prior to the 2010 release, Visual Studio Team System covered the majority of the team, but QA did not have any really good tools. Most QA shops were left to either use a combination of applications such as Excel, Word, Notepad, etc or a lot of times the QA team would use specialized testing tools such as the HP test suite.
MTM gave Microsoft all the essential pieces to go from a development solution to a full ALM solution. This was the final piece needed to get the entire team communicating through TFS rather than using 3rd parties or synchronizers. Along with a new name for Team System (now Visual Studio ALM), the new picture looks like this:
How does it work?
MTM allows you to plan, execute, analyze, and track your test cases. You are also able to automate your test cases through the use of Coded UI tests and add them to your builds. So there is a lot of integration between the entire team. From within MTM, you also have access to Lab Management, which allows you to manage tests across multiple virtual environments. We will focus on Test Case Management for now.
Planning
We start by taking a look at the “Plan” tab in MTM. Of course, the first step is to plan what the test team will be working on. When you first start up MTM and connect to a TFS Server (you must be using TFS to be able to use MTM), you are taken to Testing Center plan selection screen: 
At this point, you can either select an existing plan or you can add a new test plan. Each test plan is referred to as a “Test suite”, you can have multiple Test Suites under each suite (hierarchical) or you can just create all your test cases under the root. 
From here, you can create a new test case, add an existing test case, edit test cases, and change test suite properties. Let’s take a look at the properties screen: 
This screen allows you to manage your test suite (name, description, owner, status, start/end date. You can also assign it to an Area Path and Iteration, just like you would for a Story, Task, Bug, etc in Team Explorer. Behind the scenes, a test plan and a test case is just a work item.
The part that interests us the most here is the “Run Settings” section (middle of the screen). This is where you can customize how your test cases are going to run and set environment settings. Here is the Test Settings screen: 
On this screen you specify the type of information that will be gathered during test runs. This is really important as it will help testers and developers communicate and re-create any issues that you run into. So this should reduce any “Can’t repro” or “Works on my machine” bug responses. You can set settings on the following diagnostic values:
– Actions: What applications will be recorded for play-back
– ASP.NET client proxy: Lets you collect information about the http calls from a client to a Web server (used along with IntelliTrace)
– Event Log: Event logs and event types that should be collected.
– IntelliTrace: Data that should be collected by IntelliTrace (Processes, Events, etc)
– Network emulation: To emulate slower networks
– System Information: OS, memory, etc
– Test Impact: This is probably one of the most powerful features. It collects information about which methods were called by your application. When a developer touches that same method, then the test cases will be flagged to be re-run.
– Video recorder: Records the tester’s desktop while a test runs, which helps with reproducing any bugs.
In addition to all these settings, you can specify which Build your test cases are going to run against and also the configurations that you are going to test (Windows 7 + IE 8, Windows XP + Firefox 3, etc).
Creating a Test case
Obviously, the most important feature would be to actually create your test cases. Here is the screen for that: 
If you are familiar with TFS, this probably looks familiar to you. A test case is a work item, so you will have a lot of the common fields that you’ve seen in other Work Item Types towards the top. Something that is new to us is the “Steps” tab. This is where the user would enter all the steps that a tester would need to follow in order to complete a test case. This is specific to a manual test case, so the test steps should be written as human-readable as possible. There are some interesting things that you can do here, such as combining multiple test steps into “shared steps”, which would allow you to reuse your steps in other test cases. To do this, You just need to highlight the test steps, right-click and select “Create Shared Steps”. To use them in the future, you can click on the “Insert Share steps” toolbar button.
You can also use parameters in order to make your test cases data-driven. Take a look at Step 4 on my screenshot above: “Add Mailing list item: @Name, @Email, @Twitter”. When MTM sees a word preceded by an @, it adds is a parameter on the “Parameter Values” section at the bottom. This allows you to create multiple iterations. Later on, I will show you how to use them to achieve some automation on your manual test cases.
There are other tabs such as the “Tested User Stories”, which allows you to relate a test case to a User Story in order to be able to track progress/completeness.
So that covers the first part of this series. Next step is Test Execution.
Interested in learning more about MTM? Checkout my Pluralsight course on Microsoft Test Manager.