A deep link opens a particular application screen, such as a product, order, invitation, or search result. For users, it is a shortcut to an action. For QA, it combines the OS, browser, domain configuration, application navigation, and access control.
Testing goes beyond seeing the application appear. Check which object opened, under which account, what happens after login, and where Back leads.
Distinguish link types
A custom scheme looks like qahub://article/123. An installed application handles it, but the scheme itself does not verify web-domain ownership and may conflict with other handlers.
Android App Links and iOS Universal Links use ordinary web URLs with a verified site-to-app association. Android checks Digital Asset Links; iOS uses associated domains and apple-app-site-association. These are different platform mechanisms with different diagnostics.
The link contract
Before testing, describe allowed domains, paths, parameters, and destination screens. For example, https://example.com/orders/1042 means viewing an order rather than confirming a purchase. Actions with consequences generally require explicit confirmation and renewed permission checks.
Agree on behavior for unknown objects, missing parameters, old link formats, and an application that is not installed. Without a contract, team members may interpret the same behavior as either a defect or an acceptable fallback.
Checking domain association
On Android, assetlinks.json must match the application and signing certificate. A working debug build does not establish store-build behavior because signatures may differ. Check verification state on the target device, accounting for asynchronous verification and OS version.
On iOS, entitlements and the AASA file must agree. Consider configuration delivery through Apple infrastructure and caching: fixing the server file may not immediately change an already-installed application's behavior.
Where users open links
Test the real source: email, messenger, notes, web page, or QR code. Embedded browsers and redirects can change the opening path. Typing a URL into the browser address bar is not equivalent to tapping a Universal Link.
Apple also describes same-domain navigation remaining in Safari. A bug report therefore needs the source and opening method alongside the URL.
Practical example: an order after login
Imagine an emailed link to order 1042. Test both the owner and another ordinary user.
- 1.End the app session and tap the email link. Expect the agreed login screen with the target route preserved.
- 2.Sign in as the order owner. The application should open exactly order 1042 without another unnecessary login or an accidental purchase.
- 3.Navigate back. History should remain understandable without an endless login/order loop.
- 4.Repeat after logout, signing in as another user. Expect access denial without disclosing the other user's order details.
- 5.Delete the test order through an authorized method and reopen the link. Expect the specified unavailable-object state.
Confirm permission checks through API responses or server data: a hidden screen alone does not establish resource protection.
Application states and repeated navigation
Test a cold start, return from the background, and opening over another screen. Repeating a link to the same object should not create an uncontrolled stack of identical screens.
Another case is two different links tapped during startup. For example, the user taps order 1042 and then 1043 before login finishes. Requirements should define which route remains current and prevent an outdated action from running.
Parameters and security
Treat every parameter as external input. Check unknown IDs, empty values, URL encoding, extra parameters, and unexpected nested URLs. The application must not trust a role, price, or owner merely because a link specifies it.
- →Validate the complete target domain rather than an arbitrary substring match.
- →Restrict return URLs to allowed destinations.
- →Keep secrets and personal data out of URLs and diagnostic attachments.
- →Apply normal server-side access checks to data changes.
Fallback when the application is absent
Without the application, a web link should lead to a usable web scenario or agreed page. A custom scheme without a handler does not provide this automatically. Also test an installed older version that does not recognize the new route.
Preserving context through installation requires a separate deferred deep linking mechanism. It is not an inherent property of every App Link or Universal Link; the product must explicitly support and test it.
Diagnosing failures
Separate three questions: did the OS choose the application, did the application parse the URL, and did the backend permit access? If a browser opens, begin with the domain, signature, and verification. If the app opens at its home screen, investigate route handling and restoration after login.
Do not replace system-routing checks with directly launching a specific activity and package. This helps diagnose the handler but can bypass the OS application's selection process.
Key takeaways for QA engineers
A good deep link takes users to the intended context, preserves navigation, and grants no extra access. Test domain association, source, application state, authorization, and fallback as one route. Preserve the complete URL with secrets safely replaced and the exact opening method for reproduction.