| Article Index |
|---|
| Testing the installation process of a software |
| Page 2 |
| All Pages |
What is Install?
Installs often consists of multiple components including files, folders, dynamic link libraries (DLLs), registry settings, Web services,and Windows services. Dozens, if not hundreds, of different file types can be installed. Some files are executables with their supporting DLLs. Others, such as .cab files (cabinet files are compressed files used during Microsoft Windows installs), are copied onto the PC and then used to complete the install process. Help and documentation files often include compressed XML, HTML, and .pdf files.
Install Inventory
The install inventory is a list that identifies all the components of the install. This inventory might include the added files and folders and identify all registry keys added or changed. When you know the components of an install, it should suggest to you the types of install defects you might find. For example, if an install includes Microsoft Foundation Class (MFC) DLLs, then you should know a DLL conflict may occur. If an install includes .cab or other compressed files, then you should think about testing for sufficient hard drive space. To expose space issues on installs, check available space before the install or intentionally use a PC with limited space to see what happens when the compressed files attempt to unpackage. You should want to know everything the install will alter on a PC; the install inventory helps satisfy that curiosity. The more you know about the install and document in the inventory, the more ideas you will have for finding defects.
An install inventory is like a list of ingredients. Figure 1 shows an install report captured using Inctrl5, an install utility application designed to track changes due to an install. A basic inventory contains a list of the files fromthe install. A more robust inventory specifies the file date and version details of each file. Sometimes applications are dependent on external resources.These dependencies should be identified in the install inventory as well. For example, while testing an application that required specific DLLs from the MFC Library. If these DLLs were already on the PC, copies from the CD were not installed. If they were not on the PC, the DLLs were installed. Similarly, while testing the install of many applications that are dependent on the Visual Basic (VB) environment, it is often found that many of these applications will install the necessary VB files in the same directory as the application. In these cases, it appears the install doesnt check whether the VB runtime environment is on the workstation but instead adds the required files in the application folder. By knowing the state of the PC prior to the install, you could know if you should expect to see the DLLs installed or not. By knowing the version of the DLLs on the test PC before the install, you also know if you should expect to see the DLL updated or not. This is an example of the conditional coding programmed into an install. If the DLL should be replaced or updated by the install, knowing the install has conditional code to check the DLL version is helpful.
| < Prev | Next > |
|---|
