Skip to content
QA Knowledge Hub

Test cases for a ride booking flow

Updated 2026-11-13 · 6 min read

A ride app mixes maps, real-time matching, payments and safety. These 34 cases cover booking, the wait for the driver, the trip, payment and receipts, safety, privacy and peak demand.

Assumes a rider app for booking cabs and auto-rickshaws in a city, with fare estimates, driver matching, a start code the rider tells the driver, live trip tracking, an SOS button, and payment by UPI, wallet or cash. A driver test app is available to accept, start and end trips. Fees, free-cancellation windows and waiting charges below are examples.

How to answer in an interview

Ask first: rider app, driver app or both; which vehicle types; upfront or estimated fares; is there peak pricing; what are the cancellation and waiting rules; how does the trip start (start code or not); which payment methods; and which safety features exist? Then follow the ride: booking, waiting for the driver, the trip, payment and receipt, and close with safety, privacy and peak demand.

Scope and test data

Example rules: free cancellation within 3 minutes of driver allocation; waiting charges after 5 minutes at pickup. Test rider [email protected] and 9000000001; test drivers with test vehicle numbers. Use simulated locations and recorded routes; do not track real people. GPS spoofing tests are run only on test devices in an authorised test. These are designed cases, not an execution report.

Booking

IDCategoryTest caseExpected result
D01FunctionalPickup from GPS, drop chosen from searchRoute shown; fare estimate for each vehicle type
D02BoundaryDrop a few metres from pickupMinimum fare shown, or booking blocked with a message, as specified
D03NegativeDrop outside the service areaClear message; booking not possible or marked as outstation
D04NegativeDeny location permissionPickup can still be typed or picked on the map
D05FunctionalMove the pickup pin on the mapAddress updates to the new point
D06FunctionalBook during simulated peak demand, if peak pricing existsHigher fare shown and accepted by the rider before booking
D07FunctionalApply a valid and an invalid promoValid one lowers the estimate; invalid shows a reason
D08FunctionalConfirm the bookingSearching state, then driver name, photo, vehicle number and arrival time
D09NegativeNo drivers accept within the timeoutClear message; no charge; option to try again
D10NegativeTap Book twice quicklyOne ride requested

Waiting for the driver

IDCategoryTest caseExpected result
D11FunctionalDriver drives towards pickup on a recorded routeCar moves on the map; arrival time updates
D12FunctionalCall and chat with the driver from the appConnects through a masked number or in-app chat
D13BoundaryRider cancels at 2 minutes 59 seconds and at 3 minutes 1 second after allocationFirst is free; second shows the fee before confirming
D14FunctionalDriver cancelsRider notified; new search offered; no fee for the rider
D15NegativeDriver enters a wrong start code, then the right oneTrip does not start on the wrong code; starts on the right one
D16BoundaryRider arrives 5 and 6 minutes after the driverNo waiting charge at 5 minutes; charge applied after, as specified

During the trip

IDCategoryTest caseExpected result
D17FunctionalShare the trip with a contactContact receives a live link that stops working after the trip
D18FunctionalChange the destination mid-tripNew route and fare estimate shown and accepted
D19FunctionalAdd a stop, if supportedStop added to the route; fare reflects it
D20FunctionalPress SOS in the test environmentReaches the configured emergency contacts or support with the live location, as specified
D21NegativeDrive through a simulated GPS and network lossTrip continues; distance after reconnect is sensible, not zero or doubled
D22NegativeKill the rider app mid-trip and reopen itTrip screen restored with the current state

Payment and receipt

IDCategoryTest caseExpected result
D23FunctionalDriver ends the tripFinal fare with a breakdown (distance, time, fees) matching the pricing rules
D24FunctionalTrip includes a toll or parking chargeShown as a separate line on the fare and receipt
D25FunctionalPay by cashDriver marks it collected; rider sees the trip as paid
D26NegativeUPI or wallet payment fails after the tripAmount shown as due; the next booking follows the specified rule
D27FunctionalOpen the receipt and the emailed copyCorrect pickup, drop, time, fare and tax details; sent to [email protected]
D28FunctionalRate the driver with one starApp asks for a reason; rating saved
D29FunctionalReport an item left in the cabSupport flow started; driver contacted without revealing either phone number

Privacy, security and performance

IDCategoryTest caseExpected result
D30SecurityAfter the trip ends, try to call the driver from the rider appMasked calling stops after the window the spec allows
D31SecurityChange the ride ID in an API call to another rider's rideAccess denied; no details returned
D32SecurityUse a mock location app on a test driver deviceDetected or flagged as the spec requires
D33PerformanceSimulate peak demand in one areaMatching time within the agreed limit; no driver assigned two rides at once
D34CompatibilityRun the full flow on a low-memory Android device and an older supported iOS versionCompletes without crashes; map remains usable

What to prioritise

Safety and money first: D15, D20, D13 and D16 (charge boundaries), D23 and D26. In an interview, the common mistake is to forget that two apps are involved: say which actions come from the driver app and how you would trigger them in a test.

Downloads

Quick answers

How do you test GPS-dependent features without driving around?

Use location simulation: mock locations on Android test devices, simulated routes in the iOS simulator or emulator, or the team's own route-replay tool. Keep a few real drive tests for things simulation cannot show, such as poor GPS between tall buildings.

Is the final fare supposed to equal the estimate?

Not always. Many apps give an estimate that can change with route, waiting time, tolls or destination changes; others lock an upfront fare. Ask which model the product uses and test both the normal case and every documented reason for a change.

Want a project you can show in interviews?

The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.