Planning Your Testing

Common Scenarios

This section covers some common scenarios and how you can handle them from a planning and tracking perspective.

Scheduling and Tracking Test Case Creation and Execution Before everyone on the team rushes to write features and write Test Cases, you need a plan for how to manage and track this work. Out-of-the-box, you can notice that the Test Case work item type (regardless of whether you use

65

Common Scenarios

activity can be captured in a Microsoft Project WBS. Second, the project man- ager has the option to schedule the Test Case for creation and for execution separately. When doing it this way, the Assigned To field would be the person creating it in the first case and executing it in the second case. You do not need to use the Assign To Tester functionality unless testing on multiple configu- rations. This enables the project manager to track the time discretely for each activity; however, you may not want to assign a task to execute a Test Case. This is quite difficult for a tester to realistically keep track of. The task would

be associated with the Test Case and not the test run, which makes reporting even more difficult. The Parent/Child relationship between the Task and Test Case is not nec- essary. It provides some additional structure and enables the Test Cases to show up in a tree query (as opposed to a directed links query) but does not

66 Chapter 3: Planning Your Te sting process, Test Cases need to be “migrated.” For example, if you create a series

of Test Cases (Test A, Test B, Test C) for code on feature branch F1 and that code is merged to Dev and then back down to feature branch F2, those Test Cases may need to be executed against the code in branch F2. How do you keep track of it?

The recommended solution is to create one Test Plan per feature branch. Because you can copy suites between Test Plans, this becomes relatively sim- ple. Figure 3-20 shows the Copy Suites screen.

67

Common Scenarios

Moving from One Iteration to Another When you move from iteration to iteration, you need to deal with a number of issues. Some of these include uncompleted Test Cases, and in others the Test Cases were completed but never executed. Do you simply “copy” them from one suite to another, which creates a reference, or do you duplicate the Test Cases? This depends on how you want to report on them.

If you have a Test Case with the area set as Iteration 1 but then you copy the suite that it is part of to another Test Plan, which is testing Iteration 2, you have a problem. Because a suite copy is actually a “reference,” the Test Case continues to show up in Iteration 1—not Iteration 2. This can significantly skew your reporting depending on how you report on it. On the other hand, creating actual copies of the Test Cases adds to the “number” of Test Cases, even though this number doesn’t change.

68 Chapter 3: Planning Your Te sting executed against the current release. In this way it acts almost as a branching

mechanism for your Test Cases and enables you to preserve the Test Cases executed against a release. This may be handy for auditing purposes.

The advice for this issue is “It depends on what you’re trying to do.” There are no “best practices” because everything is dependent on your situation. Just be aware of what can happen in the various scenarios, and think it through before developing your plan.

Handling Different Test Configurations As previously mentioned you can use configurations as metadata for report-

ing purposes and to cut down on the number of Test Cases that you need to maintain. But does it always make sense to do this? The answer is no. No tools can easily solve this problem, so it takes some planning. First, you need

Summar y

SUMMARY In this chapter, you learned about Test Plan components and how to create

them. You learned the relationships between all the different test containers and about the goals of different stages of testing: analysis, construction, and user acceptance testing. This chapter also showed you how to create different testing configurations and their effects on Test Cases. You learned how to start managing a Test Plan by assigning testing configurations and testers to different Test Cases and configuration combinations. Most important, you explored a number of different scenarios that require you to think about the structure of your testing environment and common problems to these sce- narios. In the next chapter, you learn how to execute tests using Microsoft Test Manager.

This page intentionally left blank