Package testing

Tested item

Details

Why to check this item?

Shortcuts

Start Menu shortcuts:

- in right place

- work OK

Check that the shortcuts published for user are created in right location and they start correct applications with correct parameters.

Extra Shortcuts

Extra shortcuts removed

Depending on the company standards sometimes the extra shortcuts users don't need should be removed during package installation.

Log files

Logs created to correct place

If company has a standard directory for local logging, check that all logs are in correct place.

Logged errors

Check logs for possible "under the hood" errors

Sometimes the installers may fail even if they say installation finished successfully. It may be good to check the logs quickly if there are some severe errors logged.

Configuration files / registry imports

If you are copying some configuration files or importing some registry settings, check that all those are correctly done.

Quite often people are just checking that the software installation works OK, but forgetting to verify all the configurations are in place. These errors may then show up later when users are not able to use the applications.

Test application with basic user rights

Works OK with Basic User permissions (always test this first!)

One of the most important things is to check that the application runs with basic user rights straight after the installation. Some installers / setups are not setting up the permissions or registering components correctly but trusting that the users can do those themselves. This prevents the application to run on basic user permissions. To fix this you need to locate and run the required actions in the package.

Temporary installation files

If you are for example copying some media on local disk for installation, remember to remove them in the end of the package.

It is important to clean the "dirt" created by the installation and so to keep the hard disk space free.

Scenario

Why to test

Consequences / how to fix

Basic User logged in during installation

Sometimes software installers / setups try to run some sub processes with currently logged on user's account. Usually these fail due to lack of permissions.

Some versions of InstallShield add a registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{ID}\RunAs = Interactive User

where {ID} is the unique AppID of this InstallShield version. Value is added in the beginning of the installation by the Isscript.msi installer. By removing this value after this phase has run but before the actual software installer starts the installation runs with admin rights.

Admin logged in during installation

Sometimes software installers / setups may show some additional dialogs if an admin is logged on, which might then cause a failure.

Computer locked during installation

Some installations don't work if the computer is locked. Examples of this are ScriptIt based installations or AutoIt scripts utilizing SendKey functions. These automation methods won't run if computer is locked.

Failing this test prevents the group distributions of this package and lowers the overall quality and usability of the package. If the problem is in the installation scripts built by package builder, you should try to modify them to work also in this scenario. If the problem is already inside the software installer / setup, not much can be done.

No one logged in during installation

Some installations don't run if no one is logged into the computer. This can happen for example with some AutoIt or ScriptIt driven installations.

Failing this test prevents the group distributions of this package. If the problem is in the installation scripts built by package builder, you should try to modify them to work also in this scenario. If the problem is already inside the software installer / setup, not much can be done.

Initial installation

Some installations may fail in initial installation even though the package works perfectly in single installation tests. Reasons for this may be for example some missing user specific directories or such which are created on computers already in use.

Try to find out what is the reason for the failure in initial install and fix it. If this test fails, package cannot be added bind into anywhere as default package but has to be installed separately after initial build.

Same software already installed

Some installers fail, if same software is already installed.

You can either add logic into package which stops the package before installation even starts, or then you need to check the installation status (by inventory reports) every time before launching the package.

Software already running

Usually software cannot be updated if the same application or previous version is already running.

Add logic into package checking if application is already running (action ProcessCheck). This is important in packages meant for group distributions.