Q24 of 26 · Mobile QA

How do you test app updates and data migration between versions?

Mobile QASeniormobileupgradedata-migrationversioningappiumadbtesting

Short answer

Short answer: Install the previous production version, seed known app state, install the update over the top (preserving app data), then assert the migrated state is intact: user is still logged in, cached data is correct, and no crash occurs on first launch of the new version.

Detail

Why it matters: most crash spikes after a release are migration failures. A database schema change that doesn't account for existing data, a preference key rename, or a removed cached file format can corrupt state for every user who upgrades.

Test flow on Android:

adb install old.apk          # install previous version
# launch app, create known state: log in, add items, set preferences
adb install -r new.apk       # replace APK, preserve data
# launch app
assert: user is still logged in
assert: cart items are preserved
assert: preferences are unchanged
assert: no crash on launch

Test flow on iOS: use TestFlight to install the previous version on a real device. Create state. Install the new version via TestFlight (which preserves app data). Assert. For CI, use xcrun simctl install booted old.app then xcrun simctl install booted new.app on the iOS Simulator — the simulator preserves app data between installs of the same bundle ID.

What to seed as known state: the user session token, the database version stamp, any cached user data, and user preferences. These are the four things most likely to break on migration.

Specific failure modes to assert: the database migration function runs without exception, deprecated columns are removed from the schema without data loss, new required columns have correct default values for existing rows, and caches are invalidated (not served stale data from the old schema).

// WHAT INTERVIEWERS LOOK FOR

Understands the test is about preserving pre-existing state through the upgrade — not just running tests on a fresh install of the new version.

// COMMON PITFALL

Installing only the new version in tests and calling it an upgrade test. A fresh install doesn't exercise any migration code — it starts with an empty database.