Mobile E-Commerce App Testing: What’s Different and What to Check

Reading Time: 12 minutes

Last updated: September 9, 2026

This is a practical guide to testing mobile e-commerce apps. It covers what e-commerce testing is, how the process works, and what changes when you move from a website to a native app. It includes device and OS coverage, in-app payments, push notifications during checkout, interrupted checkout sessions, and low-end Android behaviour. Written for QA engineers and tech leads who own release quality for a shopping app.

A mobile shopping app fails in ways a website never does. A phone call arrives during payment. The user switches to another app and comes back 2 minutes later. Android kills the app in the background to free memory. None of these are bugs in your code, but all of them can lose a sale.

A lot of test plans miss them. Teams port their web checklist to mobile, add a few screen sizes, and call it done. The result is a suite that passes while real users drop out of checkout.

The gap shows in the numbers. Baymard Institute benchmarked 138 major US and European mobile sites and found none rated “good” for user experience, with 62% rated mediocre or worse. Their mobile e-commerce UX research also notes that mobile often makes up around half of all traffic on e-commerce sites, yet converts at a much lower rate than desktop, in some cases less than half.

Our guide covers what to test and how. It does not cover tool selection or building an automation framework from scratch.

What Is E-Commerce Testing?

E-commerce testing checks that a shopping product works correctly across the full buying journey: finding a product, adding it to a basket, paying, and getting confirmation.

It covers more than screens and buttons. A complete scope includes:

• Catalogue and search. Filters, sorting, stock status, and product detail pages (PDPs).
• Basket and pricing. Quantity changes, promo codes, tax, shipping, and currency.
• Checkout and payment. Card entry, wallets, authentication, and order confirmation.
• Account flows. Registration, login, guest checkout, saved addresses and cards.
• Post-purchase. Order history, returns, refunds, and email or push confirmations.
• Non-functional areas. Performance, security, accessibility, and localisation.

The money paths matter most. A broken filter annoys a shopper. A broken payment step loses the order and often the customer. Our e-commerce testing services page covers how this scope maps to platforms like Shopify and Magento.

Key takeaway: Treat e-commerce testing as a risk-ordered scope across the whole buying journey, with payment and basket at the top, and everything else ranked below them.

Why Test E-Commerce Websites?

Because errors in the buying flow cost real revenue, and shoppers rarely come back to try again.

Baymard’s research on why US shoppers abandon checkout found that 17% left because the website had errors or crashed. Another 17% said the checkout was too long or complicated. You can read the full breakdown in their cart abandonment research. Both of those causes sit inside QA’s remit.

Websites and native apps share this risk, but they do not share failure modes. A browser tab keeps running when a call comes in. A native app can be suspended, or killed outright. That difference drives most of what follows.

The basics still apply to both. Broken search, silent form errors, and wrong tax on the basket cost you orders on any platform, and our list of common e-commerce platform mistakes is a good cross-check before you start on the mobile-only work.

Web vs Native Mobile App Testing

Area	Web (mobile browser)	Native mobile app
Environment	Browser handles rendering; you test browser versions	OS handles the app process; you test OS versions and OEM builds
Session state	Held in cookies and server session; survives most interruptions	Held in app memory; lost if the OS kills the process
Interruptions	Tab stays alive during a call; page usually intact	App moves to background; may be suspended or terminated
Payments	Redirect or iframe in the browser	Native SDK, wallet sheet, or redirect that leaves and re-enters the app
Updates	New version live for everyone at once	Users stay on old versions for months; you test several at once
Notifications	None during checkout	Push can arrive at any point, including mid-payment
Memory limits	Browser manages memory	App has a per-process limit; heavy images can trigger a kill
Offline behaviour	Page fails to load	App stays open with stale data; needs explicit handling
Distribution	Deploy and done	App store review, staged rollout, forced update logic

The right-hand column is where mobile test effort belongs. Everything in the left column you already know how to test. For a wider view of the testing types involved, see our guide to mobile app testing types.

How Does E-Commerce Software Testing Work?

The process runs in 5 stages. Teams often do stages 1 and 4 well, and skip stage 2.

