You’ve probably noticed that for the most part, managing multiple test plans and test cases are more convenient when they’re part of the same Team Project in TFS/VSO. For one thing, area paths and iteration paths just work much more cleanly.
If you’re working across multiple Team Projects, though, the story changes slightly. Things can still work just fine, but you need to be even more aware of the differences between working with existing test cases, and copying them.
Let’s look at the differences.
When adding test cases that exist in another TFS/VSO Project entirely (not just another test plan in the same project), you are basically creating a reference back to the main test case, not a copy. That is, you can’t modify the area or iteration fields to represent the target project. Because it is a reference, when the test case is opened it is opened as it resides in the source test plan/project. You can’t modify the area or iteration fields because they are scoped to the project in which the test case resides.
Consider this example:
I have two projects: Project A and Project B. I created a test plan in Project A called “Master Test Plan”, and inside that plan created a test case named “Test Case from Master Test Plan in Project A” (just to make it easy to reference). It has an ID of 13.
In Project B, I create a test plan named “Project B Test Plan”. In this plan, I want to reference the test case from Project A. So I select “Add existing” from the toolbar, and query VSO for the test case.
I select the test case and click “Add test cases”, which adds it to my plan in Project B, as seen below:
If I open the test case, I am only able to set the iteration path (and the area path for that matter) to a value that is within the scope of the plan which we referenced.
Because we are referencing the test case, any changes made here will be reflected back in the Master Test Plan in Project A. This is because we are working with a single instance of the test case, we’re just referencing it from a different location.
If you wish to have a discrete copy of a test case, test cases, or test suites across projects (to a test plan that resides in a different project), you can perform a “clone” across projects via the command line (tcm.exe).
The TCM tool contains various options to control what gets copied, and new values to set (i.e. area and iteration). (It can also be used to run automated tests)
For this example, I’ll copy/clone my test cases (in the root test suite) of Project A to a newly-created project, Project C (in which I have a test plane named “Project C Test Plan”). Since this is a basic example, all that exists is that single test case.
Here is the command line I will run:
tcm suites /clone /collection:https://<myVSO>.visualstudio.com/DefaultCollection /teamproject:”Project A” /suiteid:1 /destinationteamproject:”Project C” /destinationsuiteid:3 /overridefield:”IterationPath”=”Project C\Release 1\Sprint 1” /overridefield:”Area Path”=”Project C”
tcm suites /clone
/overridefield:”IterationPath”=”Project C\Release 1\Sprint 1”
/overridefield:”Area Path”=”Project C”
When I execute this for the current scenario, I’m telling the tool to copy the test suite (with ID: 1, the root test suite in my “Master Test Plan”) from Project A to Project C (to the suite with ID: 3, the root test suite in Project C’s test plan (named “Project C Test Plan”)). I’m also instructing to the tool to set the Iteration Path of the copied test cases to “Project C\Release 1\Sprint 1”, and the Area Path to “Project C”.
After running this, if I look at my test plan in Project C, I see this:
I can see the copied test suite (“Master Test Plan”), and the test case it contains. If I open that test case, note the new values of Area and Iteration:
Also note the new ID (14) as a sign that this is an actual copy of the original test case (ID 13).
Because I’ve actually made a copy of this test case (not a reference, as in the first scenario), any changes I make to this test case will NOT affect the original from Project A. To illustrate this, I modified the title of the test case in (Project C) to reflect that it has been changed in Project C. Compare that change (top) with the original test case back in Project A (bottom):
To help with reference, the command line tool created a link between the two so users can see where the test case came from, and gain context as to why it’s there.
Thanks for reading!