It is still a bit complicated, or better a bit confusing, how the different parts within Microsoft Test Manager are organized. This post is a try to clear things a bit [mostly for myself ]… please respond if I made a mistake!
On MSDN this image is shown to explain the organization of test artifacts, but this is a simplification, the reality is a bit more sophisticated and complex. For example test cases can exist in different suites, plans and even different team projects.
A different view…
And again, correct me if I’m wrong…
See image below; a project collection has multiple team projects and a team project only can live in one project collection. A test plan only exists in one team project, while team projects have multiple test plans and a test case belongs to a single team project, where team projects can have more test cases.
So far no problem… With test cases and test plans it gets confusing. When you read the diagram, a test case can live in different test plans from different team projects [within the project collection]. The proof is in the image below ”a test plan with test cases from multiple team projects”… you can accomplish this by adding excising test cases, just change the query.
The only reason why you want to add test cases from other team projects in our current test plan is when you want to check something from another application before you continue testing your project, maybe the availability of a service where you depend on.
Anyway, it can get a bit confusing… the other thing what you need to keep in mind, it isn’t a ‘deep’ copy of the test case when you copy-past test cases to other test plans, it is a link-copy, the ID stays the same..!
The relation and composition of test runs and test results is another dependency which can get confusing, specially when you have test cases linked to many different test plans and team projects. A test plan has test runs, every time you run a test case or a set of test cases a run is added to the test plan. For test cases which are executed in this test run a test result is collected [which information can be collected for bug reports].
So, we can have succeeding test runs with test cases which are failing in other test runs … We definitely need some more reporting to get some better understanding about that, a view in which test run [and test plan/ team project] a test case has run with which result for example.
I didn’t mention the relationship / linking you can create with other work item types, but I do think you can imaging it even can get more complex. The “Work Item Visualizer for TFS 2010” on Visual Studio Gallery is a great tool for clarifying this.