1. Map the risk. List the user journeys, then rank them by what a failure costs. Payment, basket, and login sit at the top. Marketing banners sit at the bottom.

2. Set severity rules before you find bugs. Agree what blocks a release. Doing this in advance stops the argument happening at 6 pm on release day.

3. Build the coverage. Manual exploratory testing on the risky paths, automated regression on the stable ones, and a real-device matrix for the rest.

4. Run it in CI. Smoke tests on every build, full regression before release, and results that say whether it is safe to ship.

5. Watch production. Crash rates, checkout funnel drop-off, and payment failure rates per device and OS version.

Severity Levels for E-Commerce Defects

Severity	Example of a defect	Action
P0	Duplicate payment charged; checkout unavailable; basket reset after a phone call	Blocks release
P1	Discount calculated incorrectly; PDP loads slowly on 3G	Fix before release
P2	Product image does not zoom; wrong font on one OEM device	Next sprint

Note where the basket reset sits. Losing a basket after an interruption is a P0, because the user has already decided to buy and you have lost the sale. Many teams file it as P2 because it looks cosmetic.

Key takeaway: Agree the severity table with product and engineering before your first release, not during one.

How to Test Mobile E-Commerce Apps

5 areas separate a mobile test plan from a web one.

1. Device and OS coverage

Pick devices by what your users actually hold, not by what is new. Pull the device and OS breakdown from your analytics, cover the top 80% of sessions, then add one deliberately weak device. 

At QA Madness, every e-commerce device matrix starts from the client’s own analytics rather than a generic top-20 list, because the shape of the audience differs a lot between a fashion retailer and a B2B parts catalogue.

Test at least:

• Current and previous major iOS and Android versions
• One low-RAM Android device (see the section below)
• One large screen and one small screen
• At least 2 Android skins from different OEMs, meaning the handset makers who ship their own version of Android, since Samsung, Xiaomi and Google builds differ in keyboard, back-gesture and notification behaviour
• The oldest app version you still support in the store

OS compatibility is more than “does it launch.” 4 things break most often across versions:

• Permissions. Notification and tracking prompts changed behaviour in recent OS releases. Check the app still works when the user says no.
• Back navigation. Android’s predictive back gesture behaves differently by version and OEM. Test that back from the payment screen does not silently cancel an order.
• Keyboards. Third-party keyboards can block the pay button or break autofill on card fields.
• System font and display size. Users of large accessibility text sizes are common in retail. Check the checkout button is still reachable.

Old app versions deserve their own line in the plan. Users update slowly, and the version from six months ago is still taking orders. Test the oldest one you support against today’s live API.

2. In-app payments and wallets

Wallets are now the main way people pay online. Worldpay’s Global Payments Report 2026, based on a survey of more than 63,000 shoppers across 42 markets, found digital wallets account for 56% of global e-commerce transaction value.

That changes the test scope. Card form validation is no longer the main event. Check:

• Apple Pay and Google Pay sheets, including cancel and dismiss
•  Saved cards, including an expired card and a card that fails
• Wallet with no cards set up
• Currency and amount shown in the wallet sheet matching the basket
• Double-tap on pay, to confirm you cannot create two orders
• Refunds and partial refunds against the original payment method

Duplicate charges deserve their own test pass. They are the worst defect a shopping app can ship, and they usually appear when a retry happens after a timeout.

If you sell in the UK or the EU, strong customer authentication rules mean many card payments trigger a 3DS challenge, so the challenge path is a main flow rather than an edge case. And if your app touches raw card data at any point, that brings PCI DSS scope with it. Most teams avoid this by handing card entry to the provider’s SDK or hosted fields, which is worth confirming before you plan the test scope.

3. Push notifications during checkout

Push during checkout is a real failure path and almost nobody tests it. Send yourself a notification while a payment screen is open, then tap it.

3 things to check:

• Tapping the push takes the user away. Does the app return to the same checkout step, with the basket intact?
• Does the push arrive but leave the payment sheet on top, so the user cannot dismiss it?
• If the notification deep-links to a different product, does the in-progress order survive or vanish?

4. Network conditions

Test on throttled 3G, on a flaky connection that drops mid-request, and on airplane mode. The question is always the same: does the app tell the user what happened, and can they recover without starting again?

