Define mobile acceptance tests around user goals, authoritative outcomes and recovery from ordinary interruptions. A screen rendering correctly does not prove that the associated transaction completed or that another user is prevented from accessing it. Test representative journeys across the agreed devices, roles, connectivity and external dependencies.
Let’s plan your mobile acceptance tests.
Bring your requirements and the decisions you need to make. We’ll help you clarify the scope, explore the trade-offs and plan the next step.
Start with accepted outcomes
For each journey, record the starting conditions, user goal, required business result and evidence of completion. Include what the user sees and what the backend or external system records.
Use representative data and task permissions. Decide which scenarios can use controlled test services and which require a separately authorised production verification arrangement. Avoid creating real consequential transactions merely to make a test look realistic.
Build a journey test record
| Field | What to capture | Example question |
|---|---|---|
| Preconditions | User, role, device and data | Is the account actually permitted? |
| Task | Outcome the user must achieve | Can the request be completed? |
| Interruption | Failure introduced deliberately | What if connectivity drops? |
| Visible state | Message and available next action | Is pending distinct from success? |
| Authoritative result | Accepted backend or provider record | Did the business action occur once? |
| Recovery | Resume, correction or escalation | Can work continue without guessing? |
| Evidence | Version and result references | Can a reviewer reproduce the finding? |
This is an acceptance template, not an exhaustive test standard. The product's scope determines the necessary journeys and depth.
Run an interrupted submission
Suppose a hypothetical user sends an inspection report and then receives a phone interruption. On return, the app should explain whether work is saved locally, submitted or accepted.
Repeat the test with server acceptance occurring before the connection fails. Verify that retry or resume does not create a duplicate report. Include a rejected attachment and an expired session as separate conditions with their own expected recovery.
Include boundaries beyond the main task
Test installation, permissions, account recovery, accessibility, old supported client versions and access removal. Check links from notifications when the underlying task has changed or is no longer permitted.
Android's core app quality guidance provides platform-level context. Your acceptance plan must still define the product-specific tasks, environments and evidence it covers.
Classify failures by consequence
Separate appearance defects from failures that affect transaction integrity, access or the ability to recover. Agree release-blocking conditions before the acceptance session.
Record environment and dependency limitations. A passing result against a test provider does not prove identical production configuration, and one device does not establish every supported form factor.
Connect findings with a release decision
Assign each unresolved finding an owner, next action and accepted limitation if applicable. Recheck the affected journey after a repair and run relevant regression checks where shared behaviour changed.
Retain the evidence needed to explain the decision. A checklist containing only ticks loses the context that makes a later incident or supplier transition understandable.
Questions founders ask
Must every test be automated?
Choose methods suited to the risk and repeated work. Automation and human task review can provide different useful evidence.
Does testing every screen cover every journey?
No. State transitions, integrations, permissions and interruptions can fail between individually correct screens.
Prepare the acceptance session
Bring journeys, devices and expected business records. Combine the mobile launch checklist with the mobile development overview to make readiness reviewable.
