Test cases for mobile app install, update and uninstall
Updated 2026-11-13 · 6 min read
These 30 cases use explicit test fixtures and checkable outcomes. Cover normal behavior, boundaries, recovery, security and usability, then adapt the requirements to your product.
How to answer in an interview
Ask which OS versions and distribution channels are supported, which older releases can upgrade, and what data should survive each transition. Separate clean install, in-place update, uninstall and backup restore. A successful launch after a fresh install tells you little about migration from an older database.
Scope and test data
These 30 cases require approved test builds labelled A (older) and B (newer), an isolated backend, synthetic user Asha Test, and a device matrix supplied by the team. Record real build identifiers, signing/distribution setup, storage availability and backup state before execution. Labels A and B are fixtures, not claims about released versions.
Seed A with a saved preference, an offline draft and a server-synced record. Specify which must survive update and restore. For clean-install checks, disable restore or use a clean test profile. Android Auto Backup can restore eligible data after installation; uninstalling is not proof that the next install starts with empty data. Uninstall also does not by itself delete a server account.
These are proposed manual test cases, not an execution report. Run security and load checks only in an authorised isolated environment. Record agreed limits before execution; a case without its required limit is not ready to pass or fail.
Clean installation
| ID | Category | Test case | Expected result |
|---|---|---|---|
| M01 | Functional | Install B through the approved test distribution channel on a supported device | One app entry appears with the expected build and opens to the designed first-run screen |
| M02 | Functional | Launch B for the first time with clean local state | Onboarding defaults match the clean-install specification |
| M03 | Negative | Launch a fresh install while offline | Offline explanation or limited mode appears; no permanent startup loop occurs |
| M04 | Boundary | Attempt installation with insufficient storage | OS or installer reports failure; no falsely successful usable install is shown |
| M05 | Negative | Interrupt the package download and retry through the approved channel | A complete valid build installs; partial download is not treated as runnable |
| M06 | Compatibility | Attempt installation on an unsupported OS version | Channel or installer prevents unsupported installation according to package eligibility |
| M07 | Compatibility | Install on each supported device architecture and screen class | Correct build variant launches without missing native components or clipped onboarding |
| M08 | Functional | Deny optional permissions during onboarding | App remains usable outside the dependent feature; denied capability is explained |
| M09 | Functional | Open an approved app link after initial setup | App resolves the intended destination and applies authentication before private content |
| M10 | Security | Attempt to install a deliberately invalidly signed test artifact | Distribution or OS validation rejects it; no trusted existing install is replaced |
Updates and migration
| ID | Category | Test case | Expected result |
|---|---|---|---|
| M11 | Functional | Upgrade seeded A to B through the intended channel | B launches; documented preferences, draft and synced record are retained |
| M12 | Functional | Upgrade from each supported older release, including a skipped release | Each supported migration path produces the expected current data shape |
| M13 | Functional | Launch B repeatedly after migration | Migration does not duplicate records or reset preferences on later launches |
| M14 | Negative | Interrupt the update download before completion | Existing installed version remains usable or installer offers recovery without corrupting its data |
| M15 | Negative | Interrupt first-launch migration at an approved fault point | Next launch recovers or reports a controlled failure without silently discarding seeded data |
| M16 | Boundary | Upgrade with storage near the documented free-space requirement | Supported boundary succeeds; insufficient space fails clearly without partial user-data loss |
| M17 | Functional | Update with notifications disabled and optional permissions denied | User choices persist unless a documented platform change requires a new prompt |
| M18 | Functional | Update with an offline operation pending | Pending operation is retained and reconciles once when connectivity returns |
| M19 | Compatibility | Run A and B against the staged backend during rollout | Both supported clients complete their agreed core workflows without incompatible responses |
| M20 | Security | Attempt a normal-channel downgrade where policy forbids it | Installer or channel refuses; B's user data remains intact |
Uninstall, restore and release confidence
| ID | Category | Test case | Expected result |
|---|---|---|---|
| M21 | Functional | Uninstall B through OS settings | App entry is removed and it cannot launch from the normal launcher |
| M22 | Functional | Reinstall with restore disabled in a clean profile | Onboarding starts with clean local state; old local draft is absent |
| M23 | Functional | Reinstall with an eligible backup and restore enabled | Only data allowed by backup policy returns; restored data opens correctly |
| M24 | Security | Inspect the approved test backup and restored state | Credentials and sensitive files excluded by policy are absent |
| M25 | Functional | Sign in after reinstall and fetch server-synced records | Authorised server records return once; uninstall has not been mistaken for account deletion |
| M26 | Security | Switch to another account after reinstall | Previous user's private local or restored records are not exposed |
| M27 | Functional | Send a test notification to the old installation registration after uninstall | Permanent invalid-registration feedback, when received, retires that registration |
| M28 | UI | Inspect app name, icon and build information after update | Branding is consistent and displayed build identifies B rather than stale A |
| M29 | Performance | Measure first launch after update and later launches on reference devices | Each meets its separate recorded budget; migration cost is included in first-launch measurement |
| M30 | Compatibility | Repeat clean install, upgrade and reinstall on the supported Android and iOS matrix | Each lifecycle follows that platform's documented distribution and restore policy; results name the exact device and build |
Preserve evidence before resetting the device
Record seeded data before update, verify it after migration, and keep the install-channel error when an operation fails. Resetting immediately can erase the only evidence of an intermittent migration defect. Use authorised test profiles and devices for destructive lifecycle cases.
If asked “Should uninstall remove everything?”, distinguish app-local data, backups, exported files and server records. Define each retention expectation separately. Android versioning and backup documentation support the platform discussion here; iOS restore, signing and distribution paths still need a platform-specific execution plan.
Downloads
Quick answers
Is reinstall always a clean installation?
No. Eligible backup data may be restored. Control backup state or use a clean profile when testing first-run defaults.
Should every update test start from the immediately previous release?
No. Include the older versions the product promises to support, especially paths that skip intermediate migrations.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.