Creating the Test Plan
Early in your Windows 2000 planning, each design subteam should write a test plan that describes how they will test their specific technology. For example, the networking team might write a test plan that describes how they will test networking features. All members of the subteam should review and approve the test plan before testing begins. From the test plan, test cases (or scenarios) are developed to describe how to test each feature or function. Test cases are described in more detail in the section "Designing Test Cases" later in this chapter.
The test plan applies to both unit and integration testing. It provides the big picture for the testing effort and should address the topics that follow.
Scope and Objectives
In this section of the test plan, describe what you will and will not cover in your testing. For example, you might limit your testing of client computer hardware to the minimum supported configurations or the standard configurations.
Describe what you want your testing to accomplish. For example, one organization had an objective of migrating the Windows NT 4.0 environment to Windows 2000, component by component, keeping the access control lists (ACLs) and Exchange permissions intact. Another organization had an objective to measure network traffic and observe server performance during specific directory service tasks.
Describe the general strategy you will use for your testing. For example, your strategy for testing schema changes might be to configure an isolated domain in the lab where schema changes can be applied without affecting other lab tests. This section of the test plan might include the following descriptions:
Domain architecture used for the test
Tools and techniques used to conduct the tests or to measure results
Automated techniques used for tests
Itemize the following types of resources that you require to support testing:
Hardware For example, identify the standard configurations you plan to support for client computers. Include components such as video cards, modems, and external drives.
Software For example, include Microsoft® BackOffice® or other server-based products that you need to test.
Databases Include databases that you need to set up for testing applications. It is recommended that you include a description of resources, such as personnel and production data, that you need to populate the databases.
Personnel Describe the number of testers you need and the skill level you require. Include consultants and other support personnel.
Training Specify the Windows 2000 training that your testers need to understand the technology they are testing.
Tools For example, include link simulators for testing WAN links if you do not have a second lab you can use for this purpose. Include any tools you need to automate testing and to track test results.
Features and Functions
Include a list of all the features or aspects of features to be tested. This is a list of what to test, not how to test. Some organizations include a list of tests as an appendix to their test plan. Other organizations create a separate document, or test specification, that lists the tests and briefly describes what each test must cover. Still other organizations include the list of tests as tasks in their project schedule.
The following is an example from one organization's test specification:
Test 1 — Trust retention
Description: all trusts to and from a domain should be retained when the domain controllers are upgraded to Windows 2000. Use the Domain Tree Manager to view the trusts. If the trusts do not appear, then the test failed.
Note that the description does not include instructions on how to perform the test.
Later in the project, team members develop detailed procedures that describe how to perform each test listed in the test plan. The section "Designing Test Cases" later in this chapter provides more information about developing test procedures.
Your test plan should address the following types of tests:
The functionality of each feature and service you will implement.
Interoperability with existing components and systems in the production environment, both during and following a phased rollout. These tests include the mixed environment that will occur during your phased rollout and the Windows 2000 environment after the completion of your rollout.
Hardware and driver compatibility for every type of computer that will run on Windows 2000.
Application compatibility for every application that will run on Windows 2000.
Baselines and stress tests for capacity planning.
Baselines for performance monitoring.
Optimization of configurations, such as for standardized desktops on client computers.
Procedures for deployment and post-deployment administration, such as upgrading a client computer and back-out plans.
Tools and utilities.
For more information about planning for application compatibility testing, see "Testing Applications for Compatibility with Windows 2000" in this book.
Describe the known risks that could prevent successful testing. For example, the test lab might be behind schedule, hardware or software might be unavailable, or testers might be working on other projects or need additional training.
Draft a schedule that includes each test you listed in the test plan. The schedule can help you coordinate lab use with other subteams.