Test mobile deep links as complete journeys: entry point, app state, identity, destination and fallback. A link opening the app is only the first step. The user should reach the intended authorised content after any required login, or receive a clear alternative when that content is unavailable.
The test plan must distinguish platform link association from application routing. Both can affect the result, but a correctly associated domain does not prove that a signed-out user resumes the right journey.
Define the intended destination and allowed fallback
Describe what the link represents in business terms. A fictional service app might link to a particular job record, while another link opens a general list. Specify which parts of the destination are essential and what happens when they no longer exist.
Review incoming links with the broader mobile navigation and accessibility checks, rather than testing app opening alone.
Choose the fallback deliberately. The web version, a general app screen or an unavailable message may be appropriate in different circumstances. Do not let an accidental routing default become the product decision.
Android's App Links testing guidance concerns verification and testing of app and domain configuration. Apple's universal-links documentation explains its supported website and app association model. Use the relevant platform documentation for the actual setup; these sources do not establish that a particular app has been configured or tested.
Record whether the journey is intended to work when the app is absent. A browser fallback and automatic continuation after installation are different capabilities. Do not promise post-install continuation unless the chosen solution supports it and the team has evidence for the complete path.
Choose entry points and device states
List the real places people encounter links: email, a web page, a notification or another supported channel. Entry context can affect how the platform handles a link, so test the channels relevant to the product rather than only pasting a URL into a development tool.
Include the app closed, already running and showing another record. Decide whether opening a second link replaces the current destination, queues a journey or asks the user to finish work first. An unsaved form should not be discarded by an unexplained navigation side effect.
Cover the supported OS and app versions, with the actual installation and association state recorded. A result from one device configuration is not evidence for every supported combination.
Use controlled destinations that let reviewers distinguish correct routing from a generic home screen. Keep a stable test record identity and expected outcome so the same case can be repeated after a routing change.
Preserve the journey through authentication
A signed-out user may need to authenticate before seeing the destination. Retain only a validated intended route and resume it after the appropriate identity checks. Authentication should not turn an untrusted parameter into unrestricted navigation authority.
Recheck access to the destination after login. The person may sign into a different account from the one the sender expected. Knowing a record identifier or receiving its link does not establish permission to open it.
Define cancelled and failed login behaviour. The app should not falsely report that the linked task completed or repeatedly restart an unwanted login. Give the user a clear next choice under the product's actual authentication design.
Consider several incoming links during authentication. Decide which valid destination is retained and how the user understands the result. A global “last URL” variable can conceal a product decision about competing journeys.
Build an app-state and identity test grid
This hypothetical grid shows the decisions to specify. It is not evidence of commands run or tests performed against a released application.
| Starting state | Journey | Expected decision |
|---|---|---|
| App installed; user signed in | Open a permitted record | Reach the intended current record |
| App installed; user signed out | Authenticate and resume | Preserve a valid route and recheck authority |
| App absent | Follow the chosen fallback | Use the supported web or installation journey |
| Record removed or access lost | Open a previously valid link | Show the agreed unavailable or denied route |
| Destination malformed | Process invalid routing input | Reject it or use a safe, defined fallback |
Expand each row with the entry channel and app lifecycle state. For an important journey, inspect both the visible screen and the underlying record identity. Similar titles can make a wrong destination look correct.
Record unexpected extra navigation too. Reaching the right record only after a loop or repeated login can still be a material usability defect. Define acceptance in terms the product owner can assess.
Include back navigation in the same case. After opening the linked record, the user should have an understandable route to continue using the app. Decide whether “back” returns to the previous app screen, the sending context or a sensible parent view. Record the intended behaviour for that platform rather than expecting every entry point to create the same navigation history.
Test a second account explicitly when the app supports account switching. Confirm that the link is re-evaluated under the selected identity and that a previously loaded preview does not remain as evidence of access for the new account.
Review malformed destinations and safe handling
Validate the route and parameters before using them. Decide which destination types are allowed and how unknown fields, missing identifiers or invalid encodings are handled. Avoid treating an arbitrary incoming URL as an approved redirect target.
Include authentication and unavailable destinations in the agreed mobile software testing.
Inspect previews and error messages for unnecessary disclosure. A denied record link should not reveal sensitive record details merely to explain the failure. The appropriate wording depends on the product's information boundary.
Test stale state as well as malformed input. A job may have closed, a booking may have changed or a resource may now belong to another account. The current system state should determine the action available after opening the link.
Use a fictional link to job record J42, then close that job before the user completes login. The correct destination is now the agreed closed-record experience, not necessarily the screen that would have been appropriate when the link was sent. Inspect the displayed record identity and the actions still available. A retained route should preserve intent while the current state determines what the user may do.
Agree evidence and release ownership
A useful result records the link, entry context, device and app state, signed-in identity class, expected destination and observation. Keep test accounts controlled and avoid putting private live links into a widely shared report.
Assign platform configuration, application routing and identity issues to the appropriate owners. The release reviewer should be able to distinguish a verified association from a verified end-to-end journey and see any remaining unsupported combinations.
Discuss incoming-link journeys and release evidence for mobile app delivery with ZakCodeX.
