Testing a food delivery app is hard. Testing an on-demand logistics app is harder.

Food delivery has a fixed pattern: one restaurant, one customer, one delivery partner, 30 minutes. Logistics apps break every one of those constraints. Multiple pickup stops. Multiple drop locations. Vehicle selection based on package size bike, auto-rickshaw, mini-truck, or 3-wheeler. Weight and dimension-based pricing that recalculates mid-booking. Driver allocation across vehicle categories. Package photo verification at pickup and delivery. OTP-based handoffs. And live tracking across routes that can stretch 3 hours across a city instead of 30 minutes across a neighbourhood.

India's on-demand logistics market is growing at 25%+ annually. Platforms are processing hundreds of thousands of parcels daily across 50+ cities from a document courier within downtown Manhattan to a 50kg furniture shipment from Los Angeles to San Francisco. In India, the same scale plays out across cities like Bangalore, Delhi, and Mumbai. The QA challenge scales with the complexity.

This guide provides 28 ready-to-use test cases covering every critical flow in an on-demand logistics app, from booking to delivery confirmation. Each test is written in both Appium and Drizz format so you can see the difference in approach and maintenance cost.

For food delivery testing, see our 30 Test Cases from Order to Doorstep. For the broader delivery app challenge, see Why Delivery Apps Are the Hardest to Test.

Key Takeaways

• On-demand logistics apps are harder to test than food delivery because of multi-stop routes, vehicle type selection, weight-based pricing, package verification (photo + OTP), and tracking across city-scale distances.
• 28 test cases cover the complete logistics flow: booking (8), driver matching (4), pickup verification (4), live tracking (4), delivery confirmation (4), payment (4), and cancellation/refund (4).
• Selector-based tools (Appium) struggle with logistics apps because of dynamic fare estimates, map-heavy flows, photo verification screens, and OTP dialogs that cross app boundaries.
• Vision AI (Drizz) validates the visual experience fare estimates displayed, map pin moving, photo upload confirmed, OTP screen rendered without depending on element IDs that change with every release.
• Region-specific challenges vary by market: in the US, challenges include apartment complex access codes, loading dock scheduling for commercial deliveries, toll route pricing, and multi-timezone scheduling for cross-state shipments. In India, additional challenges include auto rickshaw as a vehicle category, addresses without pin codes in tier-3 cities, intercity parcel flows, and COD for logistics.

How Is Logistics App Testing Different from Food Delivery Testing?

Section 1: Booking Flow (Test Cases 1-8)

TC-01: Enter pickup address

Appium:

driver.find_element(AppiumBy.ID, "com.app:id/pickup_input").click()

driver.find_element(AppiumBy.ID, "com.app:id/address_search").send_keys("Brooklyn Heights")

WebDriverWait(driver, 5).until(
    EC.presence_of_element_located((
        AppiumBy.XPATH,
        "//android.widget.TextView[contains(@text, 'Brooklyn Heights')]"
    ))
)

Drizz:

1. Tap the pickup address field
2. Type "Brooklyn Heights"
3. Tap "Brooklyn Heights" from suggestions
4. Verify pickup address is set

TC-02: Enter drop address

Drizz:

1. Tap the drop address field
2. Type "Midtown Manhattan"
3. Tap "Midtown Manhattan" from suggestions
4. Verify drop address is set
5. Verify distance or route preview is displayed

TC-03: Add multiple stops (multi-drop)

Drizz:

1. After setting the pickup and first drop address
2. Tap "Add Stop" or "+"
3. Type "SoHo"
4. Tap "SoHo" from suggestions
5. Verify two drop locations are listed
6. Verify the fare estimate updates with the additional stop

TC-04: Select vehicle type

Appium:

WebDriverWait(driver, 5).until(
    EC.presence_of_element_located((
        AppiumBy.ID,
        "com.app:id/vehicle_list"
    ))
)

vehicles = driver.find_elements(
    AppiumBy.XPATH,
    "//android.widget.RecyclerView[@resource-id='com.app:id/vehicle_list']//android.widget.FrameLayout"
)

assert len(vehicles) >= 2

vehicles[1].click()  # Select mini-truck

Drizz:

1. Verify vehicle options are displayed (Bike, Auto, Mini Truck)
2. Verify each option shows an estimated price
3. Tap "Mini Truck"
4. Verify Mini Truck is selected and highlighted
5. Verify the fare estimate updates for the selected vehicle

TC-05: Fare estimate calculation

Drizz:

1. Set the pickup address
2. Set the drop address
3. Select a vehicle type
4. Verify the fare estimate is displayed as a number
5. Verify the fare breakdown shows the base fare, distance charge, and taxes
6. Change to a different vehicle type
7. Verify the fare estimate updates for the selected vehicle

TC-06: Weight and dimension input

Drizz:

1. Tap "Package Details" or "What are you sending" on the booking screen
2. Select a package category (Document, Small Box, Large Item, Furniture)
3. Verify a weight estimate or input field appears
4. Enter "15 kg"
5. Verify the fare updates based on the package weight

