Microsoft Test Manager provides functionality to manage and execute test cases. In this blog post I’d like to focus on the possibilities of a release and sprint oriented test planning. We would like to plan the tests for each sprint but still be able to easily keep track of all the tests of the current release. Finally we are going to have a look on how we can achieve a base-lining of test cases across multiple major releases.
Structure of a test plan
A team project may contain multiple test plans which itself contains test suites and test cases. The test suites are used to structure the test cases. like folders on a file system. There are three types of test suites. Besides the standard suite which arranges the test cases statically, the query based test suite and the requirements based test suite provide a dynamic result set based on the filter criteria. Since a dynamic result set of test cases is cumbersome to keep track of, we recommend to use the static test suites.
Test Plan Repository
We need somehow a repository which contains all test cases of a certain release. Since we only got Test Plan, Test Suites as structure elements, we will use the Test Plan for that purpose. In this repository test plan we will create a test suite structure to organize our test cases. Since test cases are work items, we can reference them from other Test Suites without duplicating them. We use this functionality to create a subset of the tests for a sprint. The structure will look as follows:
As you can see in the picture above, the sprint test plans have the same Test Suite structure and reference a subset of the available test cases for this particular sprint. So how to we get there using Microsoft Test Manager?
Let’s create a test plan called “repository” and add the test cases to it. If we develop new test cases during the sprints, the will added to the corresponding Test Suites.
Now let’s plan the first sprint. Therefore we will create a new Test Plan and reference the test cases which we are going to run during that sprint.
Now, we will add the test cases by reference to new newly created Test Plan.
Now we have the same Test Suite structure available. We are now going to remove all the unneeded test case. It only removes the reference from the Test Suite to the Test Case, the Test Case itself is not deleted.
Now we only have those test cases left in our test plan, which have been planned to be done in sprint 1.
Test Case base-lining across major releases
When creating a new major release of the software, we often have the situation that the test cases will change but we still need the old ones to be ready to be executed again. Think of changing the UI structure which will lead to a change in the test steps.Since the old version is still on the market, we need to do bug fixing the old version and therefore be able to re-run the tests again. Since the work item structure of TFS always provides the latest version of a work item, just modifying the test case in this case is not a good solution. We need to create a copy of the test case and then work on that clone for the next release.
Luckily there is a build in functionality in Microsoft Test Manager for that purpose.To do so, we open the repository test plan of version 1 and create a clone of it.
We now have a test plan which has the same test suite structure but the test cases are not referenced from version 1, they are cloned and referenced. This means that we are now working on a copy of them and the old test cases are still valid and remain unchanged for version 1.
The cloning functionality is also available from command line. If you need more information about this, please have a look here.
1
2
3
4
5
6
7
8
9
tcm suites
/clone /collection:http://tfs.<myserver>.com:8080/tfs/DefaultCollection
/teamproject:IceCream /destinationteamproject:<myproject> /clonerequirements /suiteid:123 /destinationsuiteid:456
/overridefield:"Iteration Path"="<myproject>\\sprint3"
/overridefield:"Area Path"="<myproject>\\catalog"