How to test installation, updates and data migration
A user cannot reach the features of a desktop application if its installation or update fails. These scenarios are time-consuming to verify manually, so they are often tested on only one computer and with one version. This article shows how to divide them into repeatable checks and where automation provides the greatest value.
Where the most common problems arise
A clean installation on a developer’s computer is not enough. Customers may update from different supported versions, use different settings and work with a database that has evolved over several years. A problem may therefore appear only with a particular combination of source version, data and environment.
Common risks include:
- a missing dependency, service or permission on a clean computer;
- a file locked by a running process during an update;
- loss of user settings or an incorrect database conversion;
- a failed upgrade from an older but still supported version;
- an incomplete uninstall that causes the next installation to fail.
The biggest mistake is often checking only the result “the application opened”. Corrupted records, changed settings or a non-functioning service may not become apparent until later.
How to create reliable coverage
First, we prepare a matrix of supported paths. We determine which versions can be updated directly, which require an intermediate step and which types of user data must be preserved after migration. We do not test every historical combination, but those that the vendor supports and customers actually use.
Each test begins in a known state. We restore a virtual machine or dedicated test environment from a snapshot, install the specified older version and prepare reference data. After the update, we check not only that the application starts, but also:
- the version of the application and installed components;
- the state of services, files and configuration;
- record counts and selected values in the database;
- preservation of user settings;
- a key workflow after migration.
We use the installer’s command-line or unattended interface where one is available. We automate the graphical wizard only for the part that a user also needs to complete. When controlling windows, we prefer Windows UI Automation to clicking fixed coordinates; we explain the difference in Why desktop tests should not rely on coordinates and images.
Tests can run on a dedicated Windows runner according to risk: when the installer changes, regularly overnight or before a release. Not every upgrade path needs to run for every build.
What to watch out for
Migration tests must use prepared test data, not the only copy of a production database. Licences, activation, administrator permissions and antivirus behaviour must also be addressed in advance. If the installer is expected to support returning to an older version, rollback is a separate scenario and must be verified just as thoroughly.
What you gain
The team receives repeatable information about whether the application can be installed and whether supported upgrade paths preserve data. Manual testing can focus on new or non-standard situations instead of repeating the same steps on clean machines.
At the same time, a defect appears in a specific combination of version and data. The developer does not have to begin looking for the cause only after a customer report, and the release does not depend on a single test performed in a hurry.
Next step
List the supported source versions, the target release and two or three representative data sets. Then verify the entire process for one upgrade path, from preparing the environment to checking the data. The result will show what can safely be included in a regular automated run.