TC-07: Schedule a future pickup

1. Tap "Schedule" or "Later" on the booking screen
2. Verify the date and time picker appears
3. Select tomorrow's date and 10:00 AM
4. Tap "Confirm"
5. Verify the booking screen shows the scheduled date and time
6. Verify the fare reflects the scheduled pricing

TC-08: Intercity parcel booking

Drizz:

1. Set the pickup address in Delhi
2. Set the drop address in Jaipur
3. Verify the intercity booking flow is activated
4. Verify vehicle options update for intercity deliveries (larger vehicles)
5. Verify the fare estimate reflects the intercity distance
6. Verify the estimated delivery time is displayed in hours (not minutes)

Section 2: Driver Matching and Acceptance (Test Cases 9-12)

TC-09: Booking confirmation and driver search

Drizz:

1. After selecting a vehicle and confirming the fare
2. Tap "Book Now" or "Confirm Booking"
3. Verify the "Searching for driver" or "Finding your partner" screen appears
4. Verify a loading animation or search indicator is visible

TC-10: Driver assigned with details

Drizz:

1. After the driver accepts the booking
2. Verify the driver name is displayed
3. Verify the vehicle number or vehicle details are shown
4. Verify the driver rating is visible
5. Verify the driver photo is displayed
6. Verify the "Call Driver" or contact option is available

TC-11: No driver available handling

Drizz:

1. Place a booking in a test environment with no drivers available
2. Verify the "No drivers available" or retry message appears
3. Verify an option to retry the search or change the vehicle type is displayed

TC-12: Driver cancels after accepting

Drizz:

1. After a driver is assigned
2. Trigger a driver cancellation via the test API
3. Verify the "Driver cancelled" message appears
4. Verify automatic driver re-search begins or a rebooking option is displayed

Section 3: Pickup Verification (Test Cases 13-16)

TC-13: OTP verification at pickup

Appium:

# OTP dialog may be OS-level or in-app

WebDriverWait(driver, 30).until(
    EC.presence_of_element_located((
        AppiumBy.ID,
        "com.app:id/otp_display"
    ))
)

otp = driver.find_element(
    AppiumBy.ID,
    "com.app:id/otp_display"
).text

assert len(otp) == 4

Drizz:

1. Open the tracking screen
2. Verify the pickup OTP is displayed
3. Verify the OTP is a 4-digit number
4. Verify the instruction "Share this OTP with driver" is visible

TC-14: Package photo at pickup

Drizz:

1. After the OTP is verified via the test API trigger
2. Verify the "Package picked up" confirmation appears
3. Verify the pickup photo is displayed in the order details
4. Verify the pickup timestamp is shown

TC-15: Pickup address reached by driver

Drizz:

1. Open the tracking screen
2. Verify the driver status changes to "Arrived at pickup"
3. Verify the "Driver is at your location" notification or message appears
4. Verify the call or chat option with the driver is accessible

TC-16: Wrong pickup location handling

Drizz:

1. Verify the driver can report "Wrong address" or "Cannot find location"
2. Verify the customer receives a notification about the driver's issue
3. Verify an option to update the address or contact the driver is available

Section 4: Live Tracking (Test Cases 17-20)

TC-17: Map loads with route

Drizz:

1. After pickup is confirmed, navigate to the tracking screen
2. Verify the map is visible and rendering correctly (not blank)
3. Verify the route line is displayed between the current location and the drop location
4. Verify the driver pin is visible on the map

TC-18: Driver pin moves on map

Drizz:

1. Open the tracking screen and note the driver's pin position
2. Wait 15 seconds
3. Verify the driver pin has changed position
4. Verify the ETA has been updated

TC-19: ETA updates during transit

Drizz:

1. Read the current ETA on the tracking screen
2. Wait 60 seconds
3. Verify the ETA has decreased
4. Verify the ETA is displayed in a readable format (minutes or arrival time)

TC-20: Multi-stop tracking transition

Drizz:

1. For a multi-stop booking, verify the tracking screen shows "En route to Stop 1"
2. After Stop 1 is completed (via the test API), verify the status updates to "En route to Stop 2"
3. Verify the map route updates to show the next destination
4. Verify the ETA is recalculated for the remaining route

Section 5: Delivery Confirmation (Test Cases 21-24)

TC-21: OTP verification at delivery

Drizz:

1. When the driver arrives at the drop location
2. Verify the delivery OTP is displayed on the customer app
3. Verify the message "Share OTP with driver to complete delivery" is displayed

TC-22: Delivery photo confirmation

Drizz:

1. After the delivery OTP is verified via the test API
2. Verify the "Delivered" status appears
3. Verify the delivery photo is displayed in the order details
4. Verify the delivery timestamp is shown

TC-23: Delivery to alternate recipient

Drizz:

1. Verify an option to add an alternate recipient name and phone number is available
2. Enter the alternate recipient's contact details
3. Verify the delivery confirmation displays the alternate recipient information

