Test summary report template for a mobile release

A mobile test summary report should tell the release owner which iOS and Android builds were tested, what passed or failed, and what still needs checking. Lead with your release recommendation and the reason for it. Use the template below to put the results, open defects and gaps in one place without making the reader reconstruct the round from individual tickets.

What does the report need to answer?

Start with the decision the team needs to make: can these builds proceed to the next stage, and under what conditions? Name that stage, whether it's a wider beta, UAT or production. A successful internal test doesn't automatically approve a production release.

Compare what happened with the agreed exit criteria. ISTQB's foundation syllabus, section 5.3.2 describes a test completion report as an account of the testing performed, including outstanding defects, risks and departures from the plan. For mobile QA, make the build and device coverage explicit so a result on one phone doesn't read as approval for every supported configuration.

If the team hasn't agreed what acceptance requires, settle that before interpreting the results. The mobile UAT test plan template can help establish the scenarios and decision owner for a stakeholder round.

Which template can you copy for a mobile release?

Keep the short recommendation at the top and link to detailed results underneath. Fill in the environment and feature settings that could change the outcome; don't paste credentials or real customer data into the report.

Release / next stage:
Report author, testing dates and time zone:
Recommendation (proceed / hold / proceed with conditions):
Reason and any conditions:

Tested candidates
- iOS version and build:
- Android version and build:
- Service environment and relevant feature settings:
- Previous installed versions used for upgrade tests:

Scope and coverage
- Changes and journeys tested:
- Plan / exit criteria:
- Device models, OS versions and install states tested:
- Missing devices, scenarios or other departures from the plan:

Results as of (date and time):
- Counting rule (for example, case + device + install state):
- Passed / failed / blocked / not run / total:
- Detailed case results and automated run links:
- Open defects: issue, user impact, workaround and owner:
- Blocked or untested cases: reason, risk and next action:

Decision
- Exit criteria met / unmet, with evidence:
- Decision owner, decision and timestamp:
- Accepted risks, follow-up owners and due dates:
- Builds and environment this decision covers:

Use the actual build identifiers, even when both platforms show the same marketing version. For an upgrade test, record the starting version as well as the candidate. “Android passed” doesn't say whether anyone tested an existing installation with saved data.

How should you count passed, failed and untested cases?

Say what you're counting before adding up results. For a manual round, one result might be one test case on one device and OS combination, with a specified starting state. The same case on a fresh install and an upgraded installation then produces two results.

Give each planned result one status as of the report's date and time. Use Blocked when something prevented the check, such as an unavailable test account. Use Not run when it hasn't been attempted. Explain both alongside the totals. Keep cases removed from scope visible as a change to the plan rather than quietly dropping them from the denominator.

Here's a fictional checkout test round with eight planned results per platform:

The round has 12 passes from 14 completed checks, with two further checks unresolved. If you show the executed pass rate, it's 12 ÷ 14 = 85.7%. That percentage says nothing about the impact of the two failures or the risk in the two unchecked cases. Keep those details beside it.

Report automated suites separately from the manual round unless you've defined how they map to the same cases. Hundreds of passing unit tests shouldn't hide an untested checkout journey.

What would a useful release recommendation look like?

Continuing the fictional example, suppose the iOS failure creates a duplicate order after a retry. The Android failure clips a collection-time label at large text sizes. The blocked iOS case needs an account the test environment couldn't provide, and the Android upgrade case wasn't run.

The summary could read:

Hold the production release of iOS 2.4 (514) and Android 2.4 (907). Twelve of 16 planned results passed; two failed, one was blocked and one wasn't run. The iOS retry failure creates a duplicate order and breaks our agreed checkout exit criterion. Fix and retest that failure, then complete the Android upgrade check. The detailed results identify the clipped label and blocked account scenario for the release owner's review.

Link each failure to a ticket with the affected build, setup, reproduction steps and evidence. For each gap, say who will resolve it and when. A blocked test needs an action such as “QA to rerun with a restored test account by Friday”.

Record the release owner's decision separately from QA's recommendation. If the owner accepts a remaining defect, state its user impact, any workaround and the follow-up owner. Apply the decision to the named candidates and environment. When a replacement build arrives, review what changed and rerun the affected checks before updating the recommendation. The mobile regression testing guide explains how to select those related checks.

Which evidence should sit behind the summary?

Link to the case results, the device coverage record and any automated runs used in the decision. Keep the original failing run available after a successful retest so engineering can compare them.

For automated iOS tests, Xcode's Report navigator provides the test report, including test results and logs. See Apple's guide to interpreting test results. For Android, the Run window shows results and supports exporting them; see Google's test results guide. Link the run that tested the candidate named in your summary.

Before sharing, check that the release owner can open the evidence and that screenshots and logs don't expose private account details. If a failed case still needs a clear ticket, use the bug report template generator to write up its steps, expected result and actual result, then link that issue from the summary.