Mobile Testing: Did the Order Go Through?

A customer taps “Place order” and waits for the receipt. Nothing appears. After watching the loading screen for a while, they close the app and reopen it.

The order may already exist. There’s no receipt on the screen, and their items are still in the basket. They try once more.

The support team may later have to work out why two orders arrived. Did the first request reach the server? Was payment taken? The customer needs to know whether they’ve bought anything before being asked to submit another order.

Mobile testing can account for that uncertainty. A checkout tested over a steady connection won’t show what the customer sees when reception drops just after payment or when they return to an expired session.

There’s no need to invent an unusual failure to explore this. The next checkout test could include closing the app while confirmation is loading, then reopening it to check whether the purchase appears.

Following the Order After Checkout

A confirmation message provides something visible to check. A warehouse employee needs to find that same order in the queue before anything gets packed.

If the handoff fails, the customer could be waiting for a delivery that the warehouse knows nothing about. An address has a similar journey: changing it on the phone should also update it when the account is opened elsewhere. And when a card is declined, clearing the basket creates extra work for someone who was ready to pay.

Mobile app testing should follow these actions far enough to establish their outcome.

For checkout, the tester can look for the order in the customer’s history and compare it with the purchase and payment records. The team also needs to agree on the expected outcomes of failed purchases.

Simulate a declined payment during a test, then try another card. Does the basket survive? For a successful payment, close the app before the receipt appears and look for the purchase after reopening it. The customer shouldn’t have to place a second order to discover that the first one worked.

These questions help teams decide what a mobile test should prove. “The button worked” leaves too much of the transaction unexplained.

The Order Was Saved. The Phone Is Still Waiting

With no connection at all, the app can tell the customer it cannot submit the order. If the connection drops during a purchase, the warning needs more careful wording. “Try again” could be poor advice if the order has already been accepted.

The server could save the purchase and send its reply just as the phone goes out of range. That reply never arrives. The customer keeps watching the loading screen. When reception returns, the app has to retrieve the order’s status before offering another attempt.

Saving a delivery address is a simple example. An entry that never reached the server still needs to be submitted. An entry already saved should appear the next time the customer opens their address list.

While reception is down, either scenario may leave the customer looking at the same unhelpful loading screen.

To test mobile applications under these conditions, use the same address change for two runs. Disconnecting before submission gives one result to examine: the change should not yet be on the server. For the other run, allow the service to save the address but prevent its reply from reaching the phone. Once the connection is restored, inspect the saved address and what the app tells the customer.

A failure message beside an address that was successfully saved deserves investigation. Following its instructions might mean submitting the same change again.

Leaving Checkout to Check a Message

The customer needs the postcode from a message, so they switch apps. While they are there, they answer the sender. Checkout waits in the background longer than they intended.

On returning, they may land halfway through the form or find themselves signing in again.

Mobile application testing needs to cover that return. Before switching away, leave a recognizable instruction in the delivery field, such as “Use the side entrance.” When checkout reopens, look for that wording and check whether the basket’s availability information has been refreshed.

Remembering the instruction is useful. Remembering an expired delivery offer would cause trouble.

An item available when the customer opened the basket may have sold out. A collection slot could have passed. The customer needs to see those changes while they can still amend the order, before payment is taken.

Session expiry adds another decision. Signing back in might restore the items while requiring a fresh payment authorization. The checkout team needs to specify what is kept, what is checked again, and what the customer must re-enter.

Without that agreement, a tester who finds an empty payment field cannot tell whether it is intentional or a fault.

Choosing the Phones for the Test

A list of available phones is a starting point. Choosing which ones to use requires some knowledge of the customers.

The team can review usage figures alongside its supported operating systems and previous device-related faults. A device used by a substantial share of customers deserves attention. So might an older supported phone that has previously exposed a performance problem.

Layout checks need some variation as well. Android’s guidance includes rotating or resizing the app during use. Try it with a partly completed form: the fields, entered values, and remaining controls all need checking after the layout changes.

The practical questions are familiar. Can someone reach the final field when the keyboard is open? Does a longer error message push the submit button out of view? Can a customer using larger text still read the delivery options and select one?

A screenshot taken before the keyboard opens won’t reveal every difficulty someone has filling in the form.

On their own, the terms mobile testing and mobile application testing tell a reviewer little about device coverage. A useful report names the phones and records what happened on each, including the settings used, such as larger text. That makes gaps easier to discuss before release.

Automation Needs an Outcome to Check

A checkout journey repeated across builds is a reasonable candidate for automation. Suppose a revised postcode field rejects the address saved on an existing account. An automated checkout using that account could catch the problem before release.

In mobile application automation testing, completing the taps is only part of the test. For this purchase, the test could check that the order contains two specified products, one delivery charge, and the collection slot chosen at checkout.

A receipt heading could appear even with the wrong amount underneath it. Checking the resulting order gives the team stronger evidence about what the sequence accomplished.

Repeated runs can also leave changes behind. A previous run could have changed the account’s default address. An offer used in the original test might no longer be valid. Recording the account’s starting state helps the developer determine whether a failure comes from the application or from changes to the test account.

Some checks also benefit from someone trying the app for themselves. Automation can establish that a payment error appeared. Trying to continue from that message may reveal a different problem: it asks for another payment attempt without saying what happened to the first.

That finding belongs alongside the automated results.

What Will a Failed Run Tell You?

Mobile automation testing tools deserve evaluation against the application and the team’s working practices.

Can the tool exercise the required journeys on supported devices? Can testers prepare the necessary data? What evidence would be available to someone investigating a failed run?

An Appium test sends instructions through a driver to interact with the app. Before relying on it for checkout, the team has to get the required devices connected and the driver working. Later, a renamed or replaced control may require a test change. A failed run therefore needs investigation before it is treated as an application defect.

Access to devices and useful failure records can also influence the choice. QyrusAI’s Device Farm documentation describes automated execution on real devices with reports that include video recordings, device vitals, and Appium logs. Those records can help a team establish what happened during a failed run.

A recording might show the keyboard covering a control. Comparing the timing in the video with the available logs can help establish whether the attempted tap reached the app and whether a request followed. The developer can investigate that moment rather than repeat the entire checkout journey.

Customer Problems Give the Next Test Somewhere to Start

Support staff may hear about an interruption that nobody tried before release.

A customer switches to their messages, returns to checkout, and finds their address gone. Another finds an order in their history after receiving a failure message. The tester has a starting point: leave checkout at the same stage, then return and see what remains.

The saved records help narrow down the fault. Finding the address in the database would shift attention to what happens when checkout reopens. The follow-up test should therefore include leaving the form and returning to it; merely testing whether the address can be saved would miss the reported problem.

Support reports can gradually add to mobile testing coverage. A complaint about an expired sign-in could lead to a test that leaves a basket open until the session ends. A duplicate order could prompt another run with reception cut just after submission.

For that duplicate-order test, the return to the app matters as much as the interruption. The existing purchase should be easy to find, with enough detail for the customer to recognize it and know they have already paid.