Skip to main content
QA guide

Deep link testing checklist before every release

If deep links are part of paid acquisition, lifecycle messages, or QR campaigns, they need a repeatable QA routine. This checklist helps teams validate iOS, Android, and web behavior before traffic goes live.

What a complete deep link test should prove

A passing test is not just "app opened once." You need to prove route accuracy, fallback behavior, and parameter integrity for all major entry conditions.

Minimum pass criteria

  • Installed users open the expected in-app route.
  • Non-installed users land on the intended store/web fallback.
  • UTM/query parameters survive redirect and route resolution.
  • Domain association checks pass without redirect/content-type warnings.
li-nk.me/tools/universal-links
Universal links validator screen with domain check results

Release-day deep link testing sequence

1. Infrastructure preflight

Validate AASA and assetlinks endpoints first. If association files are wrong, app-side checks are noise.

2. Installed-app route checks

Test critical routes on both iOS and Android devices where the app is already installed.

3. First-install fallback checks

Uninstall app and re-test to verify store/web fallback flows and deferred route handoff logic.

4. Parameter integrity checks

Confirm UTM/campaign parameters remain present in final destination and analytics payloads.

Test matrix teams can reuse

ScenarioExpected behaviorFailure signal
iOS installed appUniversal link opens correct screen in-appSafari opens and route does not reach app
Android installed appApp Link resolves to intended activity/routeBrowser fallback used despite installed app
App not installedStore or web fallback loads quickly and correctlyWrong store, 404 landing page, or stale destination
UTM-tagged campaign linkCampaign params preserved end-to-endMissing or overwritten source/medium/campaign keys
QR-based scanSame routing as tapped link for each platformScan path diverges from direct link behavior

Tooling stack for faster debugging

Escalation order when a test fails

  1. Fix association files and domain response warnings.
  2. Re-test on a clean device state (cache/app reinstall as needed).
  3. Compare failing route against a known-good baseline link.
  4. Inspect logs for platform detection and redirect target mismatch.
  5. Only then move to app-side route handler debugging.

Related reading

Ship links like product code, not marketing assets

Deep links sit on your conversion path. Treat them with release gates, repeatable test cases, and visible rollback criteria just like any production feature.