Test case library · Shopping, delivery & travel
Cab and auto booking covers setting a pickup and drop, comparing bike, auto and cab fares, meeting the driver, starting the ride with an OTP and paying at the end. It fails in the field when GPS puts the pickup on the wrong side of the road, when a network drop during the driver search books two rides, and when battery savers on budget phones stop trip sharing in the middle of a ride.
From the reviews. In ride-hailing and mobility apps, features that don't work were 10 of the 17 malfunction reviews, more than every other kind of malfunction put together.
Expected: The pickup shows your street or building, a fare estimate is shown before booking, and the confirmation shows the driver, vehicle number and a ride OTP.
Why a real phone: The pickup depends on a real GPS fix at your actual location.
Expected: The address label updates to the pin's new spot, and the driver app shows the dragged pin as the pickup, not the original GPS point.
Expected: The saved place fills in with its pin and label, and after the edit, new bookings use the updated pin.
Expected: Nearby matches come first, each suggestion shows its area or city so look-alike names can be told apart, and the chosen place appears on the map.
Expected: Each option shows a fare or fare range marked as an estimate, an arrival time and a seat count, and the detail view lists what the fare includes.
Expected: The driver's name, photo, vehicle number and model appear, the marker moves towards the pickup with a falling ETA, and an Arrived message shows at the pickup.
Expected: The ride starts only after the correct OTP, the status changes to On trip with the drop shown, and the OTP is no longer displayed.
Expected: The rider app shows Paid with the exact final fare, the UPI app shows one debit for that amount, and the driver app shows the payment as received.
Why a real phone: Needs a real installed UPI app and the switch out and back.
Expected: The rider app shows the final fare in large text before payment, then Paid in cash, and the receipt names cash as the method.
Expected: The wallet is debited by exactly the final fare, once, and the transaction list shows the ride with its date and amount.
Expected: Both show pickup, drop, distance, duration, each fare component, taxes as your app labels them, the payment method and the total charged, with times in IST.
Expected: The app says rides are not available there before you can book, and no fare is shown as if the ride were possible.
Expected: The search ends with a clear no drivers message and options to try again or pick another vehicle type, and nothing is charged.
Expected: The app says no cancellation fee applies, the ride shows as cancelled with ₹0 charged, and no fee appears on the next ride.
Expected: Before you confirm, the app shows the exact cancellation fee and why it applies. After cancelling, the same amount appears on the receipt or the next ride's bill.
Expected: The rider sees that the driver cancelled, no fee is charged, and the app searches again or offers to rebook with the same pickup and drop.
Expected: The first attempt shows as failed without marking the ride paid. The retry or cash payment settles the ride, and only one debit appears in the UPI app.
Why a real phone: The decline happens inside a real UPI app with a real UPI PIN.
Expected: The final fare is within the estimate shown, or each extra charge, such as a toll or waiting, is listed with its amount.
Expected: The rider app shows a waiting timer and a warning before charges start, and the receipt lists the waiting charge on its own line.
Expected: The app shows a revised fare estimate before you confirm, the driver app shows the new drop, and the receipt explains the change in fare.
Expected: The app suggests named pickup points near you, and the driver app shows the same point you chose.
Why a real phone: GPS error at large stations and airports needs testing at the real venue.
Expected: The other person gets an SMS with the driver, vehicle number and OTP, and the driver app shows that person's name as the rider.
Why a real phone: SMS delivery to the other phone depends on the real carrier.
Expected: The app uses the wallet for part of the fare and asks for the rest by another method, or asks you to choose another method. The balance never goes below ₹0.
Expected: The app shows the one ride that was booked, with its driver if assigned. It does not book a second ride or go back to searching for a ride already assigned.
Why a real phone: Real Wi-Fi to mobile data handover and lift dead zones drop requests unpredictably.
Expected: The ride OTP, vehicle number and driver name are still shown, and the screen says the phone is offline.
Expected: The app opens straight into the ongoing trip with the map, fare estimate, Share trip and SOS available, not the home screen.
Why a real phone: Only real low-RAM phones kill background apps this aggressively.
Expected: The rider map shows when the driver's location was last updated, instead of a frozen marker with an ETA that keeps falling.
Why a real phone: OEM battery savers on the driver's phone throttle background location in real use.
Expected: The pickup, drop and vehicle choice are kept, the fare is refreshed if it changed, and only one ride is booked.
Why a real phone: Needs a real incoming carrier call during the booking.
Expected: The app warns that your location may be inaccurate or asks you to confirm the pickup, rather than silently placing the pin on the next street.
Why a real phone: Weak indoor GPS fixes cannot be reproduced with a mocked location.
Expected: The shared link keeps moving with the ride, or clearly shows when the location was last updated, until the ride ends.
Why a real phone: Each OEM battery saver limits background location differently on real phones.
Expected: Booking still works with a typed or moved pickup, and on reopening the app asks again instead of showing a wrong default pickup.
Expected: The map stays responsive, vehicle markers update without the app freezing, and switching options does not reload the whole screen.
Why a real phone: Map rendering lag and memory pressure only appear on real budget hardware.
Expected: The ride does not start on any wrong OTP, the driver app limits repeated attempts, and the rider app still shows the ride as not started.
Expected: SOS is reachable in one or two taps during the trip, asks before calling anyone, and the test contact receives your live location and vehicle details.
Why a real phone: Alerts go out by real SMS or calls and use the phone's live GPS.
Expected: The link shows the driver's name, vehicle number and live location without your phone number, and stops showing location once the ride ends.
Expected: Each vehicle option is read with its fare and arrival time, and the OTP and vehicle number are read out digit by digit.
Expected: Each search finds the intended place, old and new city names return the same results, and Hindi suggestions show readable area names.
Expected: Fares, the OTP and the vehicle number stay fully visible, and the Book and Cancel buttons are not pushed off screen.
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 12 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.
Cancel at each stage: right after booking, after the driver accepts, after the free window and after the driver has arrived. Check that the app shows the exact fee and the reason before you confirm, and that the same amount appears on the receipt or the next ride's bill. Also check that a driver cancellation never charges the rider.
Check that the ride starts only after the driver enters the correct OTP, that wrong attempts are limited, and that the OTP disappears once the trip starts. Also check that the OTP is still visible when the rider's phone is offline, and that it reaches the right person when the ride is booked for someone else.
Pickup accuracy needs real GPS at real places, including indoors and at large stations. UPI payment at the end of the ride, SMS to another rider, SOS alerts and trip sharing under OEM battery savers also need real devices. Fare rules, cancellation fees and receipts can be checked with test accounts on an emulator.
36 cases · 15 need a real phone
40 cases · 13 need a real phone
37 cases · 12 need a real phone
40 cases · 12 need a real phone
36 cases · 10 need a real phone
39 cases · 14 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.