Every food delivery app has the same promise: you tap a button, food shows up at your door. Testing that promise requires covering everything between those two moments search, browse, cart, coupons, payments, tracking, delivery confirmation, ratings, and the dozen things that can go wrong at each step.
This guide provides 30 ready-to-use test cases covering every critical flow in a food delivery app, from opening the app to the food arriving. Each test case is written two ways: the traditional Appium approach (selectors, waits, assertions) and the Vision AI approach (plain English, no code). By the end, you'll have a complete QA checklist you can execute today.
These test cases are based on patterns from production delivery apps processing over a million orders daily in India, including platforms tested with Drizz Vision AI.
For the broader delivery app testing strategy, see our Why Delivery Apps Are the Hardest to Test guide.
How to Read These Test Cases
Each test case is shown in two formats:
Appium (traditional): Python code using selectors, explicit waits, and element assertions. Requires Appium server, platform SDKs, and element inspection setup.
Drizz (Vision AI): Plain English steps that describe what the user sees and does. No selectors, no code, no setup beyond connecting a device.
Section 1: App Launch and Location (Test Cases 1-5)
TC-01: App launches and home screen loads
Appium:
driver.launch_app()
WebDriverWait(driver, 15).until(
EC.presence_of_element_located((AppiumBy.ID, "com.app:id/home_screen")))
assert driver.find_element(AppiumBy.ID, "com.app:id/restaurant_list").is_displayed()
Drizz:
Launch the app
Verify home screen is visible
Verify restaurant listings are displayed
TC-02: Location permission prompt appears and is accepted
Appium:
WebDriverWait(driver, 10).until(
EC.presence_of_element_located((AppiumBy.ID, "com.android.permissioncontroller:id/permission_allow_foreground_only_button")))
driver.find_element(AppiumBy.ID, "com.android.permissioncontroller:id/permission_allow_foreground_only_button").click()
Drizz:
Verify location permission dialog appears
Tap "Allow only while using the app"
Verify home screen loads with restaurant listings
TC-03: Change delivery location manually
Appium:
driver.find_element(AppiumBy.ID, "com.app:id/location_bar").click()
driver.find_element(AppiumBy.ID, "com.app:id/search_location").send_keys("Koramangala")
WebDriverWait(driver, 5).until(
EC.presence_of_element_located((AppiumBy.XPATH, "//android.widget.TextView[contains(@text, 'Koramangala')]")))
driver.find_element(AppiumBy.XPATH, "//android.widget.TextView[contains(@text, 'Koramangala')]").click()
Drizz:
Tap the delivery location bar
Type "Koramangala" in location search
Tap "Koramangala" from suggestions
Verify restaurant listings update
TC-04: Restaurants update when location changes
Appium:
# Store current first restaurant name
first_restaurant_before = driver.find_element(AppiumBy.XPATH,
"//android.widget.RecyclerView/android.widget.FrameLayout[1]//android.widget.TextView[@resource-id='com.app:id/restaurant_name']").text
# Change location
change_location("Whitefield")
first_restaurant_after = driver.find_element(AppiumBy.XPATH,
"//android.widget.RecyclerView/android.widget.FrameLayout[1]//android.widget.TextView[@resource-id='com.app:id/restaurant_name']").text
assert first_restaurant_before != first_restaurant_after
Drizz:
Note the first restaurant name on screen
Change location to "Whitefield"
Verify restaurant listings have changed
Verify a different restaurant appears first
TC-05: "Not serviceable" message for unsupported location
Appium:
change_location("Remote Village")
WebDriverWait(driver, 10).until(
EC.presence_of_element_located((AppiumBy.ID, "com.app:id/not_serviceable_text")))
assert "not available" in driver.find_element(AppiumBy.ID, "com.app:id/not_serviceable_text").text.lower()
Drizz
Change location to an unsupported area
Verify "not available in your area" message is displayed
Section 2: Search and Browse (Test Cases 6-10)
TC-06: Search for a cuisine and verify results
Drizz:
Tap the search bar
Type "Biryani"
Verify search results show restaurants with "Biryani" in name or cuisine tags
TC-07: Filter by rating (4.0+ stars)
Drizz:
Tap "Filters"
Select "Rating 4.0+"
Tap "Apply"
Verify all displayed restaurants show 4.0 or higher rating
TC-08: Sort by delivery time
Drizz:
Tap "Sort"
Select "Delivery Time"
Verify restaurants are listed with shortest delivery time first
TC-09: Browse a restaurant menu
Drizz:
Tap on the first restaurant card
Verify restaurant menu screen loads
Verify menu categories are visible
Verify at least one menu item shows name and price
TC-10: Restaurant closed message displays correctly
Drizz:
Navigate to a restaurant marked as closed
Verify "Currently closed" or schedule information is displayed
Verify "Add to Cart" button is disabled or not visible
Section 3: Cart Management (Test Cases 11-16)
TC-11: Add item to cart
Appium:
driver.find_element(AppiumBy.XPATH,
"//android.widget.TextView[@text='Chicken Biryani']/following-sibling::android.widget.Button[@resource-id='com.app:id/add_btn']").click()
WebDriverWait(driver, 5).until(
EC.presence_of_element_located((AppiumBy.ID, "com.app:id/cart_badge")))
assert driver.find_element(AppiumBy.ID, "com.app:id/cart_badge").text == "1"
Drizz:
Tap "Add" next to the first menu item
Verify cart icon shows item count of 1
TC-12: Increase item quantity
Drizz:
Tap "+" on the added item
Verify quantity shows 2
Verify cart total updates
TC-13: Remove item from cart
Drizz:
Tap "-" until item quantity reaches 0
Verify item is removed from cart
Verify cart icon shows empty or disappea
TC-14: Add items from different restaurants (multi-restaurant warning)
Drizz:
Add an item from Restaurant A
Navigate back and open Restaurant B
Tap "Add" on an item from Restaurant B
Verify "Replace cart" or "Start new cart" dialog appears
TC-15: Cart persists after app restart
Drizz:
Add 2 items to cart
Close the app completely
Reopen the app
Verify cart still shows 2 items with correct names and prices
TC-16: Item unavailable after adding to cart
Drizz:
Add an item to cart
Navigate to checkout
Verify if any "item unavailable" message appears
Verify cart total recalculates if items are removed
Section 4: Checkout and Payment (Test Cases 17-24)
TC-17: Checkout screen displays order summary correctly
Appium:
driver.find_element(AppiumBy.ID, "com.app:id/checkout_btn").click()
WebDriverWait(driver, 10).until(
EC.presence_of_element_located((AppiumBy.ID, "com.app:id/order_summary")))
assert driver.find_element(AppiumBy.ID, "com.app:id/item_total").is_displayed()
assert driver.find_element(AppiumBy.ID, "com.app:id/delivery_fee").is_displayed()
assert driver.find_element(AppiumBy.ID, "com.app:id/grand_total").is_displayed()
Drizz:
Tap "Checkout" or "View Cart"
Verify order summary screen shows item names and quantities
Verify delivery fee is displayed
Verify total amount is displayed
TC-18: Apply coupon code successfully
Drizz:
Tap "Apply Coupon" on checkout screen
Type "FLAT50" in coupon field
Tap "Apply"
Verify discount is reflected in the order total
Verify coupon tag shows "FLAT50 applied"
TC-19: Apply invalid coupon code
Drizz:
Tap "Apply Coupon"
Type "INVALIDCODE" in coupon field
Tap "Apply"
Verify error message "Invalid coupon" or "Coupon not applicable" appears
Verify total remains unchanged
TC-20: Pay with UPI
Drizz:
On checkout screen, select "UPI" as payment method
Verify UPI app selection or UPI ID input appears
Complete payment
Verify "Order Confirmed" screen appears
TC-21: Pay with credit/debit card
Select "Credit / Debit Card" as payment method
Verify card input form appears
Enter test card details
Tap "Pay"
Verify order confirmation screen appears
TC-22: Pay with Cash on Delivery
Drizz:
Select "Cash on Delivery" as payment method
Tap "Place Order"
Verify order confirmation screen appears
Verify order status shows "COD" payment method
TC-23: Pay with wallet (partial + UPI)
Drizz:
Verify wallet balance is displayed on checkout
Toggle "Use wallet balance" on
Verify remaining amount to pay is calculated
Select "UPI" for the remaining amount
Complete payment
Verify order confirmed
TC-24: Delivery tip selection
Drizz:
On checkout screen, verify tip options are displayed
Tap a tip amount (e.g., "20")
Verify total updates to include tip
Tap "Place Order"
Verify order confirmation includes tip
Section 5: Order Tracking (Test Cases 25-27)
TC-25: Order status updates in real-time
Drizz:
After placing an order, verify order tracking screen loads
Verify status shows "Order Placed" or "Confirmed"
Wait for status to update to "Preparing" or "Being Prepared"
Verify status transition is visible on screen
TC-26: Live map tracking shows delivery partner
Drizz:
On order tracking screen, verify map is displayed
Verify delivery partner icon or marker appears on map
Verify ETA is displayed and updates
TC-27: Cancel order flow
Drizz:
On order tracking screen, tap "Cancel Order" or "Help"
Verify cancellation options or reasons are displayed
Select a reason and confirm cancellation
Verify "Order Cancelled" confirmation appears
Section 6: Post-Delivery (Test Cases 28-30)
TC-28: Rate the order
Drizz:
After delivery, verify rating prompt appears
Tap a star rating (e.g., 4 stars)
Verify rating is submitted
Verify "Thank you" or confirmation message appears
TC-29: Reorder previous order
Drizz:
Navigate to order history
Tap "Reorder" on a previous order
Verify items are added to cart with correct quantities
Navigate to checkout
Verify order summary matches previous order
TC-30: Report an issue with delivered order
Drizz:
Navigate to order history
Tap on a completed order
Tap "Help" or "Report an Issue"
Verify issue categories are displayed (wrong item, missing item, quality)
Select an issue and submit
Verify confirmation that issue is reported
The Pattern You Just Saw
Look at the 30 test cases above. Every Drizz test reads like instructions you'd give a human tester: "tap this, verify that, check this appears." Every Appium test reads like code written for a machine: element IDs, XPath expressions, explicit waits, type assertions.
Now ask yourself:
- Which version survives a checkout screen redesign?
- Which version breaks when a developer renames com.app:id/add_btn to com.app:id/add_to_cart?
- Which version can a manual QA tester write without learning Python?
- Which version takes 5 minutes to write vs 45 minutes?
The Appium versions require 6-12 selectors per test, each one a potential breakage point. The Drizz versions require zero selectors. When the UI changes, the Appium tests break. The Drizz tests keep passing because the button still says "Add" on screen.
At 30 test cases with an average of 8 selectors each, an Appium suite has 240 breakage points. A Drizz suite has zero.
How to Use This Checklist
If you're starting from zero: Use the Drizz versions. Install Drizz Desktop, connect a device, and start with TC-01 through TC-10. You'll have your first 10 automated tests running within an hour.
If you have an existing Appium suite: Compare your current tests against this checklist. Identify which of the 30 flows you're missing. Rewrite your highest-maintenance tests (checkout, payment, cart) in Drizz and run them in parallel for 2 sprints to compare maintenance cost.
If you're a QA lead building a strategy: This checklist maps to the 5-layer testing strategy recommended for delivery apps. TC-01 through TC-05 are Layer 1 smoke tests. TC-06 through TC-30 are Layer 2-3 regression tests.
Frequently Asked Questions
How many test cases does a delivery app need?
A production delivery app typically maintains 300-500+ automated test cases. This checklist of 30 covers the critical path from order to doorstep. Additional tests cover edge cases (network failures, concurrent modifications, multi-device sessions), payment permutations (8-12 methods), location-based variations, and device compatibility.
Can these test cases run on both Android and iOS?
The Drizz versions run identically on Android and iOS from a single test file because they describe what the user sees, not platform-specific element identifiers. The Appium versions require separate element locators for Android (resource-id, XPath) and iOS (accessibility-id, predicate string).
How long does it take to automate all 30 test cases?
With Drizz: approximately 2-3 hours for all 30 test cases (5-6 minutes each). With Appium: approximately 15-20 hours including element inspection, selector identification, wait configuration, and cross-device validation.
What about test data (restaurant names, menu items, prices)?
The Drizz test cases use structural validation ("verify a restaurant card shows name, rating, and delivery time") rather than specific data ("verify Pizza Palace shows Margherita at 299"). This means tests pass regardless of which restaurants are available at test time. For data-specific tests (coupon codes, test payment credentials), parameterize the test data separately.
Do I need a test environment or can I test on production?
Drizz tests can run on production builds because they don't require instrumentation or debug builds. Use test accounts with test payment credentials to avoid real transactions. Most delivery apps provide sandbox payment modes for QA.