Test case library · Shopping, delivery & travel
Order tracking keeps a hungry customer informed from the moment the restaurant accepts the order to the knock at the door: statuses, a live map, an ETA and a way to reach the delivery partner. It fails in the field when battery savers on budget phones hold back the Arrived alert, when masked calls break on dual-SIM phones, and when GPS drift in dense lanes and high-rises puts the partner at the wrong gate.
From the reviews. Wrong or out-of-date information was food delivery apps' top malfunction (7 of 22 malfunction reviews), ahead of crashes and freezes (5).
Expected: Each status appears once, in order, with its time in IST, and the order moves from active to past orders after delivery.
Expected: The marker moves along roads towards your pin without jumping across buildings, and recentre fits both the partner and your location on screen.
Expected: The ETA is revised at each stage, never shows zero or a negative time while the food is still on the way, and switches to a running late message if it slips.
Expected: The card shows the partner's name with Call and Chat buttons. The partner's personal phone number is not shown anywhere.
Expected: The call connects to the partner, and the call log shows the masked or virtual number, not the partner's personal number.
Why a real phone: Masked calling runs over the real carrier network and needs a real phone call.
Expected: Messages appear on both sides in the order sent, with times, and no phone numbers are shown in the chat.
Expected: A notification arrives for each key status, such as preparing, picked up, arriving and delivered, close to the time each one happens.
Why a real phone: Push delivery to a backgrounded app depends on the real phone and its OS.
Expected: The tracking screen says the restaurant cancelled the order, gives the reason if one was entered, and shows a refund initiated for the amount paid.
Expected: The app shows a delay message and a new ETA instead of a frozen or expired timer, and offers help or contact options.
Expected: The order shows as cancelled, the partner card with its Call and Chat buttons disappears, and refund details appear for a prepaid order.
Expected: You are asked to accept the change or cancel, the bill drops by that item's price, and the partial refund amount is shown on the order.
Expected: The order screen offers a not received or help option on the order itself, and submitting it shows a reference and a status you can come back to.
Expected: You hear or see a message that the partner cannot be reached, and the app suggests chat or help. No personal number is revealed.
Why a real phone: How the masked line handles unreachable phones depends on real carriers.
Expected: The refund shows the amount, the original payment method, a status such as Initiated then Processed, and a reference you can match in the UPI app or bank statement.
Expected: The order shows as cancelled with no amount due and no refund line, so the customer is not told to expect money back.
Expected: The new partner's name and map position replace the old ones, and Call reaches the new partner, not the previous one.
Expected: The screen never moves back from a later status to an earlier one, and the timeline shows each status only once.
Expected: You can switch between both orders, each with its own map and ETA, and every notification names the restaurant or order it refers to.
Expected: The partner's marker ends at your pin, and the address text, landmark and pin all point to the same building.
Why a real phone: GPS drift between closely packed buildings only shows up at a real location.
Expected: Arrived shows when the partner reaches the gate, not while they are blocks away, and the tower, flat and gate details appear in the partner app.
Why a real phone: Indoor and high-rise GPS readings cannot be faked convincingly on an emulator.
Expected: Status, ETA and map catch up to the current state within a few seconds, without first showing stale information as if it were live.
Why a real phone: Real Android background limits decide whether the app is paused or restarted.
Expected: The app opens straight to that order's tracking screen with the current status, not the home screen.
Why a real phone: Notification delivery to a killed app and its launch vary across OEM skins.
Expected: The screen catches up to the current status, and you do not get a burst of stale notifications for steps that are already over.
Why a real phone: Real dead zones and delayed push delivery cannot be reproduced on an emulator.
Expected: Status text and ETA keep updating even if map tiles load slowly, and the screen says when the location was last updated instead of freezing.
Why a real phone: Real Jio, Airtel or Vi fallback to 3G or 2G is uneven, unlike throttling.
Expected: The call shows a masked number rather than the partner's own, and after the call the tracking screen is still open and up to date.
Why a real phone: Needs a real incoming carrier call while the app holds the screen.
Expected: The app or the dialer lets you call from the registered number, or the masked line still connects. The call never fails without an explanation.
Why a real phone: Masked lines often check the calling number; SIM choice needs real dual-SIM hardware.
Expected: Both notifications arrive before or as the partner reaches the door, with sound if the app's notification settings allow it.
Why a real phone: Each OEM battery saver restricts push and background work differently.
Expected: The app does not restart, the map stays responsive, and the battery drop is in line with a navigation app used for the same time.
Why a real phone: Battery drain, heat and memory pressure only show up on real budget hardware.
Expected: The lock-screen item shows the current status and ETA, updates as the order moves, and disappears or shows Delivered at the end.
Why a real phone: Lock-screen and ongoing notification behaviour differs by OEM skin and iOS version.
Expected: The tracking screen still updates inside the app, and the app explains once, at a sensible moment, that status alerts are off and how to turn them on.
Expected: The call does not reach the partner, and you hear a message that the order is complete or that the number is no longer active.
Why a real phone: Needs real calls over the masked line before and after delivery.
Expected: The link shows status, ETA and map only, with no phone numbers, full address or order items, and it stops showing live location after delivery.
Expected: The second account sees no tracking for the first account's order, and the old notification opens the login or home screen, not the order details.
Expected: Each item has a clear label, Call is read as Call delivery partner, and a status change is announced without you having to move focus.
Expected: Statuses, delay and refund messages and notifications are all in Hindi without truncation, and times are shown in IST in one consistent format.
Expected: The status timeline and ETA wrap without overlapping, and the Call and Chat buttons stay visible above the map.
They fit the Standard package: 10 × 45-minute sessions on 4 phones or browsers of your choice, up to ~50 cases, ₹18,999 + GST ($249), verified report in 3 business days. The 8 P1 cases alone fit Starter (₹9,999 + GST).
Download the CSV, pick the package at checkout and upload the file with your build. Testers run them on their own phones, on Jio, Airtel and Vi.
Use a test restaurant, a test panel and a test partner account on a second phone, so you can accept, delay, edit, reassign and cancel orders on demand. Push statuses in normal and unusual orders and watch the customer app. Keep a few real deliveries for GPS accuracy, masked calls and notifications, which a test panel cannot fake.
Many phone makers ship battery savers that stop background work and delay push messages once an app is swiped away or left unused. Behaviour differs across Xiaomi, Realme, Vivo, Oppo and Samsung skins, and can change with OS updates. Test with battery saver on and the app swiped away, and note how late each alert arrives.
That calls connect in both directions without showing either side's personal number, including in the call log. Check what happens when the partner is unreachable, when the customer's registered number is on the second SIM, and after delivery, when the masked line should stop connecting. Also check that a reassigned order calls the new partner.
40 cases · 12 need a real phone
39 cases · 12 need a real phone
39 cases · 14 need a real phone
38 cases · 13 need a real phone
36 cases · 10 need a real phone
37 cases · 10 need a real phone
99tests runs your cases, AI-generated ones included, on the phones, laptops and browsers your users own. Every finding is verified, serious bugs come with a screen recording, and each case comes back pass, fail, blocked or not run.