TC-24: Failed delivery attempt

Drizz:

1. Trigger a failed delivery via the test API (recipient unavailable)
2. Verify the "Delivery failed" status appears
3. Verify the failure reason is displayed (e.g., "Recipient not available")
4. Verify options to Reschedule, Return to Sender, or Contact Support are available

Section 6: Payment (Test Cases 25-28)

TC-25: Pay with UPI after delivery

Drizz:

1. After delivery is confirmed
2. Verify the payment screen shows the final fare
3. Verify the final fare matches the estimated fare or displays the reason for any adjustment
4. Select UPI as the payment method
5. Complete the payment
6. Verify the payment confirmation and receipt are displayed

TC-26: Cash on Delivery completion

Drizz:

1. For a Cash on Delivery (COD) booking, verify the instruction "Pay Cash to Driver" is displayed
2. After delivery is completed (via the test API trigger for cash collected)
3. Verify the order status shows "Completed • Paid by Cash"

TC-27: Corporate account billing

Drizz:

1. Log in with a corporate account
2. Complete a booking
3. Verify the payment is charged to the corporate account (not the personal account)
4. Verify the booking appears in the corporate dashboard or booking history
5. Verify the invoice or receipt displays the company name

TC-28: Fare adjustment and dispute

Drizz:

1. After delivery is completed, verify the final fare is displayed
2. If the final fare differs from the estimate, verify the adjustment reason is shown
3. Tap "Help" or "Dispute Fare"
4. Verify the fare dispute form or support options are displayed

The Pattern: Why Vision AI Fits Logistics Apps

Logistics apps have more visual, dynamic, and cross-boundary flows than food delivery:

• Vehicle selection is a visual grid of options with images, names, and prices not a standard dropdown Appium can easily select from.
• Fare estimates update dynamically based on distance, weight, vehicle, and time static assertions break instantly.
• Photo verification at pickup and delivery renders images inside the app that Appium can't validate (it can check if an image element exists, not if it shows the right package).
• OTP screens may be in-app or OS-level Vision AI sees both.
• Multi-stop tracking requires visual validation that the map route, status text, and ETA all update correctly at each stop transition.
• Addresses without pin codes in tier-3 cities often use landmark-based descriptions that render as long text strings Vision AI confirms the text renders without truncation.

At 28 test cases with an average of 8 selectors each, an Appium suite has 224 breakage points. A Drizz suite has zero. For logistics apps that iterate on booking UI and tracking flows weekly, the maintenance gap compounds every sprint.

After 3 months of weekly releases, a selector-based suite has faced 12 rounds of potential breakages across those 224 points. The QA team that started with 28 well-maintained tests is now spending more time fixing broken selectors than writing tests for the new features shipping every sprint scheduled pickups, intercity routes, corporate billing, package insurance. Coverage stalls. The newest, highest-risk flows ship untested.

A Vision AI suite faces those same 12 releases and needs zero selector updates. The team spends that same time expanding coverage to 50, then 80, then 120 tests covering every new feature as it ships. The architecture doesn't just reduce maintenance. It changes what the team is capable of building.

Frequently Asked Questions

How is logistics app testing different from food delivery testing?

Logistics apps add vehicle selection, weight-based pricing, multi-stop routing, package photo verification, OTP handoffs at both pickup and delivery, scheduled bookings, intercity routes, and corporate accounts. Food delivery has a simpler fixed pattern (one restaurant, one customer, 30 minutes). Logistics has variable routes, variable durations (30 min to 3+ hours), and variable package types.

Can Appium test photo verification flows?

Appium can verify that an image element exists in the element tree, but it cannot verify what the image shows. A pickup photo showing the wrong package, a blurry image, or a placeholder icon all pass Appium's is_displayed() check. Vision AI can confirm that an image is present, appears to be a photo (not a placeholder), and the surrounding context (timestamp, "Picked up" label) renders correctly.

How do you test multi-stop routes?

Test each stop transition independently: verify tracking shows the correct current destination, verify ETA updates when a stop is completed, verify the map route changes to the next stop, and verify the status text transitions correctly. Use a test API to trigger stop completions without waiting for real deliveries.

What about testing auto-rickshaw as a vehicle option?

Auto-rickshaw is a vehicle category specific to Indian logistics apps. Test it the same as any vehicle: verify it appears in the vehicle selection grid with an image and estimated price, verify selecting it updates the fare, and verify the booking confirms with the correct vehicle type. Vision AI sees "Auto" as a visual option regardless of what element ID the component uses.

How many devices should logistics apps test on?

Logistics apps should test on 25-40 devices with emphasis on mid-range and budget Android phones (Samsung A-series, Xiaomi Redmi, Realme) because delivery partners and many customers in tier-2/3 cities use budget devices. Include 3-4GB RAM devices, older Android versions (12-13), and smaller screen sizes where booking forms and tracking maps are most likely to have rendering issues.