Developing a Lab Strategy and Methodology
Setting up a lab and testing Active Directory needs to be completed before production implementation. Developing a lab strategy and methodology needs to be undertaken, even before a lab can be configured. If your organization is relatively advanced in quality assurance programs, you might already have a lab strategy in place that you can utilize for Active Directory testing. If so, you are fortunate. Most organizations, no matter how advanced, do not have a comprehensive testing strategy that is employed on a regular basis.
Developing an Operational Acceptance Test Plan
One of the first goals of you should set as you begin establishing your lab is to put together a set of parameters concerning what you are testing in the lab. Typically, the results of the lab testing are presented to an operations group within your organization that accepts operational responsibility for the Windows 2000 network environment and Active Directory after it is implemented. Consequently, one of the best ways to establish a set of test parameters is to develop an Operations Acceptance Test (OAT) plan.
The OAT is fundamentally a negotiated contract between the team who is building and testing the Active Directory design and the operations group who administers the environment. The goal of the OAT is to establish a set of tests, which, if completed successfully, facilitate the implementation of the design in to production. Consequently, the plan should include testing for all the aspects of the plan with which the operations group is concerned.
To begin establishing your OAT, identify the following:
Functionality to be tested
Test parameters for each aspect of functionality
Results expected from each test
When identifying the functionality to be tested, it is important to consider every aspect of the product. You are establishing a test plan for Active Directory, but Active Directory is directly impacted by the performance of the Windows 2000 network environment. Consequently, there might be aspects of Windows 2000 that also need to be tested. After you have identified the functionality to be tested, you need to build a test matrix.
Developing the Test Matrix
The test matrix should include an explanation of the functionality to be tested, how it will be tested, and what the expected result is. In addition, it should also include the business reason driving the need for the functionality. This is an extremely important aspect to consider during the OAT process. If there is no business reason to implement a specific aspect of the product, you will be hard pressed to justify the testing, design, and implementation of that aspect to business management. For example, you might decide that you want to test the integration of a public key infrastructure (PKI) with Active Directory. However, there might be no business reason for implementing PKI in your organization. There is no reason to conduct tests on functionality you won't be using. The converse is also true. You need to be sure to identify all business requirements for implementing a networking system and directory service and to map Windows 2000 and Active Directory functionality to the business. This makes it easier to justify the implementation of the product to the business management in your organization. After you have compiled the business justification for the functionality to be tested, it is time put together the test matrix. An example is shown in Table 21.1.
| Functionality | Business Driver | How to Be Tested | Expected Result | Result | Flag |
|---|---|---|---|---|---|
| Logon Authentication | Logon is required for access to environment. | Logon is performed from machines configured in the test environment. | Logon functions within acceptable parameters: Authentication takes no more than 5 seconds. | Logon took 4.5 seconds. | Green |
| Directory Search | Searching Active Directory for objects is required for integrating directory with the line of business (LOB) applications. | Populate the directory with 50,000 objects and perform a search for a single object. | Search for a single object should take no more than 5 seconds to find a single object in a 50,000 object directory. | Search for a single object in the directory took 8 seconds. | Yellow |
| Dynamic registration with DNS | Dynamic registration with domain name system (DNS) during the DHCP Dynamic Host Configuration Protocol (DHCP) configuration process reduces the overall total cost of administration. | Start up a workstation configured for DHCP and verify that dynamic DNS (DDNS) registration occurs. | During the startup process, the workstation automatically registers with the DNS server. | During the startup process, the workstation did not register with the DDNS server. | Red |
In Table 21.1, three different flag types are listed. First, the logon test is performed, and the result is within the acceptable parameters for the test. No further action needs to be taken.
The second test, testing the search time for Active Directory, is completed, but it does not meet the acceptable results expected. However, the result is not severe enough to warrant a red flag. A yellow flag is set for the test. A yellow flag might or might not require further action. Depending on the acceptable variance in the test, action might be required.
The result of the third test in the example is more significant. The DDNS registration test results in a red flag. The client was unable to register with the DDNS server. If a red flag is registered during lab testing, it is critical that a path to resolution be established. In the preceding example, if the workstation is not able to register with the DDNS, it is not be able to properly function in the Windows 2000 environment. When establishing a path for resolution, remember to identify the following:
Next steps for resolution
Timeline for resolution
Action to be taken if the issue cannot be resolved
Lab team member responsible for the issue's resolution