Jan 4, 2023
6 Basic Steps of eCommerce App Development
Adam Creamer
Read More
The mobile app testing process is the sequence a team runs to get an app from a build to a release it can stand behind: plan, set up, test and fix, decide. This guide lays it out as twelve steps, says what each one produces and who owns it, shows how the steps compress into an Agile sprint, how to build the device list, the exit criteria that tell you testing is done, and what production tells you after release. For what mobile app testing is, start with our What Is Mobile App Testing guide and come back here for the how. What you test is a separate question from how you run the process; our types of mobile app testing guide has that list, and step 2 below is where you pick from it.
Two things make the mobile version of this process different from desktop or web. The device is a variable you do not control, so the plan starts with the critical journeys and the devices they must run on rather than a feature list alone. And most of the steps run more than once per release, so the process is a cadence, not a phase.
The Mobile App Testing Process in 12 Steps
The twelve steps below are the sequence we see working across enterprise mobile teams, from the first strategy conversation through to the final end-to-end pass before release. Not every team runs all twelve on every build, but every team that ships reliably has an answer for each one.
Here is the whole sequence in one view, with what each step produces and who owns it. Owners are the usual split on a delivery team; adjust to yours.
| Step | What you do | What it produces | Owner |
|---|---|---|---|
| 1. Preparation and Strategy Formulation | Define the critical journeys, app type, device list, performance budgets, exit criteria, and the policy for what gets automated | Test plan with device matrix, budgets and exit criteria | QA lead with product |
| 2. Identification of Essential Testing Types | Choose which types this release needs and which changes trigger them | Types list mapped to risk | QA lead |
| 3. Design of Test Script and Test Case | Write cases against acceptance criteria with device, network and state preconditions; scripts for what repeats | Traceable test cases; automation backlog | QA engineers |
| 4. Setup of Testing Environment | Real devices, virtual devices, test data, accounts, network profiles, continuous integration (CI) wiring | Working environment on the device matrix | QA with DevOps |
| 5. Manual and Automated Testing | Developer checks as the feature is built; smoke first; exploratory by hand on new flows; regression automated | Pass/fail results with logs, video and device metrics | QA engineers |
| 6. Usability and User Interface Testing | Real people on real devices; screen reader walkthrough; accessibility validations | Usability findings; accessibility findings | QA with design |
| 7. Compatibility Testing | Run the agreed coverage per tier across the device matrix | Per-device results; device manufacturer (OEM) and OS defects | QA engineers (automated run) |
| 8. Performance Testing | Budgets checked on representative devices and networks | Metrics against budgets | QA with engineering |
| 9. Security Testing | Protected storage, transport, authorization, session expiry | Scan results; pen-test findings | Security with QA |
| 10. Usability and Beta Testing | Beta on a wider cohort; User acceptance testing (UAT) against the business acceptance criteria | UAT sign-off; beta feedback triaged | Product with QA |
| 11. Feedback Integration and Iterative Testing | Every defect reproducible, with severity and priority; fixes return as retests and regression cases | Triaged defect list; regression suite grows | QA with engineering |
| 12. End-to-End Testing Before Final Release | Full journeys on the approved build; exit criteria checked; Go or No-Go | Release report and decision | QA lead, product signs off |
1. Preparation and Strategy Formulation
The mobile app testing process begins with the testing strategy. Settle the prerequisites, the target devices and the app type. Write the test plan for the cases that need to run. Set the performance budgets (cold start, key transitions, memory, battery) and the exit criteria you will hold the release to (see How to Know When Testing Is Done). Set the policy here: which classes of test are automated and which stay manual. Automation suits frequent use cases, tests with predictable outcomes, tests needed for various devices, and unit testing.
App type is not a labeling exercise. It changes what the rest of the plan looks like:
| App type | What it is | What that changes for testing |
|---|---|---|
| Native | Built for one platform in its own language: Kotlin or Java on Android, Swift or Objective-C on iOS | Two separate suites. Espresso on Android and XCUITest on iOS are the standard UI automation frameworks. Full hardware and sensor coverage is in scope. |
| Hybrid | Web code (HTML and JavaScript) inside a native shell, the Ionic and Capacitor pattern | One codebase, but rendering still differs per platform. Test the web layer and the native bridge separately: defects hide at the boundary, in permissions, navigation, deep links and keyboard handling. |
| Cross-platform (React Native, Flutter) | One codebase targeting both platforms: React Native drives native platform views, Flutter renders its own widgets on a canvas | Watch the seam between your code and the platform: the bridge in React Native, platform channels in Flutter. Tooling differs: Appium works for both but is driver-dependent, Detox targets React Native, Flutter uses its own integration_test. |
| Mobile web / progressive web app (PWA) | A mobile-optimized site in the browser; a PWA can also be installed to the home screen | Browser and browser-version fragmentation replaces device fragmentation as the primary variable. A plain web app has no install path; a PWA adds installation, offline behavior, cached content and service-worker updates to test. Hardware access is limited either way. |
Settle this before you size the device matrix. A mobile web app needs breadth across browsers; a native app needs breadth across hardware; a hybrid app needs some of both; a cross-platform app needs hardware breadth, like native.
2. Identification of Essential Testing Types
Decide which types of testing this release needs, in what order, and which ones every release runs regardless. The baseline for a mobile app is functional on the critical paths, compatibility across the device list, interruption on anything that writes data, installation and upgrade from the versions still in use, API contract checks, a performance budget and a security regression. Then add emphasis by what the app does: a banking app leans on security and transaction safety, a media app on performance and battery. Our types of mobile app testing guide has the full list, what each one catches, and a table of which types each kind of release change triggers. The output of this step is a short list mapped to risk, not a tour of every type.
3. Design of Test Script and Test Case
Write test cases against the acceptance criteria, alongside development rather than after it, and keep the link: each case names the criterion it covers, so coverage can be checked by requirement rather than by count. A mobile test case carries three things most web cases leave implicit: the exact device and OS it runs on, the network condition it assumes, and the app state it starts from (fresh install, upgraded, signed in, backgrounded). Leave any of those out and two people will get two results.
Cover the failure paths as deliberately as the happy path: wrong input, lost network mid-request, a denied permission, a call during the flow. Then apply the automation policy from step 1 case by case: anything that runs on every build or across the device list becomes a script; anything that needs judgment stays manual. The output is a traceable case set with preconditions, plus an automation backlog in priority order. One case, written out:
| Field | Example: transfer between accounts |
|---|---|
| Acceptance criterion | AC-12: a transfer between two of the user’s own eligible accounts completes exactly once and shows a receipt |
| Device / OS | One exact configuration per run, named in the case (for example: a mid-range Android model on the previous major OS; an iPhone model on the current OS). Record the model and OS build |
| Network | Variant A: throttled 3G for the whole flow. Variant B: the app sends the transfer and the server accepts it, but its response is withheld; switch from Wi-Fi to cellular so the client retries the same request |
| Starting state | Upgraded from the version in production; signed in; two eligible accounts with known starting balances |
| Steps | 1 Open Transfers. 2 Pick the destination account. 3 Enter an amount under the daily limit. 4 Tap Confirm. 5 For Variant B, while the response is withheld, switch network so the client retries the request. 6 Return to the account view. |
| Expected | The retried request carries the same idempotency key and the same parameters, so the server records exactly one transfer. The app shows a receipt only once the server confirms, and the destination balance increases once |
| Failure paths | Amount over the limit is rejected with the right message. A timeout at step 4 shows a pending state, not a receipt, until the server answers |
4. Setup of Testing Environment
The testing environment is the code, devices and data the tests run against, and its configuration depends on the app in question. Stand up the backend or staging the cases need, the test accounts and seeded data, and the network profiles; wire the smoke suite into CI; and record the build and configuration each run used.
Part of that configuration is deciding what your tests run on. “Emulator”, “simulator”, and “real device” get used interchangeably, but they are three different things and they prove three different levels of confidence.
- An emulator runs an Android system image on your machine, hardware-accelerated on a modern host, so it is fast enough for daily development and can exercise OS-version behavior, layout and most failure handling.
- A simulator runs the iOS environment on top of your machine’s operating system. It starts fast and is useful during development, and because it is not iOS hardware it sits further from real device behavior.
- A real device is physical hardware running the same build your users will install.
| What you are validating | Virtual device | Real device |
|---|---|---|
| Layout, screen sizes, basic navigation | Sufficient | Not required early |
| Battery and CPU consumption | Not reliable | Required |
| Camera, GPS, biometrics, NFC | Simulated only | Required |
| Real network latency and signal loss | Simulated only | Required |
| Thermal throttling and sustained memory pressure | Partial: low-memory warnings can be simulated, thermal cannot | Required |
| Setup cost and maintenance | Low | Higher, unless accessed via a device cloud |
The practical rule: anything that touches physical hardware needs physical hardware. A suite that is green only on virtual devices has not tested battery drain, sensor behavior, biometric authentication, or camera capture, and those are the areas where production defects concentrate.
5. Manual and Automated Testing
Three layers, each starting as early as it can. Developer tests (unit and instrumentation) run as the feature is built, on every commit, in the test pyramid Android’s testing guidance describes. The first QA pass on a new flow is manual and exploratory, on a real device, with the tester free to go off-script. That is where the layout, typing, back-navigation and permission bugs surface that no suite was written to catch yet. On a real-device cloud that runs accessibility and performance validations during the session, those findings and the device metrics come out of that same manual pass.
Then the paths that stop changing are automated under the policy from step 1, and the automated suite takes over the repetition: smoke on every build and before any broader run, regression on every release candidate, compatibility across the device list. Two checks belong in the manual pass that teams forget: permissions (the app asks for nothing it does not need, works when a permission is denied, and recovers when it is granted later) and the first launch on a device that is low on storage.
6. Usability and User Interface Testing
Usability testing confirms the app is easy to use, effective, and satisfactory for end users. UI testing confirms they can navigate and operate the interface without effort. Accessibility belongs in this step rather than in a separate exercise at the end. Run the app with TalkBack enabled on Android and VoiceOver on iOS, and check three things: every interactive element is announced with a meaningful label, focus order follows a logical sequence that preserves meaning, and tap targets stay usable at the largest system font size. Layouts that look fine at default settings frequently collapse at 200% text scaling.
For many teams this is not optional: accessibility laws such as the Americans with Disabilities Act (ADA) can apply to apps, and the Web Content Accessibility Guidelines (WCAG) are the usual benchmark. Even where it is not mandated, it overlaps heavily with general usability: an interface a screen reader can navigate cleanly is usually one that is well structured for everyone.
7. Compatibility Testing
Run the agreed coverage for each tier across the device matrix from step 1 (see How to Choose Which Devices to Test On, later on this page): Tier 1 on every build, the full matrix on every release candidate, the targeted checks on Tier 3. The point is the behavior that changes with the device: a layout that breaks at one screen size, a permission prompt that behaves differently on one Android skin, an API an older iOS version handles differently. Run it on real devices, in parallel. The output is a per-device result grid and a list of OEM- and OS-specific defects for step 11. The method for building and maintaining the matrix is in our mobile compatibility testing guide.
8. Performance Testing
Check the budgets you set in step 1 (cold start, key transitions, memory over a long session, battery drain) on representative devices and networks: a mid-range device on a throttled connection shows slow startup and memory pressure before a flagship on office Wi-Fi does. Users delete apps that eat storage, lag on the phone they own, or drain the battery on a normal day; none of that registers in a functional pass, which is why it survives to production. Losing your place after a phone call is different: that is a functional interruption check, written into the failure paths in step 3 and run in step 5. A manual session on a device cloud shows memory, CPU, network and battery live; the long runs that confirm a fix belong in automation. Our mobile performance testing guide covers the subtypes and tooling.
9. Security Testing
Run the security regression on every release, and a deeper pass whenever authentication, authorization, sensitive data or permissions change. The mobile-specific checks that belong at this step: secrets in protected storage (the Keychain on iOS; on Android, encrypted with keys the Keystore protects), never in plaintext or logs; all traffic over HTTPS with certificate validation; authorization enforced on every protected endpoint, with sessions that expire; and sensitive screens hidden from the app switcher. Scanners catch the known patterns; a tester working from the OWASP Mobile Application Security Verification Standard covers the business-logic and attack-path issues scans miss. The output is a findings list with severity, plus the evidence an auditor needs in regulated industries. Our mobile app security testing guide carries the threat model, the full checklist, and the root and jailbreak controls.
10. Usability and Beta Testing
Step 6 evaluated usability and accessibility with your testers. This step puts the release candidate in front of people outside the team. Beta tests the candidate with a wider cohort on devices you do not own, in networks and locales you did not configure, with people who have not read the spec. User acceptance testing (UAT) is narrower and more formal: the people who asked for the feature confirm it meets the business acceptance criteria the cases in step 3 were written to. Run both before launch, not instead of the steps above; beta finds what your matrix missed, it does not replace the matrix. The output is a UAT sign-off and a beta feedback list that goes into step 11 on the same severity and priority scale as internal defects.
11. Feedback Integration and Iterative Testing
Finding a defect is only useful if it reliably reaches the person who can fix it. Every issue coming out of the previous steps needs to be logged with enough context to reproduce it: device and OS version, build number, exact steps, and a screen recording where the behavior is visual, then prioritized so the team knows what blocks the release and what can wait.
| Severity | What it means | Example |
|---|---|---|
| Blocker | Critical functionality unavailable, no workaround | App crashes on launch, or checkout cannot complete |
| High | Critical functionality impaired, workaround exists | Payment fails on first attempt but succeeds on retry |
| Medium | Functional issue with a straightforward workaround | A filter returns wrong results unless applied twice |
| Low | Cosmetic, no functional impact | Truncated label, minor spacing inconsistency on one device |
Severity (how bad) and priority (how soon) are separate calls; a cosmetic defect on the sign-in screen can be low severity and high priority.
Track these in whatever the development team already uses (Jira, Azure DevOps, Linear) rather than a separate QA-only system, because a defect in a system developers do not open is a defect nobody is fixing. Test results that carry device logs, network logs, and session video attached to the issue remove most of the back-and-forth about whether a bug is reproducible.
Then iterate. Fixes come back into the suite as retests, and anything that broke once earns a permanent regression test so it cannot break again unnoticed. Beta and usability feedback from step 10 feeds the same queue: user-reported problems get triaged on the same scale as ones your own testers found, which is what stops real-world friction from being filed as an opinion and ignored.
12. End-to-End Testing Before Final Release
Run the full user journeys as the user would, app and backend together, on the build you intend to ship, on Tier 1 devices at minimum: sign up, sign in, the core transaction, the upgrade from the version in production. This is also where regression closes: the suite that grew in step 11 runs one last time against that build. Record the exact build you approved. If it changes after that run, assess the impact and rerun the affected tests and the required release checks before it ships; a smoke pass alone does not cover a changed build. In a continuous integration and delivery (CI/CD) pipeline this step is the release gate rather than a sprint: the release candidate is the build that passed the gate. Then make the decision against the exit criteria below. If it is No-Go, fix, rerun the affected cases, and decide again.
Where the Testing Process Fits in an Agile Release Cycle
Laid out as twelve steps, the mobile app testing process can read like a phase that happens once, after development finishes. In practice it runs continuously, and most of it runs more than once per release. Agile sprints compress the window for testing to the point where preparing test cases has to happen alongside development rather than after it, and continuous integration means code arrives in small, frequent increments instead of one large drop.
What changes is not the steps but their frequency. A useful way to split them:
| Cadence | What runs | Scope |
|---|---|---|
| On every commit or nightly build | Local unit tests on CI hosts; automated smoke on Tier 1 devices (step 5 in miniature) | Tier 1 devices, minutes not hours |
| Every sprint | Exploratory and usability passes on new features, test case design for what is being built (steps 3, 5, 6) | Whatever the sprint touched |
| Every release candidate | Full regression, compatibility, performance, security and end-to-end passes (steps 5, 7 through 9 and 12) | The release device matrix, each tier at its assigned coverage, in parallel |
| Before a major launch | Beta, extended device coverage, full end-to-end validation (steps 10 and 12) | Widest matrix, including edge devices |
One caution worth building in early: tests that pass on a developer’s machine and fail in CI are usually failing on environment differences rather than test logic. System animations left enabled, a missing set of Google Play services, an unpinned locale or timezone, and no clean state between runs are the usual culprits. Check those before you start editing the test.
How to Choose Which Devices to Test On
Step 1 asked for a device list before the first test case is written. Here is how to build it. The list is the decision the rest of the mobile app testing process rests on, and it is the one teams most often make by instinct, usually by reaching for whatever handsets are already in the office. The result is a suite that passes on three flagship phones and ships a crash to everyone else.
Build the list from your own install-base analytics rather than a published “most popular phones” ranking. A general market list describes the market; your analytics describe your users, and those two sets overlap less than you would expect. Work through four passes.
- Coverage. Sort your active devices by user count and take models from the top until you have accounted for roughly 80% of installs. For most consumer apps this is a surprisingly short list.
- OS spread. Add the current and previous iOS versions. Android needs wider coverage, the newest release plus the two or three before it, because Android upgrades reach users far more slowly and unevenly than iOS ones.
- Risk edges. Add a low-RAM Android handset, a tablet, and a foldable or large-screen device if your analytics show any usage at all. These surface memory and layout defects that flagship phones never reveal.
- Vendor skins. Add at least one device running a manufacturer skin such as One UI, HyperOS, or ColorOS alongside stock Android. Permission prompts, background execution limits, and notification behavior all differ from stock, and those differences break apps.
For most teams this lands somewhere between eight and fifteen device-OS combinations per release, with a wider set reserved for major launches. Not every combination needs to run on every build, so tier them:
| Tier | What it covers | When it runs | Where it runs |
|---|---|---|---|
| Tier 1 | Your single highest-usage Android device and iPhone, on the current OS | Every build | Real devices, automated smoke suite |
| Tier 2 | The rest of your 80% coverage list, plus the previous major OS on each platform | Every release candidate | Real devices, full regression in parallel |
| Tier 3 | Low-RAM Android, tablet, foldable, one vendor skin | Every release candidate, targeted checks | Real devices: layout, memory, and the permission, background-execution and notification behavior vendor skins change |
| Tier 4 | Screen sizes and OS versions you only need to eyeball during development | Ad hoc | Emulators and simulators |
Review the matrix once a quarter and after each major OS release; device usage moves. The full method for turning the list into coverage across OS versions and screen sizes is in our mobile compatibility testing guide.
If holding that range of hardware in-house is impractical, and for most teams it is, a mobile device cloud gives you the same devices on demand without the procurement and upkeep.
How to Know When Testing Is Done
Testing does not end when the team runs out of time; it ends when agreed exit criteria are met. Define those criteria at the start of the mobile app testing process, in step 1, and hold the release to them at the end. A workable set for most mobile teams:
- Every planned test case has been executed on the agreed device matrix, with any skipped combinations documented and justified.
- No open blocker or high-severity defects remain. Medium and low defects are logged, triaged, and explicitly accepted for this release rather than silently carried.
- Performance meets the benchmarks set in planning: cold start, key screen transitions, memory stability over an extended session, and battery drain, measured on a mid-range device, not a flagship.
- Security checks have passed: credentials and tokens in protected storage (Keychain on iOS; Keystore-protected encryption on Android), all traffic over HTTPS, no secrets in logs or configs.
- The upgrade path from the currently published version has been verified, with user data and sessions intact.
Treat the list as a gate, not a scorecard. Every criterion met, and every critical journey passing on the approved build, is a Go. Any one missed is a No-Go, and the fix is to resolve it and rerun the affected cases, not to argue the criterion down on release day. The one legitimate exception is a medium or low defect the product owner accepts in writing for this release; that is a decision, recorded in the release report, and it never applies to a blocker, a high, or a critical journey.
Close with a short release report the whole team can read: which devices and OS versions were covered, what was tested, how many cases passed and failed, which defects are shipping and why, and a clear recommendation on whether the build is ready. This is also test closure: archive the results, and capture what the cycle taught you so the next one starts further ahead than this one did. If you want an outside read on where your process sits today, the Mobile Maturity Assessment gives you a report and a six-month plan.
After Release: What Production Tells You
The mobile app testing process does not end at the release report. The first two weeks in production are the one test environment you cannot build, and they answer the questions the matrix could not. Name who watches, what the thresholds are, and who gets paged when one is crossed. Then route each signal back into the process:
- Crash-free rate, application not responding errors (ANRs) and hangs by device, OS version and app version. A configuration that fails more than the rest and is not on your matrix goes on it next cycle (step 1).
- Devices in your analytics that you did not test on. A new flagship or a fleet refresh shows up here first; it is a reason to rerun compatibility (step 7) on that device now, not to wait for the next OS release.
- Performance in the field against the budgets from step 1: cold start and key transitions on real networks. Diagnose a field regression before changing the lab setup; it may be the build, the backend or the device.
- Reviews and support tickets in the first week, triaged on the same severity and priority scale as step 11. ‘It lost my place after a call’ is an interruption defect, not an opinion.
A hotfix runs steps 5, 11 and 12 in miniature: reproduce on the failing configuration, fix, retest on that configuration plus the affected coverage, smoke, ship, then verify the fix in production. A severe regression escalates immediately rather than waiting for the next cycle. Skipping the mobile app testing process for a hotfix is how one crash becomes two.
Mobile App Testing Process FAQs
How long does the mobile app testing process take?
It depends on the size of your device matrix and how much is automated. A first full pass on a medium-complexity app typically takes one to two weeks of dedicated QA effort. Once automation is in place, a regression suite running in parallel across a device cloud finishes in minutes, while the same coverage run by hand across physical devices still takes days.
How many devices do I need to test on?
Fewer than most teams expect. Build the list from your own install-base analytics until you have covered roughly 80% of users, then add a low-RAM handset, a tablet, and one vendor skin. For most consumer apps this lands between eight and fifteen device-OS combinations per release.
Which steps of the mobile app testing process can run on emulators?
The early ones. Layout checks, navigation, OS-version behavior and developer tests in steps 3 to 5 run well on emulators and simulators and give fast feedback. From step 7 on, the result depends on the device: performance, battery, thermal behavior, biometrics, camera and real network conditions only mean something on real hardware. Our What Is Mobile App Testing guide makes the full case.
Which steps should be automated and which stay manual?
Automate what is stable and repeats: regression suites, cross-device compatibility, and anything running on every build. Keep humans on exploratory testing, usability, and flows that resist scripting: biometric prompts, camera capture, complex gestures. A practical rule is to start a new feature with manual exploratory testing and automate the paths once they stop changing.
Who owns the mobile app testing process?
The whole delivery team, in practice. QA engineers design and run the suite, developers write unit and instrumentation tests alongside the feature code, and a product owner signs off on release readiness against the agreed exit criteria. Treating testing as something handed to QA at the end is what produces the crunch this process is meant to avoid.
What are the stages of the mobile app testing process?
This guide groups the twelve steps into four stages: plan (scope, device list, exit criteria, test design), set up (devices, data, pipeline), test and fix (the manual and automated passes, the specialized types, triage and retest), and decide (end-to-end on the approved build, the exit criteria, Go or No-Go). Other guides count differently; the stages matter less than having an output and an owner for each step.
When should the mobile app testing process start?
At the same time as development, not after it. The mobile application testing process starts when the first feature does. Test cases are written against the acceptance criteria while the feature is being built, the device list is set before the first build, and the automated smoke suite runs on the first commit that produces an installable app. The crunch at the end of a release is what happens when testing starts at the end.
For what mobile app testing is and the types it covers, start with our What Is Mobile App Testing guide.
