Building a Windows 2000 Test Lab

Previous Topic Next Topic

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.

Testing Methodology

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:

Resources Required

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:

For more information about planning for application compatibility testing, see "Testing Applications for Compatibility with Windows 2000" in this book.

Risks

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.

Schedule

Draft a schedule that includes each test you listed in the test plan. The schedule can help you coordinate lab use with other subteams.

© 1985-2000 Microsoft Corporation. All rights reserved.