5. Session and login state

Check what happens when a token expires during checkout. The app should refresh quietly or send the user to login and then back to the same step, with the basket preserved.

Scenarios to Test if Checkout Interrupted by a Phone Call: Scenarios to Test

At QA Madness, interruption scenarios are the gap we most often find when auditing an existing e-commerce test plan, and they explain most cases of a mobile shopping basket lost after a phone call.

A call, an alarm, or a switch to another app all move your app to the background. What happens next depends on the OS and on how much memory the device has.

Phone call during a 3DS2 challenge

When a card needs extra authentication, the flow depends on the integration. EMVCo’s own description of the 3-D Secure challenge flow states that a browser flow opens an iframe, while an app-based flow passes the relevant data to a 3DS SDK. Some issuers also use out-of-band authentication, where the shopper approves the payment in their banking app.

Each of those breaks differently when a call arrives:

• SDK challenge, call arrives. Adyen’s Android SDK documents that when doChallenge runs, control of the app passes to the 3DS SDK, and that the challenge carries a timeout supplied in minutes. Adyen’s own sample code uses five minutes. Test a call longer than that timeout and confirm the app handles the timeout result rather than hanging.
• Out-of-band, the user switches to their banking app. The user leaves your app entirely. Test that your app is still in the same order when they return, and that you do not create a second order.
• Redirect flow, user returns late. Confirm the return URL still resolves to the right order state.

Adyen publishes test cards for 3D Secure 2 that include challenge timeout cases. Use them rather than trying to force a real timeout.

Push notification during a payment redirect

If payment leaves your app and comes back, a push tapped in the middle of that round trip can drop the user somewhere else. Test the tap, and test dismissing it.

App sent to background mid-payment

Press home during the payment step. Wait thirty seconds, two minutes, then ten minutes. Return each time.

On iOS, Apple’s app life cycle documentation states that UIKit can disconnect a background or suspended scene at any time to reclaim resources. Apple also notes in its guidance on reducing terminations that the system terminates background apps when a foreground app needs more memory, and advises proper state restoration for exactly this reason.

To test it properly on iOS, Apple’s state restoration sample warns against force-quitting from the app switcher, because that deletes preserved state deliberately. Suspend the app with the home gesture, stop it from Xcode, then relaunch from Xcode.

Key takeaway: The pass condition for every interruption test is the same. The user comes back to the same step, with the same basket, and no duplicate order exists.

Low-End Android Device Testing

Low-RAM Android phones fail in ways flagship devices never will. Two failures matter for shopping apps.

Process death clears the basket

Android ranks running processes and kills the least important when memory runs short. Google’s process lifecycle documentation describes four levels, and says a cached process, which is what your app becomes in the background, is one the system is “free to kill as needed when resources like memory are needed elsewhere.” The same page warns that onDestroy() is not guaranteed to be called when the system kills a process.

That matters for the state. Google’s guidance on saving UI state is explicit: a ViewModel survives a configuration change but does not survive system-initiated process death. Saved state, via SavedStateHandle, and persistent storage both do.

So a basket held only in a ViewModel disappears when the user takes a five-minute call on a 3GB phone. The app relaunches to a clean screen. To the user, the basket vanished for no reason.

How to test it:

• Use ActivityScenario.recreate() in instrumented tests. Google documents this as the way to simulate the system destroying and recreating an activity.
• Turn on Don’t keep activities in developer options for manual runs. It destroys each activity as soon as you leave it, which surfaces state-loss bugs fast.
• For real memory pressure, Google documents a stress test using stressapptest pushed to the device via adb.

Run the same journey on each: add 3 items, go to checkout, background the app, come back. The basket should still be there.

Image-heavy product pages trigger memory kills

Product pages are mostly images, and images are the largest memory cost in most shopping apps. Google’s memory management overview notes that bitmap pixel data sits in the native heap on Android 8.0 and above, and that unoptimised image loading can push a process past platform memory thresholds.

Google also documents onTrimMemory, which the system uses to warn an app that memory is low so it can release cached bitmaps before the low-memory killer steps in.

What to test on a low-RAM device:

