UAT test plan template for a mobile release

A mobile UAT test plan should say which business tasks the release must support, who will test them, which app builds they will use and what evidence the decision owner needs to accept the release. Agree those details before sending out install links. Use the template below to keep the plan, scenario results and final decision together.

What question should mobile UAT answer?

Start with a task someone needs to complete. For a click-and-collect release, ask: “Can a customer place an order for the right shop and collection time, and can the shop prepare that order?” The customer seeing a confirmation screen is only part of the answer.

UAT checks whether the product meets the needs of the people using it. The SFIA user acceptance testing guidance includes measurable acceptance criteria, scenarios derived from those criteria, stakeholder collaboration and clear entry and exit conditions.

Name a business decision owner who can settle questions about the expected outcome. QA can help prepare and run the tests; someone who understands shop operations should confirm that an order contains what staff need to prepare it.

What belongs in the plan before testers install the app?

Record the release's scope and what you are leaving out. “Click-and-collect checkout” is still broad: say whether changing shops, existing baskets and order cancellation are included. Link the requirements or stories that define the agreed behaviour.

Give testers the exact iOS and Android version and build numbers, install links, environment and relevant feature settings. Include the backend or service version where your team can identify it. If the test environment differs from production, write down the difference and which outcomes it prevents you from checking.

Prepare test accounts for each role, sample baskets and instructions for resetting them. Check that the shop's test queue can receive the orders. Ask each tester to open the assigned build and sign in before the UAT window starts; an expired invitation should be fixed before it consumes their testing time.

Make those setup checks part of the entry criteria. For example, start the round once the assigned builds install, the team's smoke checks pass and both customer and shop test accounts work.

Assign devices and install states deliberately. A clean install cannot show whether an existing basket survives an upgrade. Use the mobile device test matrix to choose configurations, then record the actual phone, OS and build beside each run. Repeat a business-critical scenario on both platforms rather than treating an iPhone pass as an Android pass.

How do you turn acceptance criteria into repeatable scenarios?

Write the outcome first, then the starting conditions and actions needed to check it. ISTQB's Acceptance Testing syllabus, sections 1.1.2 and 2.1 distinguishes measurable acceptance criteria from the test cases used to verify them.

Here is a fictional click-and-collect example. The agreed rule is that a submitted order must appear once in the selected shop's queue, with the same items, total and collection slot shown to the customer. Changing shops must require a slot valid for the new shop. These are example product decisions; replace them with your own agreed rules.

Scenario	Starting conditions	What the tester does	What counts as a pass
Place an order	Customer test account, fresh basket, shop with an available slot	Choose the shop and slot, submit once, then ask the shop tester to open the order	One order appears in the chosen shop's queue; items, total and slot match the customer confirmation
Order after an upgrade	Previous released app installed, signed-in customer with a saved basket	Upgrade to the candidate build without clearing app data, then complete checkout	The saved basket is intact and the submitted order meets the same shop-queue checks
Change the collection shop	Basket ready, first shop and slot selected	Switch to a second shop and complete checkout	The customer chooses a slot valid for the second shop; only that shop receives the order

For each scenario, add its requirement or acceptance-criterion link and assign a tester for each required configuration. Give each run its own basket so two testers cannot accidentally edit the same order. Keep the order reference with the result so the customer and shop testers can compare the same transaction.

What can you copy into a mobile UAT test plan?

Use this in a shared document or test-management tool. Add one result row per scenario and configuration; keep earlier attempts when a new build arrives.

Mobile UAT test plan

Release / change:
Business task and acceptance-criteria links:
In scope / out of scope:
UAT coordinator / business decision owner:
Testers and business roles:
Test window / time reserved for fixes and retesting:

iOS version and build / install link:
Android version and build / install link:
Environment / service version / feature settings:
Differences from production:
Device and OS assignments:
Clean-install and upgrade starting states:
Test accounts / sample data / reset instructions:

Entry criteria:
Required scenarios and configurations:
Exit criteria / failures that prevent acceptance:
Issue reporting link / triage owner / review times:

Scenario result (repeat per run)
Scenario / acceptance-criterion link:
Tester / date / device / OS / app build:
Starting state and test-data reference:
Steps / expected result / actual result:
Status: Pass / Fail / Blocked / Not run
Evidence / issue link:
Retest build and result, if needed:

Acceptance decision
Builds and environment covered:
Results / outstanding failures / untested scope:
Decision: Accept / Accept with conditions / Reject
Conditions, user impact and workaround:
Follow-up owner and deadline:
Decision owner / date:

How should you handle failures and unfinished testing?

Agree the exit criteria before testing starts. For the example above, you might require all three scenarios to pass on the assigned iOS and Android configurations, including the upgrade runs. An order going to the wrong shop would prevent acceptance. Decide how to handle less serious failures with the business owner, and write that rule in the plan.

Use Fail when an observed result breaks the agreed criterion, Blocked when something prevents the check, and Not run when nobody has attempted it. If the shop's test system is offline before the run, the end-to-end scenario is blocked. Link the environment issue and assign someone to restore it. If that system is working but the submitted order never appears, record a failure and investigate it.

Keep the scenario result short and put reproduction details in the linked issue. Include the starting state, expected and actual results, build, device and evidence. Give stakeholders the UAT bug-reporting guide before the round so they know where to send findings. The bug report template generator can help format an issue when a scenario fails.

When a fix arrives, add the new build and retest result without replacing the original failure. Review which other scenarios need another run because the app, service or feature settings changed.

What should the sign-off record say?

State the builds tested, the results and the work still outstanding. If five of six assigned runs passed and the Android upgrade run is blocked, report exactly that. The decision owner needs to see which customer journey remains unchecked.

Record the decision and any conditions against those builds. For an accepted defect, name the affected users, impact, workaround and person responsible for the follow-up. ISTQB's acceptance reporting guidance, section 5.2.2 describes release decisions based on test results and open-defect impact, including acceptance with reservations or rejection pending fixes. If the candidate changes after sign-off, review the affected results before applying that decision to the replacement build.