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
| ID | Category | Test case | Expected result |
|---|---|---|---|
| D01 | Functional | Pickup from GPS, drop chosen from search | Route shown; fare estimate for each vehicle type |
| D02 | Boundary | Drop a few metres from pickup | Minimum fare shown, or booking blocked with a message, as specified |
| D03 | Negative | Drop outside the service area | Clear message; booking not possible or marked as outstation |
| D04 | Negative | Deny location permission | Pickup can still be typed or picked on the map |
| D05 | Functional | Move the pickup pin on the map | Address updates to the new point |
| D06 | Functional | Book during simulated peak demand, if peak pricing exists | Higher fare shown and accepted by the rider before booking |
| D07 | Functional | Apply a valid and an invalid promo | Valid one lowers the estimate; invalid shows a reason |
| D08 | Functional | Confirm the booking | Searching state, then driver name, photo, vehicle number and arrival time |
| D09 | Negative | No drivers accept within the timeout | Clear message; no charge; option to try again |
| D10 | Negative | Tap Book twice quickly | One ride requested |
Waiting for the driver
| ID | Category | Test case | Expected result |
|---|---|---|---|
| D11 | Functional | Driver drives towards pickup on a recorded route | Car moves on the map; arrival time updates |
| D12 | Functional | Call and chat with the driver from the app | Connects through a masked number or in-app chat |
| D13 | Boundary | Rider cancels at 2 minutes 59 seconds and at 3 minutes 1 second after allocation | First is free; second shows the fee before confirming |
| D14 | Functional | Driver cancels | Rider notified; new search offered; no fee for the rider |
| D15 | Negative | Driver enters a wrong start code, then the right one | Trip does not start on the wrong code; starts on the right one |
| D16 | Boundary | Rider arrives 5 and 6 minutes after the driver | No waiting charge at 5 minutes; charge applied after, as specified |
During the trip
| ID | Category | Test case | Expected result |
|---|---|---|---|
| D17 | Functional | Share the trip with a contact | Contact receives a live link that stops working after the trip |
| D18 | Functional | Change the destination mid-trip | New route and fare estimate shown and accepted |
| D19 | Functional | Add a stop, if supported | Stop added to the route; fare reflects it |
| D20 | Functional | Press SOS in the test environment | Reaches the configured emergency contacts or support with the live location, as specified |
| D21 | Negative | Drive through a simulated GPS and network loss | Trip continues; distance after reconnect is sensible, not zero or doubled |
| D22 | Negative | Kill the rider app mid-trip and reopen it | Trip screen restored with the current state |
Payment and receipt
| ID | Category | Test case | Expected result |
|---|---|---|---|
| D23 | Functional | Driver ends the trip | Final fare with a breakdown (distance, time, fees) matching the pricing rules |
| D24 | Functional | Trip includes a toll or parking charge | Shown as a separate line on the fare and receipt |
| D25 | Functional | Pay by cash | Driver marks it collected; rider sees the trip as paid |
| D26 | Negative | UPI or wallet payment fails after the trip | Amount shown as due; the next booking follows the specified rule |
| D27 | Functional | Open the receipt and the emailed copy | Correct pickup, drop, time, fare and tax details; sent to [email protected] |
| D28 | Functional | Rate the driver with one star | App asks for a reason; rating saved |
| D29 | Functional | Report an item left in the cab | Support flow started; driver contacted without revealing either phone number |
Privacy, security and performance
| ID | Category | Test case | Expected result |
|---|---|---|---|
| D30 | Security | After the trip ends, try to call the driver from the rider app | Masked calling stops after the window the spec allows |
| D31 | Security | Change the ride ID in an API call to another rider's ride | Access denied; no details returned |
| D32 | Security | Use a mock location app on a test driver device | Detected or flagged as the spec requires |
| D33 | Performance | Simulate peak demand in one area | Matching time within the agreed limit; no driver assigned two rides at once |
| D34 | Compatibility | Run the full flow on a low-memory Android device and an older supported iOS version | Completes 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.