• Scroll a long category list fast, then open ten PDPs in a row. Watch memory in Android Studio’s profiler.
• Open a PDP with a large image gallery, zoom every image, then go back and forth ten times.
• Check the app responds to onTrimMemory by releasing image caches.
• Confirm images are sized for the device rather than downloading full-resolution assets to a small screen.

Keep one 3GB or 4GB device in the rack permanently. It will find bugs your flagship never shows. At QA Madness, a low-RAM Android handset sits in every e-commerce device set for exactly this reason.

Key takeaway: If the basket only exists in app memory, a low-RAM phone and a long phone call will eventually delete it. Persist it server-side or on disk, then test that the persistence actually works after process death.

Mobile E-Commerce App QA Recommendations

Eight things worth putting in place, in rough order of payback.

• Rank by money, not by screen count. Payment and basket first, everything else after.
• Agree the severity table early. Use Table 2 as a starting point and adapt it.
• Keep a deliberately weak device. One low-RAM Android phone catches more real bugs than three flagships.
• Make interruption testing a standard suite. Call, push, background, and network drop, run against checkout every release.
• Test payments with provider test cards. Including declines, timeouts, and 3DS challenge cases.
• Automate the stable paths, explore the new ones. Regression suites are for flows that have settled. Appium covers both platforms from one suite; Espresso and XCUITest go deeper per platform. Our automated testing services page covers where that line usually sits.
• Watch production per device. Crash-free rate and checkout drop-off, broken down by OS version and OEM.
• Test the old app versions you still support. Users update slowly, and your oldest supported version is still taking orders.

None of these needs a big budget. Most of it is a device, a test card, and someone willing to ring the phone at the wrong moment.

FAQs

How do I test a checkout interrupted by a phone call?

Start the checkout, place a real call to the device, end it, and return to the app. Check three things: the user lands on the same step, the basket is intact, and no duplicate order was created. Repeat with the call lasting longer than your payment provider’s challenge timeout. Do this on a low-RAM Android device as well as a flagship, because the outcome differs.

Why does the shopping basket disappear after a call on Android?

Usually because the basket lives only in memory. Android kills background processes when memory runs short, and a ViewModel does not survive that. Google’s saved-state documentation recommends SavedStateHandle or persistent storage for anything that must survive process death. Persist the basket server-side or on disk and the problem goes away.

What should a mobile e-commerce device matrix include?

Take the top 80% of sessions from your analytics, then add one low-RAM Android device and your oldest supported app version. Cover current and previous iOS and Android major versions, two OEM Android skins, and one small screen. Our mobile app testing types guide goes deeper on building the matrix.

How much mobile e-commerce testing should be automated?

Automate stable, repeatable paths such as regression on catalogue, search, and login. Keep payments, interruptions, and new features in manual and exploratory testing, because they change often and need judgement. A common split is automated smoke on every build, automated regression nightly, and manual exploratory each sprint.

How do we test in-app payments without real money?

Use your payment provider’s test environment and test cards. Every major provider publishes cards that trigger declines, insufficient funds, and 3D Secure challenges, including timeout cases. Test the unhappy paths deliberately: a decline, a timeout, a cancelled wallet sheet, and a double tap on the pay button.

Should we hire an external QA team for a shopping app?

Not always. It depends on release cadence and device coverage. External teams help most when you need a wide real-device matrix, peak-season coverage, or payment testing experience you do not have in-house. If your app ships monthly and you already own a decent device set, an internal tester will usually do. If you are comparing providers, our review of the best QA testing companies in 2026 sets out what to look for.

Where to Start

Mobile e-commerce testing is web testing plus everything the operating system does to your app while the user is trying to buy something. The extra work sits in a small number of places: device and OS coverage, wallet payments, interrupted sessions, and low-memory behaviour.

If you only add one thing this sprint, add interruption testing to your checkout suite. Place a call during payment on a low-RAM Android phone and see what survives. It is a ten-minute test that regularly finds a P0.

Need people who have run this on real shopping apps? You can hire QA engineers from QA Madness and start within 1 to 3 business days. QA Madness provides independent software testing for SaaS, e-commerce, and enterprise software teams across the UK, Europe, and North America, staffed exclusively with Middle and Senior ISTQB-certified engineers.