Testing Hardware

After the lab environment is in place, it is time to begin testing hardware. The first step is to populate the OAT plan with the functionality to be tested, the method by which it will be tested, and the desired test results. To do this, identify each separate piece of equipment from the inventory documentation and document the functionality that will be affected by the implementation of Active Directory. With a router, for example, you should identify the following:

• Is the router RFC compliant? If so, test the DHCP relay functionality.

• Does the router support Quality of Service (QoS) networking? If so, test QoS functionality and service.

• Can the router be managed remotely? If so, test the management of the router by using the MMC and any associated MMC snap-ins provided by the vendor.

In addition to developing the test matrix for each individual network component, it is important to test functionality across components. This means verifying that the functionality that impacts multiple components on the network will not adversely affect any single component in the system. With the example of the routers, it is important to test that the router relays DHCP requests, and that it works properly with the DHCP server serving the DHCP requests from the DHCP scope.

Finally, as you populate the OAT, be sure to identify the expected results of each test. Identifying expected results for each functional aspect should be completed in the larger context of the entire system. For example, it is expected that all routers relay DHCP requests on to the DHCP server. It is also expected that they relay DHCP responses back to the client. In addition, it is expected that there is no undue load placed on the router or the network. All this should be documented in the Expected Results section of the OAT matrix. It is easy to see how the OAT can quickly become an extensive and critical document in the test process.

After you have completed populating the OAT for hardware, you can begin testing. Start by testing the underlying system functionality and progress to testing system-wide functionality.