Use Enterprise Software Packaging to Test Software Packages

Use Your ESP to Test Software Packages
The Enterprise Software Packaging cycle helps you test your software packages thoroughly before introducing them into the production network.
by Danielle Ruest and Nelson Ruest

Posted September 29, 2003

For This Solution: Windows Network, Software Packaging Software

One of the most overlooked processes in software testing is deployment testing. Organizations which use Windows networks today have mostly moved to Windows Installer technology for software packaging and distribution. Despite the fact that Microsoft's Windows Installer service offers several features for self-healing and package stability, it is still important to perform complete testing of each package before deploying it into the production network, so that products don't conflict with each other when running on a user's workstation.

That is why it is crucial to include a complete testing and quality assurance program for software packaging, whether it be for commercial software or corporate applications that have been designed in-house.

All software has a lifecycle. It begins the moment the software development project is initiated by a manufacturer, and continues until the moment the software is retired from the marketplace. For user organizations, the lifecycle focuses more on when it is acquired, when it is deployed, how it is maintained and supported, and when it is retired from the network. In the case of corporate applications, it begins the moment corporate developers begin to work on the project, and ends when the product is retired from use (see Figure 1).

During its lifecycle, most software will require corrections. Manufacturers often call these "service packs" or "service releases," while corporations call them "updates." If an organization adopts a software product before these corrections are released, it will have to deploy them in addition to the deployment of the original product during that product's lifecycle. An organization must arm itself with comprehensive software maintenance processes and toolkits.

Enterprise Software Packaging (ESP)—the preparation of standard, structured automated installations for deployment within a specific corporate environment—plays a key role within the lifecycle because it takes charge of all the activities that are related to software package preparation and maintenance.

The ESP cycle must include all of the processes and additional steps required to ensure full testing and quality assurance (see Figure 2). This preparation cycle includes five activities: Request; Integration; Product Testing; Quality Assurance; and Release Management.

Request
A request for a new package is initiated as part of the overall software lifecycle for a product within the network. At any point in the process, the sponsor for the product—the person responsible for the evolution of the product within your network—may want to know the status of the request.

Integration
This is the first technical stage. It involves the initial creation and testing of the package. It includes the following activities:

Discovery. The first test is always an interactive discovery and analysis of a new product, especially its installation process. This phase serves to identify the elements of the technical architecture for the product and its customization and configuration requirements. It serves to create a detailed interactive installation checklist to be used in the next stage.
Initial Package Creation. Once the first stages of discovery have been performed, it is time to automate the installation or create the initial package. Depending on the software product, this stage will include either a setup capture or an import of a Windows Installer file within the packaging tool, and configure it according to corporate specifications. The result is an automated installation file, which is imported into the corporate software repository.

Product Testing
This phase focuses on testing the new automated installation. It covers three steps:

System Test. This test focuses on the evaluation of the automated, or "silent," installation. It is also called unit testing because it tests the installation by itself. This test is performed on a clean machine through a "pull" installation—launching the installation from a server share containing the new package.
Security Issue Identification. Are there any security issues with the product as installed during system tests? Are there modifications required to operate it with user rights?
Package Automation. Now that all of the package's components have been identified, it is time to finalize the package through the inclusion of scripts and other external components, and then automate the package for deployment. This refined package will serve to support the next battery of tests.

Quality Assurance
Once the initial package has been prepared, it can move to quality assurance testing. The phase includes:

Package Validation. Is the package valid? Is it well constructed? Does it conform to Windows recommended guidelines?
Functional Test. Does the product operate as expected once the installation is complete? Are security rights appropriate?
Conflict Management. The components of the package are integrated into the conflict management inventory database and conflict resolution is performed. It is also important to identify the product category at this stage. Will it be deployed to all systems or will it target only specific systems? This will identify the conflict testing strategy and indicate against which products conflict testing is required.
Integration Test. How does the product behave when merged with other products it must coexist with? This testing is greatly simplified by Conflict Management, since it tells you what you can expect in terms of coexistence.
Acceptance Test. Will the product sponsor (final client or user) approve the product as configured and installed?
Deployment Test. Is remote distribution of this product required? If so, a deployment test must be performed to ensure that it behaves as expected during remote installation.
Uninstall Test. If uninstallation is required, it should be tested both interactively and remotely.
Final Quality Assurance. Once all tests have been performed, a final quality assurance test should be performed. Is all documentation correct and complete? Have all testing procedures been followed correctly? These are some of the questions that must be answered during this phase before final release of the product to the corporate network.

Release Management
Once all testing is complete, the final package is released for distribution. It is inserted into the package repository and released to the software deployment process.

Each of these five testing phases is important. If, for any reason, a product fails at any testing stage, it must be rolled back to the previous stage, or even earlier stages, and corrections must be applied.

Use the 80/20 rule when preparing packages; that is, 80 percent package preparation and testing, and 20 percent package implementation. This means that software packaging must use a structured testing strategy. The more your packaging strategy resembles the activities included in the ESP cycle, the more your packages will reduce your support costs once they are deployed in your network.

Software packaging does not end with the release of the final package to the production network; it goes on to manage the package throughout its lifecycle in the network. This is why organizations should put an ESP environment in place.

Several market products support this type of environment (see Resources). You should take the time to review your needs and select the tool that is appropriate for you. Whichever tool you use, you should use the ESP cycle to ensure that you control software and application events within your corporate network. Following strict guidelines and rigorous testing procedures will make final packages more productive and will avoid most support issues. This is one of the major reasons for implementing an ESP strategy.

Note: Portions of this article were drawn from the authors' upcoming book: Enterprise Software Packaging Patterns and Practices, Packaging with Wise Package Studio.

About the Authors
Danielle Ruest and Nelson Ruest (MCSE) just released their third book, Windows Server 2003 Pocket Administrator (Osborne McGraw-Hill, 2003), an everyday administration reference. Their second book, Windows Server 2003, Best Practices for Enterprise Deployments (Osborne McGraw-Hill, 2003), is a step-by-step guide for designing enterprise networks with this new operating system. They are also authors of Preparing for .NET Enterprise Technologies (Addison-Wesley, 2001), a book on mastering change in the enterprise. Both work for Resolutions Enterprises (www.reso-net.com), a small Canadian consulting firm that provides services in the information architecture and change management fields. Both can be reached through infos@reso-net.com.