Which apps are involved in testing a food delivery order?

Usually three: the customer app, the restaurant app or tablet, and the delivery partner app, plus payment and support systems. An end-to-end case needs all of them in the test environment, and you should ask which ones are in scope.

What is a good scenario question to expect?

'The restaurant accepted the order and then ran out of an item. What happens?' Ask what the product supports (partial refund, substitute, cancel) and test each path, including the refund and the notification.

Test cases for a food delivery order flow

Assumes a customer app for food delivery with address selection, restaurant search, cart, coupons, online payment and cash on delivery, live order tracking and in-app support. The restaurant and delivery partner apps exist in the test environment so status changes can be triggered. Fees, minimum order value and refund policies below are examples.

How to answer in an interview

Ask first: which apps are in scope (customer, restaurant, rider), which payment methods, what fees appear on the bill, what are the cancellation and refund rules, is cash on delivery supported, and are scheduled orders supported? Then follow the order: location and browsing, cart, bill and coupons, payment, order status from restaurant to doorstep, cancellations and issues, and finally notifications, privacy and peak load.

Scope and test data

Example rules: minimum order ₹99; free cancellation until the restaurant accepts. Test customer [email protected], phone 9000000001, a test address inside the service area and one outside it. Payments use the provider's sandbox only. Restaurant and rider actions are triggered from their test apps or a test tool. These are designed cases, not an execution report.

Location and browsing

ID	Category	Test case	Expected result
F01	Functional	Allow location and choose the detected address	Restaurants that deliver there are listed with delivery times
F02	Negative	Choose an address outside the service area	Clear message; checkout not possible
F03	Functional	Open a restaurant that is closed	Shown as closed with opening time; items cannot be ordered (unless scheduling is supported)
F04	Functional	Search "paneer"	Matching dishes and restaurants
F05	Functional	Turn on the vegetarian filter	Only vegetarian items and restaurants shown

Cart

ID	Category	Test case	Expected result
F06	Functional	Add a pizza with an extra-cheese add-on	Add-on price added to the item; cart total updates
F07	Functional	Add an item from a second restaurant	Prompt to replace the cart; nothing mixed silently
F08	Negative	An item in the cart goes out of stock before checkout	User told at checkout; cannot pay for the unavailable item
F09	Boundary	Cart at ₹98, then ₹99	₹98 blocked with the minimum-order message; ₹99 allowed
F10	Boundary	Increase one item's quantity to the maximum and one more	Maximum allowed; the next increase blocked with a message

Bill and coupons

ID	Category	Test case	Expected result
F11	Functional	Check the bill	Item total, delivery fee, packaging, taxes and any platform fee add up to the amount to pay
F12	Functional	Apply a valid coupon; an expired one; one below its minimum order	Valid one reduces the total; others show a specific reason
F13	Functional	Add a tip and delivery instructions	Tip added to the total; instructions visible in the rider test app
F14	Negative	Use a one-per-user coupon on a second order	Rejected with a reason

Payment

ID	Category	Test case	Expected result
F15	Functional	Pay by UPI sandbox successfully	Order placed once; confirmation screen shows the order ID
F16	Negative	Payment fails	No order placed; cart kept; user can retry
F17	Negative	Payment confirmed but order creation fails	Order created later by reconciliation or refund started automatically; user told which
F18	Boundary	Cash on delivery above the allowed order value, if there is a limit	Cash on delivery hidden or blocked with a reason above the limit
F19	Negative	Background the app during payment, then return	Real payment status shown; no duplicate order on retry

Order status

ID	Category	Test case	Expected result
F20	Functional	Restaurant accepts the order	Status changes to accepted or preparing with an updated time
F21	Negative	Restaurant rejects, or does not respond within the timeout	Order cancelled; full refund started; user notified
F22	Functional	Rider is assigned	Rider name and live location shown; phone number masked if specified
F23	Functional	Rider moves during the test route	Map and estimated time update without jumps backwards
F24	Functional	Rider marks the order delivered	Status delivered; rating prompt; order in history with the invoice

Cancellations and issues

ID	Category	Test case	Expected result
F25	Functional	Cancel before the restaurant accepts	Free cancellation; full refund to the original method
F26	Functional	Try to cancel after the food is being prepared	Fee or refusal shown before confirming, as the policy says
F27	Functional	Restaurant marks an item unavailable after accepting	User offered the supported option (refund, replace or cancel); bill and refund adjusted
F28	Functional	Report a missing item with a photo after delivery	Support ticket created; refund or credit as per policy; status visible
F29	Negative	Change the delivery address after the order is placed	Blocked, or allowed only within the documented limits with fees recalculated

Notifications, privacy and performance

ID	Category	Test case	Expected result
F30	Functional	Follow one order from placed to delivered	One notification for each key status; none duplicated or out of order
F31	Security	Change the order ID in an API call to another user's order	Access denied; no details of the other order
F32	Security	After delivery, look for the customer's number and address in the rider test app	Hidden or masked once the order is closed, as specified
F33	Performance	Simulate dinner-time peak load on menu, cart and checkout	Responses within the agreed limits; no duplicate orders or charges

What to prioritise

Money and food together: F15 to F17, F21 and F25 to F27. In an interview, the common mistake is to describe only the customer screens. Say that the order is really a state machine shared by three apps, and that you would test each state change and what the customer sees and pays at each one.