What
Testing concerned with the installation procedures for the system.
BS 7925-1.British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST)

Why?
   1) To find faults
   2) Give credible information about the state of the component, on which business decisions can be taken.

In the wider sense, installation is the very first thing the customer will do. Any faults found here will immediately give the wrong impression about the product.

There are two related areas are documentation testing and Conversion testing.

Installability to Me, means ensuring that everything the customer does, runs smoothly. This runs from taking delivery of the code and other artifacts through to the end-users being able to log on.

Who?
My belief is that Installability testing should be done with as much independence as possible. Additionally the testers should be as close as possible to the customer. Ideally I would want someone from Support or an implementor to test. Otherwise, if independence from development is lost, workarounds and inside knowledge will not expose bugs.

Customers may even take part, if they are in a beta testing programme.

Where?
Usually at the developers site. However, it might even be done outside by the customers site.

When?
Although Installability probably is fairly high up on the V Model, this does not mean that testing has to start late in the lifecycle.

As soon as the organisation is able, it should be reviewing or inspecting the documentation that is to be sent with the product. This might include installation guides, manuals and deliverables. Typos and other simple faults will be trapped by this process.

The install shield procedures and other processes (such as unpacking a .tar file) can be tested long before release. If the installation is considered to be high risk the central processes might be tested early on in the cycle.

How?

Both manual and automated testing can be conducted. The more mundane and repeatable elements of the process are candidates for automation. Manual testers can then concentrate on the more complex elements.

As with all testing, expected outcomes should be compared with the actual outcome. The expected outcome should be derived from a requirement. Ideally this would be explicitly declared. In many cases they are only implied.

Each test case should have the following:

   The start / entry state
   The requirement which is to be tested.
   Actions and inputs
   The expected outcome

The test case outlined above is very concise. However if many organisations are beta-testing, then many more scenarios, not necesarrily specified will be tested. An important issue is that of complexity of the environments into which the software is to be installed.

For example compare a specialist piece of medical software and a release of office. The medical software, will likely be installed into an environment that is highly regulated and controlled. Other elements to which it will connect will also have been rigourously tested. Requirements will probably have been tightly controlled. Thus the developing organisation, can with reasonable confidence use the above methodology to test installability. In addition, they know it will be tested by the medical authorities to make sure it is safe.

Microsoft on the other hand, can not be sure into which environment, business users will install Office. Home users, installing the shrink wrapped product create an infinite range of environments, even if they have good housekeeping on their PCs. So whilst Microsoft can test against the most common environments and lay down requirements, it must be nigh on impossible to cover more than the surface, with the methodology shown above. (Not that I am sticking up for them, you understand.)