Developing

Figure 4 shows the activities that occur during the Developing Phase. During this phase, the Test feature team prepares for the testing done in the Stabilizing Phase by reviewing the BDD 2007 implementation architecture and documents. If possible, key Test feature team members must attend reference architecture and core team meetings to fully understand the direction of the solution’s technological development. In addition, this preview assists the team with preparing its test cases.

Figure 4. Activities during the Developing Phase

On This Page

Roles and Responsibilities
Create the Test Lab
Milestone: Test Labs Complete
Define Test Case Types
Milestone: Test Cases Complete

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Developing Phase of the initiative. Table 3 lists those roles and defines the focus areas for each role cluster.

For more information about MSF team role clusters, see Microsoft Solutions Framework at https://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Table 3. Roles and Responsibilities During the Developing Phase

Create the Test Lab

Effective testing requires creating a lab in which data can be assembled, stored, analyzed, tested, and manipulated in an isolated, secure environment. Establishing and maintaining a lab environment early in the project is key to the solution’s success. The lab shown in Figure 5 has the following basic characteristics:

• It is a permanent, dedicated space.

• It is isolated from the production corporate network and the Internet by firewalls.

• It has Internet access.

• It uses a common, 100-megabits-per-second (Mbps) switched Ethernet infrastructure.

• It provides common service components, such as:

  • Dynamic Host Configuration Protocol (DHCP).

  • Windows Internet Naming Service (WINS).

  • Domain Name System (DNS).

  • Microsoft Windows Deployment Services (Windows DS).

  • File share services.

  • Tape backups.

  • CD-ROM or DVD recorders.

  • Printers.

  • Optionally, a system and configuration management tool and an application monitoring tool.

Note These last two components, which the Infrastructure Remediation feature team identifies, depend on the scope of the BDD 2007 implementation.

• It provides a dedicated workspace for each feature team.

• It allows the production environment to be realistically simulated for services such as the Microsoft Active Directory® directory service.

• It contains the same target hardware found in the production environment. (This hardware can be limited to the actual computers targeted for deployment. There is no reason for the actual server hardware to be duplicated here so long as all the services provided in production are duplicated.)

  

  Figure 5. Sample test lab

Isolating network shares and providing specifically allocated workstation equipment creates an environment that enables each feature team to work independently when appropriate. However, because the feature teams share a common infrastructure of network, servers, and services, each team can easily collaborate with other feature teams when necessary without having to create redundant infrastructures or affect the production network. For example, the Application Management and the Application Compatibility feature teams can potentially share workspaces, because their tasks are related to the same applications. A common lab also facilitates more timely communication, because all the developers are in the same physical area. Because the life cycle of each feature team may be slightly different, the equipment assigned to each team workspace can be dynamically allocated based on needs.

The number of workstations required differs for each organization and for each feature team based on its size and complexity. A key consideration is that these teams are often expected to work in parallel. Therefore, having workspaces for each team helps reduce the confusion and wasted time that may occur while one team waits for another to finish using shared equipment.

For its test lab, a fictional company called Woodgrove Bank chose to use two types of servers:

• Lab server. The lab server is a computer placed in a workgroup. This computer holds the BDD 2007 package files. A typical server has several hundred gigabytes (GB) of disk space to hold the files that the various teams require. Additional space is required to host the simulated production servers.

• Simulated production servers. The simulated production servers (which can be VMs) are similar to those in the production environment, so developers can test on a test network that matches the production environment, including such items as directory designs, policies, and security permissions. The entire lab is isolated from the production network to avoid collision of its services with the production servers.

Note The lab need not use the same domain names used in production. Identical domain names are not a required component of the testing strategy, but identical forest structures are.

Build the Test Lab

Test lab construction includes several activities: base server installation; creation of the file servers; installation of the VM software; and creation of the VMs that simulate production servers. Several of these activities are manual, but many can be automated. For example, after creating the base VM, team members can use scripts to generate the various VMs required to reproduce the production services.

The Infrastructure Remediation feature team is responsible for the initial setup of the test lab. After setup is complete, the Test feature team moves to the finalization of the lab. During the Developing Phase, the Test feature team finalizes the test lab, which includes installing all software and test tools as well as bug tracking and reporting software.

For example, in testing this solution, the Woodgrove Test feature team made extensive use of virtual server technology. Doing so reduced the physical size of the lab by consolidating a large number of servers on a small number of computers and, in some cases, on the same computer. In fact, the Microsoft BDD 2007 Test feature team used only two physical servers to host approximately 25 VMs.

As a rule for testing, each VM is allotted 512 megabytes (MB) of dedicated random access memory (RAM). In some cases, where the virtual server is expected to host several memory-intensive services, this amount can be increased appropriately.

In addition to housing servers and client computers on which deployment is carried out, the test lab environment also requires a great deal of storage space. The Test feature team must plan for storage space, keeping in mind the following requirements:

• Space for storing the BDD 2007 component files

• Space for the volume-license media

• Space for source files for various application software media

• Space for the images built during testing

• Space for backing up virtual hard disks (at a minimum, space for three sets of virtual server environment backups must be available: one for golden baseline, one for temporary backup, and one for a fully configured environment)

Depending on the scope of the BDD 2007 implementation, a considerable amount of disk space may be needed to satisfy the requirements mentioned above. On average, a minimum of 200 GB of space is required, but this number is affected by the number of disk images, VMs, and application packages the BDD 2007 project includes.

A staging area that hosts all the source files needed for configuring the VM must be set up on a host computer that all the VMs requiring access can reach. Design the test lab in a way that allows testing as much of the proposed logical and physical production environment as possible—including computer hardware, network topology, wide area network (WAN) connections, domain architecture, services, databases, business applications, administrative tools, security model, application deployment methodology, and network server storage methods.

