Mobile app regression testing: how to choose what to test
For mobile app regression testing, keep a short list of journeys that must work in every release. Then add cases for the parts of the app that share code, data or settings with this release's changes. If a fix changes how the app renews a sign-in session, retest the original bug and check what happens when the same session expires during checkout or while someone is editing a saved draft.
How do you decide which cases to run?
Start with the release candidate and its change list. For each change, ask the developer what else uses the code or data it touches. A fix on the account screen might change a session handler used by every signed-in screen. A change to one button label may need only a quick check of the affected screen and its supported layouts. The ISTQB foundation syllabus, section 2.2.3 calls this impact analysis: identify what a change could affect before choosing the regression tests.
Keep the usual release checks in the run even if their screens didn't change. Pick the journeys your users would be stuck without, such as signing in, placing an order or finding work they've already saved. For the extra cases, ask what failure would cost and where it's most likely to happen. Losing a draft during an app update deserves a run from an older installed build. A fresh install can't answer whether existing work survives the update.
What would you test after a change to sign-in?
Imagine a shopping app fixes a loop that sends customers back to sign-in when their session expires on the account screen. In this example, the app should renew an expired session if the server still allows it. If the session has been revoked, it should ask the customer to sign in again. Use a test account and ask the developer for a repeatable way to put it in each state.
| Case | What to do on the release candidate | What should happen |
|---|---|---|
| Original account bug | With an expired but renewable session, open Account. | Account loads without sending the customer back to sign-in. |
| Checkout uses the same session | With an expired but renewable session, open a filled basket and continue to checkout. | Checkout opens with the same items and quantities. |
| Return to a saved draft | With an expired but renewable session, reopen a saved return request. | The draft opens with the fields the customer saved. |
| Session cannot be renewed | Revoke the test session, then open the order history. | The app asks the customer to sign in and doesn't show protected order data. |
| Existing customer updates | Fill a basket on the last shipped build, then update in place and reopen the basket. Sign in again if prompted. | The basket still has the same items and quantities. |
The first row confirms the fix. The other rows check whether existing behaviour still holds under related conditions. If the first row fails, update the original ticket using the mobile bug retesting checklist. If checkout now empties the basket, file a separate issue and link it to the failed case and the original fix.
Which tests need a phone?
Use fast automated tests for rules you can exercise without navigating the whole app. For this example, a component or integration test can verify how the session handler responds when renewal is accepted or rejected. Run the checkout journey on the release candidate as well: it verifies that the screen actually keeps the basket while the session changes. Google's Android testing strategy guide shows how smaller tests and release candidate tests can cover different parts of a journey.
If the change ships on iOS and Android, start with a representative phone on each. Add a device or OS version when it tests a specific risk, such as an older supported OS where the app restores state differently. Use the mobile device test matrix to record which combinations ran. If you only tested a fresh install on Android, leave the Android upgrade case marked Not run.
What should you record before signing off?
Use one row per case and device setup. Name an observable result, such as “basket still contains two items when checkout opens”. A case marked Blocked needs a reason: for example, the test environment couldn't produce an expired session. That tells the release owner what still needs evidence. If the build changes before release, check what changed and rerun the affected cases against the new build.
Release candidate and test environment:
Previous build (for upgrade or comparison):
Change and other journeys it could affect:
Case:
Device and OS:
Starting state and action:
Expected result:
Actual result or reason not tested:
Status (Pass / Fail / Blocked / Not run):
Evidence or issue link:
Required cases still open:
Release owner and decision:
If a case fails, record the build, the starting state and the exact point where the result changed. If you compared it with the last shipped build, include both results under the same conditions. If you couldn't make that comparison, report the observed failure and leave its history open. Use the bug report template generator to turn the failed case into a tracker issue.
Frequently asked questions
What is mobile app regression testing?
Mobile app regression testing checks that behaviour people already rely on still works after a change. It can cover the changed screen, other journeys that share its code or data, and differences between app builds, devices and OS versions.
What is the difference between smoke testing and regression testing?
A smoke test is a short check that a build is usable enough for further testing, such as installing it and signing in. Regression testing checks whether a change broke behaviour that previously worked. A critical journey can belong to both suites, with more conditions tested in the regression pass.
Do you need to run the full regression suite for every mobile release?
Keep a core set of critical journeys for each release and add cases based on what changed. Widen the pass when a shared dependency or data migration affects many journeys, or when you cannot confidently identify which users and flows are affected. Record any cases you leave out.