Mobile bug retesting checklist: how to verify a fix

To retest a mobile bug fix, confirm that the installed build contains the change, recreate the original starting conditions and repeat the failing steps. Check that the expected result now occurs, then test related behaviour the change could affect. Record the build and evidence in the original issue before closing it.

A fresh install that passes won't settle a bug reported after an upgrade. A successful retry won't explain whether a queued upload was lost. Keep those conditions in the retest so another tester can follow the result.

What is the difference between retesting and regression testing?

Retesting asks whether the original defect has been fixed. Regression testing asks whether the change broke something else. ISTQB calls retesting confirmation testing and recommends using an impact analysis to choose regression coverage. See section 2.2.3 of its Foundation Level syllabus.

For a photo-upload bug, confirmation might mean repeating the interrupted upload and checking that it completes. Regression checks might include cancelling an upload, starting a second one and opening the saved photo. Ask the developer which paths share the changed code so the checks reflect the fix.

What should you confirm before installing the fixed build?

Open the original issue and agree what a pass means. Keep the original steps, screenshots and failure details; add the retest result underneath them.

Confirm these details with whoever supplied the build:

• The fix is included: record the version, build number and distribution channel. A newer version label alone doesn't tell you which changes it contains.
• The right environment is available: check the backend, account role and feature settings needed for the test. Note a server-side change separately from an app update.
• The starting data can be recreated: identify the saved draft, queued item, permission choice or upgrade path that made the failure possible.

Preserve any evidence you still need before uninstalling, clearing data or replacing the app. Where practical, confirm the old failure on an approved test setup first. If you cannot, state that limitation alongside the new result.

Which checklist should you use to retest a mobile bug?

Copy this into the issue or your existing test record. Adapt it to the defect; don't require a network transition for a spelling correction.

Issue:
Tester / date:
Original failing version and build:
Build containing the fix / distribution channel:
Backend environment / relevant feature settings:
Device model / OS version / physical or simulated:
Installation: [fresh install or upgrade; previous build]
Starting state: [account role, data, permissions, app state]

[ ] Confirm the installed build contains the intended fix.
[ ] Recreate the relevant starting state from the original report.
[ ] Repeat the original steps without an extra workaround.
[ ] Check the expected result and completion of the user's task.
[ ] Repeat as agreed for this defect; record failures / attempts.
[ ] Run the related regression checks agreed with engineering.
[ ] Attach reviewed evidence labelled with this build and attempt.
[ ] Record unavailable conditions and checks that remain blocked.

Observed result:
Related regression results:
Failures / attempts:
Evidence links:
Outcome: [passed / failed / blocked / inconclusive]
Next action / owner:

The mobile device test matrix helps when the fix needs checking on several configurations. Keep a separate outcome for each relevant device and OS combination.

Which mobile conditions are easy to miss during a retest?

Recreate the state before the failing action, including anything that happened in an earlier session. Use the report to decide which conditions matter.

Original failure	Retest setup to preserve	What could make a pass misleading?
A saved draft disappears after updating	Create the draft on the earlier build, then upgrade through a supported test route	Installing clean removes the draft before testing starts
Upload stops after the app resumes	Queue the item, background the app and repeat the reported network transition	Testing a new upload on a steady connection skips the trigger
A button is hidden by the keyboard	Use the reported screen size, text size and focused field	Dismissing the keyboard before tapping avoids the failure
Denying camera access leaves a blank screen	Repeat the relevant denied-permission state	Granting access tests a different path

Android's core app quality guidance includes checks for restoring app state and continuing to function when permissions are denied or revoked. Use those as prompts for related checks when the changed feature depends on them.

If you substitute a device, account or installation path, say so. Keep the original condition visible as a coverage gap until it has been tested or the responsible person accepts the risk.

How should you retest an intermittent bug?

Agree the setup and test effort before starting. Record the previous observed frequency if it is known, then count failures and attempts under the fixed build. Reset the relevant starting state between attempts so each run actually exercises the trigger.

“Zero failures in ten attempts on build 423, using the original upgrade path” is useful. “Fixed after trying a few times” leaves the next person guessing. Ten is an example, not a recommended threshold: the effort should reflect the impact and how difficult the failure was to trigger before the change.

If the trigger no longer exists in your test environment, mark the result as inconclusive or blocked and explain what is missing. For evidence collection before the next attempt, the screen recording guide explains how to capture the action and its result without leaving the developer to transcribe the clip.

What should the retest comment say?

Write the outcome beside the configuration and link the evidence. Here is a fictional example:

Retest: passed for the configuration below
Issue: Saved basket note disappears after returning from delivery options
Original build: 3.6.0 (412)
Retested build: 3.6.1 (423), internal distribution, staging backend
Device: Pixel 8, Android 15, physical phone
Setup: Upgraded from 412; signed-in test account with an existing basket note

Original steps: Open Delivery options, then return using Back.
Result: Saved note remains visible and is included when reviewing the order.
Attempts: 0 failures / 5 attempts, resetting the basket between runs.
Related checks: Edit note, remove note and cancel delivery selection all passed.
Evidence: Recording attached to this comment; filename includes build 423.
Gap: Original second device unavailable; its retest remains blocked.
Next action: QA owner to arrange that device before release sign-off.

The result applies to the tested configuration. The five attempts don't establish that every device is fixed, and the blocked device still needs a decision. If a related check fails, record it and agree whether it belongs in the original issue or a linked issue.

When is the bug ready to close?

Review the original failure result, related checks and any gaps with the issue owner. A passing retest supports closure for the tested scope; it doesn't by itself approve the entire release. Record who accepted any remaining uncertainty and which build the decision covers.

If the failure persists, return the issue to engineering with the new build, setup and evidence. For questions about ownership or missing information, use the bug intake and triage template to agree the next action.

Keep these results in your team's tracker. If collecting the original screenshots and app context is consuming the QA round, explore BugScreen's QA reporting workflow or create a workspace.