Design the client computer portion of the test lab to test the same functions and features currently in use or planned for use in the production environment. Include the same types of hardware, applications, and network configurations.

For more information about finalizing the test lab, see “Appendix: Finalize the Test Lab.”

Note When complete, the lab should be fully tested on its own to ensure that it does indeed reproduce the production environment and that it will support testing of the entire BDD 2007 implementation, including image and software deployment.

Milestone: Test Labs Complete

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide. At this milestone, shown in Table 4, the test lab is in place and ready to accommodate testing.

Table 4. Deliverables

Define Test Case Types

A test case is a detailed procedure that fully tests a feature or an aspect of a feature. Whereas the test plan describes what to test, a test case describes how to perform a particular test. Develop a test case for each test listed in the test plan.

A test case includes:

• The purpose of the test.

• Special hardware requirements, such as a modem.

• Special software requirements, such as a development or user state migration tool.

• Specific setup or configuration requirements.

• A description of how to perform the test.

• The expected results or success criteria for the test.

Test cases must be written by a team member who understands the function or technology being tested, and each test case must be submitted for peer review.

Organizations take a variety of approaches to documenting test cases, ranging from developing detailed, recipe-like steps to writing general descriptions. In detailed test cases, the steps describe exactly how to perform the test. In descriptive test cases, the tester decides at the time of the test how to perform the test and what data to use. Most organizations prefer detailed test cases, because it is usually easier to identify pass or fail criteria and to reproduce this type of case.

Develop Test Scenarios

Developing the test scenarios is crucial to successful validation of the BDD 2007 implementation. In addition, the test scenarios form the basis of the test cases the team develops.

The BDD 2007 build process documentation helps determine the test scenarios and test cases the Test feature team develops. Typically, this documentation is ready to be released at the end of the Developing Phase; however, it is recommended that the Test feature team not wait to prepare the test scenarios. The team can also base the scenarios on the functional specification and the BDD 2007 guides. If the project’s functional specification is not available in the early stages of the project, the Test feature team can begin with the sample specifications in BDD 2007.

One of the advantages of basing high-level test case design on the functional specification document is that doing so exposes the functional specification document to critical interpretation from an entirely different perspective—the test perspective. Accordingly, when the Test feature team prepares the high-level test cases and works with developers to review and obtain their sign-off, differences in interpretation are revealed. These differences not only help the test engineers better understand the purpose of various elements of the functional specification but also give the developers an opportunity to reevaluate the purpose of other elements.

In the context of a BDD 2007 project, the following high-level scenarios were the most relevant for determining a valid solution design:

• Lite Touch Installation (LTI) deployment

• Zero Touch Installation (ZTI) deployment

• Zero Touch Reporting

• ZTI Administration Database

Develop Test Cases

To prepare relevant test cases, team members must first review all deliverables from the various feature teams. The test cases must address each high-level scenario identified in the Developing Phase. At this stage, the Test feature team may still introduce new scenarios; however, doing so is not recommended because of the risk presented to the Test feature team’s schedule. (If some Test feature team members participated in the development of the solution or worked with the developers early on to understand the solution design, the team is now well positioned for developing test cases for project.) These test cases are documented in the Test Cases Workbook. See the workbook provided with BDD 2007 for the detailed test cases that the BDD 2007 Test feature team at Microsoft developed and tested against the solution.

The following detailed description of the test scenarios listed in the section “Develop Test Scenarios” is based on the various activities addressed in the Computer Imaging Systems Feature Team Guide, Deployment Feature Team Guide, Lite Touch Installation Guide, and Zero Touch Installation Guide:

• LTI deployment:

  • BitLocker™ Drive Encryption

  • Build server setup and configuration

  • Core application installation

  • Data migration

  • Image capture CD creation

  • Language pack installation

  • Locale and time zone configuration

  • Master image creation

  • New computer scenario

  • Operating system deployment

  • Post-deployment configuration

  • Refresh computer scenario

  • Removable media, such as DVD

  • Replace computer scenario

  • Security update

  • Solution installation

  • Testing the usage of the customsetting.ini file

  • Upgrade computer scenario

  • Using Microsoft Operations Manager (MOM) 2005 for monitoring

  • Windows DS preparation

• ZTI deployment:

  • Application compatibility

  • Build server setup and configuration

  • Core application installation

  • Data migration

  • Deployment to VMs

  • Image capture CD creation

  • Image deploy CD creation

  • Language pack installation

  • Master image creation

  • MOM 2005 preparation

  • Monitoring

  • New computer scenario

  • Operating system deployment

  • Post-deployment configuration

  • Pre-operating system deployment tasks

  • Refresh computer scenario

  • Replace computer scenario

  • SMS Operating System Deployment (OSD) Feature Pack–based capture

  • SMS package execution

  • SMS 2003 preparation

  • Solution installation

  • Testing the usage of custom settings in the customsettings.ini file

  • Upgrade computer scenario

  • Windows DS preparation

• Zero Touch Reporting:

  • Baseline attributes

  • Data source configuration

  • Migration of user state data

  • Reporting operations

  • Security testing to ensure user access rights are ensured

  • Testing the reporting user interface (UI) functionality

• ZTI Administration Database:

  • Configuring the database graphical user interface (GUI)

  • Installation of a new database

  • Using a preexisting database

  • Using the .csv file

  • Using the database GUI

Test Case Review

When prepared, the test cases must be reviewed by the respective feature teams, whose input is valuable in the proper preparation of test cases.

Milestone: Test Cases Complete

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide. The deliverables for this milestone are shown in Table 5.

Table 5. Deliverables

Download

Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions