Lesson 4: The Testing Phase | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

This lesson focuses on setting up and designing a test program and using it in the migration.

After this lesson, you will be able to

Understand the importance of the test program.
Learn how to set up a test lab.
Determine the phases of the migration that can be tested in the lab.

Estimated lesson time: 30 minutes

Setting up a Test Facility

The test facility will allow you to refine your knowledge of Windows 2000 as it applies to your migration project, to test the behavior and performance of the systems you're building, and whether existing systems will migrate to Windows 2000.

Documenting the Test Program

The test program is really a project within the migration project. You need proper project documentation to describe the following:

Test program phases. The first phase of the test program is to create the current systems and their environment. As the migration continues, other issues must be considered, such as application testing, performance testing, and training. Each of these should be fitted into the test program timetable and be documented within the project.
Test program deliverables. A number of the test activities will have deliverables associated with them; for example, performance testing will be required to prove that the planned solution can deliver in various areas. The experience of managing and configuring the test environment should generate documentation.
Test program involvement. At different phases of the test project, you'll need to involve various members of the organization to ensure that the correct programs and hardware for their department are being properly evaluated. You might need to involve distant live sites in the testing process and consult with representatives from these sites as you plan the testing.
Test program review procedures. The test program will require continuous review as it progresses and as tests succeed or fail. Therefore, the review points and procedures should be a documented part of the project.
Test program road map. As with the migration project itself, you'll need to design the phases of the test program and set deliverables for each phase. You can then map these into the migration project.

Designing the Test Lab

The systems in the test facility should be configured and connected in the same way as for the target environment. The same network protocols, domain arrangements, and network topologies should be present in the test lab as in the host organization. The hardware platforms should, of course, be the same as the intended platforms, and the test network must be isolated from the production network to avoid conflicts between systems on each.

If the migration involves the upgrade of systems, the test program should include the upgrade process as well as a finished environment. The test environment should contain a representative worst case subset of the planned final system so that you can test the critical features of the final deployment.

During the later phases of the project, you'll need to test the user applications. At this point, the users must become involved with the test lab and provide input to the process.

Using the Test Program

At planned points in the program, you should test the lab systems against specific requirements. The tests should have definite pass/fail criteria, and they should be prioritized and reproducible. You might want to monitor performance at several levels, such as monitoring background traffic when users log on at the start of the day and at times of peak activity. The tests should be packaged as a number of test cases.

Each test scenario should contain the following information:

Goal. The reason the test is being performed or the issue the test is to resolve. Goals include the testing of interoperability (will a number of systems work together to deliver the required functionality?), performance (is the response of the system acceptable under particular loading conditions?), or capacity (can the system support a given number of transactions or store a particular number of items?).
Hardware and software requirements. The details of the configuration to be used for the test, including any network connections needed for communication.
Testing procedure. The steps to be performed to implement the test. Sometimes the requirement will be testing a procedure itself, for example, successfully upgrading a server. In other situations, the test might involve creating a given set of conditions.
Criteria for success/failure. The means by which the test will be judged to have succeeded or failed. The criteria must be clear and driven by specific requirements, such as "a user logon has been completed within 45 seconds" or "a throughput of 50-transactions-per-second has been achieved."

So that the results are meaningful, you might need to recreate a specific model of activity or involve end users in the testing process. Automated simulations are useful here, if a given set of tests need to be applied to verify a design change, but you must have confidence in the accuracy of the simulation.

TIP
While you might not be able to automate the test, it's useful to create scripts to automate setting up, analyzing, and tearing down the test systems. These scripts will enable you to quickly recreate clean test environments.

You might not have the time or resources to spend on testing every aspect of each application, and in a given situation some issues will be more important than others. Be careful of the paralysis of analysis syndrome and prioritize for mission-critical issues to be tested first. You should create tests for worst-case scenarios, for example, on the slowest network link or under the heaviest loading conditions with the least powerful systems. The test results should feed directly back into the test design and then to the overall project.

In the early stages, you'll be testing to validate your design of the overall system. Later, you'll be making sure that all the components can work together. Note that this testing will include the end-user applications (and possibly the users themselves).

Be careful when extrapolating performance figures gathered from testing. Assuming that a given installation can handle twice as much activity but at half the response time is dangerous. Another common assumption is that the client logon and initialization will require only about 95 KB. This figure can be easily doubled if you consider the size of the logon scripts and roaming user profiles, and the number of policies on the site, domain, and OUs. Similarly, if you monitor a logoff, you might find that it could easily use up to 400 KB because of user profile updates instead of the 1 KB quoted.

Introducing a Sample Test Plan

When problems arise, have a procedure for dealing with them and directing them to the appropriate specialist. Formally review the tests at planned points so that you can modify any decisions in light of the results.

The sample design that follows outlines the essential phases to be followed during a test project.

Create the Test Environment

Create the test laboratory for the initial testing. This phase is also useful to gather experience installing and configuring Windows 2000 and to document this process. By the end, you'll have a set of working systems that in some way reflect the intended configuration.

Schedule Applications and Systems for Testing

Once the test environment is stable and configured appropriately, you should collect all mission-critical applications from the user base and test them to meet specific goals.

Begin the Pilot Test Phase

The pilot test phase uses a small group of users to validate the results from the testing program. It is best if the chosen group is least affected by any major disasters, and that a rollback procedure is in place prior to performing the pilot migration. Therefore, in many environments, the first test group is one of the support teams.

At the end of this phase, you should have a working pilot configuration that's now connected to your production network and a set of documents that describe how to recreate this configuration and any issues met. You must be careful with the Windows 2000 pilot phase, because its design could have permanent consequences on the layout and structure of the final migrated network. For example, if you intend to keep the pilot environment as part of the migrated network, you might wish to install a root-level domain prior to rolling out the pilot. Otherwise, this pilot will become the forest root and can't be undone other than by reinstalling it. Another issue is that if a substantial number of mistakes were made in the pilot, you will not want to incorporate these into your final production.

Perform Extended Integration Testing

Once the pilot test environment is correctly connected to the production network, you can create and deploy additional environments across the WAN (if one is present). You can configure and test the DNS and Active Directory namespaces with respect to resource access, replication traffic, and client authentication.

At the end of this phase, you should have a documented set of DNS and Active Directory configurations, test results, and configurations for the client systems.

Perform Limited Pilot Testing

At this point, you can begin to involve the users in the pilot program. You can connect a limited number of clients to the pilot installation and begin to test any outstanding application compatibility issues in a live environment. For this to be possible, you must have a working security environment for the new user community as well as all the other services that will be required to allow them to fully test all the applications. The users should also be involved in specifying the range and functionality of the applications to be evaluated.

At the end of this phase, you should have the test results from the application compatibility testing, the system configuration details, and a checklist of applications and functionality identified by the users in the pilot program.

Perform Extended Pilot Testing

During this phase, a larger population of users is exposed to the pilot installation and the full range of applications is tested. At this point, a number of existing servers will be upgraded to support the larger pilot program and to build experience in the upgrade process.

At the end of this phase, you should have results from all the application compatibility tests and a fully tested set of migration procedures. You can use these to build the migration plan for the entire project.

Once the pilot program is completed, you should have been exposed to all the issues that will be present in the actual migration process. The program should give you confidence that the migration will succeed.

NOTE
One other deliverable of the pilot program should be a large number of migration evangelists—the users who took part in the program. The pilot should be structured so that their input is highly valued and is responded to efficiently. If involvement in the pilot means additional work or disruption, you should reward users appropriately.

Lesson Summary

In this lesson, you learned about the importance of the testing program and its phases. This sets the scene for the migration project and also generates documentation and procedures that will drive it. You also learned about the importance of involving users in the pilot program and using their input to drive policy.