A customer orders milk, bananas, and bread. By the time the picker reaches the milk aisle, the last carton has been claimed by another order. The app needs to suggest a substitute, the customer needs to approve it, and the picker needs to continue all within 90 seconds. The entire order will be at the customer’s door in 12 minutes.

Now try writing a test for that.

Quick commerce grocery delivery doesn’t just move faster than food delivery. It moves faster than your test suite. The 15-minute promise compresses every flow to the point where inventory changes while the customer is browsing, items go out of stock while the picker is walking the aisle, substitution approvals happen in real-time within seconds, and the entire order-to-doorstep lifecycle finishes before your regression suite completes its second test case.

This isn’t faster food delivery. It’s a fundamentally different product: dark store inventory that differs from the customer-facing catalog, weight-based produce pricing that creates variable totals at checkout, delivery slots that expire in 2-minute windows, and picker-to-customer communication happening mid-order through substitution prompts that appear and disappear in seconds.

This guide covers what specifically needs testing, why traditional automation tools fail at the speed quick commerce demands, and how to build a testing strategy for an app where the delivery arrives before your test suite finishes running.

For food delivery testing, see 30 Test Cases from Order to Doorstep. For logistics app testing, see How to Test On-Demand Logistics Apps.

Key Takeaways

• Quick commerce grocery apps have fundamentally different testing challenges than food delivery: real-time inventory changes, mid-order substitution flows, weight-based variable pricing, 2-minute delivery slot windows, and dark store catalogue discrepancies.
• The 15-minute delivery promise means the entire order lifecycle is shorter than most test suite execution times, requiring a different approach to regression testing.
• Substitution flows where a picker suggests a replacement and the customer approves or rejects in-app within seconds are the hardest feature to test because they're real-time, visual, time-bounded, and different every order.
• Vision AI (Drizz) validates substitution prompts, out-of-stock banners, live picking status, and dynamic pricing visually the same way the customer sees them without depending on element IDs that change with every weekly release.
• Dark store inventory testing requires validating what the customer sees (catalog) against what's actually available (picker reality), a gap that causes the most customer complaints in quick commerce.

How Is Grocery Quick Commerce Testing Different from Food Delivery?

What Are the 7 Unique Testing Challenges in Quick Commerce?

1. Real-Time Inventory That Changes Mid-Session

A customer adds milk to their cart. While they're browsing snacks, the last carton of that milk is picked for another order. When they reach checkout, the milk is out of stock. The app must handle this gracefully: show an out-of-stock message, suggest an alternative, recalculate the cart total, and not charge for the unavailable item.

This happens constantly in quick commerce because dark stores have limited inventory (2,000-4,000 SKUs vs 50,000+ in a supermarket) and high order velocity (hundreds of orders per hour from a single store). Items that were available 30 seconds ago can become unavailable.

Testing challenge: A test that adds "Amul Toned Milk 1L" to the cart and asserts it's present at checkout is fragile the item might genuinely be out of stock by the time the test reaches checkout, even in a test environment.

2. Substitution Flows During Picking

This is the feature that defines quick commerce QA complexity. When a picker can't find an ordered item, they suggest a substitute through the app. The customer sees a real-time prompt: "Amul Toned Milk is unavailable. Accept Mother Dairy Toned Milk instead? Same price." The customer has 30-60 seconds to accept, reject, or skip.

What needs testing:

• Substitution prompt appears with correct original and replacement item
• Price comparison is accurate (same price, higher, lower)
• Accept updates the cart with the substitute
• Reject removes the item and adjusts the total
• Timeout (customer doesn't respond) follows the default behavior (auto-accept or auto-reject depending on platform)
• Multiple substitutions in one order render correctly (3 items unavailable, 3 prompts in sequence)

Testing challenge: Substitution prompts are ephemeral they appear, require action within seconds, and disappear. Appium needs to find the prompt element, which may have dynamic IDs generated per substitution event. By the time the test locates the element, the prompt may have timed out.

3. Weight-Based Produce Pricing

A customer orders "500g Tomatoes at 40/kg = 20." The picker weighs the actual batch: 480g. The price adjusts to 19.20. This recalculation happens at the item level, during picking, and the cart total updates in real-time.

Testing challenge: The final price isn't known until the picker weighs the item. A test asserting "tomato price is 20" fails when the actual weight differs. Every produce item in the cart has this variability.

4. Dark Store Inventory vs Catalog Discrepancy

The customer-facing catalog shows "Organic Bananas In Stock." The dark store picker scans the shelf and finds zero organic bananas. The catalog was stale by 3 minutes. This discrepancy is the #1 source of customer complaints in quick commerce.

Testing challenge: Testing catalog accuracy requires comparing the displayed catalog against actual dark store inventory in real-time a data integrity test that most QA teams don't include in their UI automation suite.

5. Delivery Slot Expiry

A customer selects a 10-15 minute delivery slot. They spend 8 minutes browsing and adding items. By the time they reach checkout, that slot has expired and a new slot (15-20 minutes) is offered. The app must update the slot, recalculate delivery time, and potentially adjust the delivery fee.

Testing challenge: Delivery slots are time-bound by design. A test that selects a slot and then takes 5 minutes to complete the checkout flow may legitimately encounter slot expiry which is correct app behavior, not a bug. Tests need to distinguish between "slot expired because the test was slow" and "slot expiry handling is broken."

6. Live Order Tracking During Picking

Quick commerce apps show picking progress in real-time: "5 of 12 items picked," "Picker is selecting your produce," "Order packed, waiting for delivery partner." This is a status feed that updates every few seconds during the 3-5 minute picking window.

Testing challenge: The picking status updates are server-pushed events that change the UI every few seconds. A test that asserts "status shows 5 of 12 picked" may see "7 of 12" by the time the assertion executes.

7. Minimum Order and Delivery Fee Thresholds

Quick commerce platforms have minimum order values (often 99-199) with delivery fees that change based on cart value (free above 299, 25 fee below). Every cart modification add, remove, substitute, weight adjustment can push the cart above or below these thresholds, changing the delivery fee and potentially blocking checkout.

Testing challenge: Delivery fee assertions break whenever the platform changes threshold values, which happens frequently with promotions and A/B tests.

20 Test Cases for Quick Commerce Grocery Apps

Browse and Cart (TC-01 to TC-06)

TC-01: Search and add item to cart

1. Tap the search bar
2. Type "Milk"
3. Verify milk products appear in the search results
4. Tap "Add" on the first available milk product
5. Verify the cart icon updates with the item count

TC-02: Item goes out of stock while in cart

1. Add an item to the cart

2. Trigger out-of-stock for that item (via the test API)

3. Navigate to the cart

4. Verify an out-of-stock indicator appears on the item

5. Verify the cart total recalculates without the unavailable item

6. Verify an option to remove the item or find an alternative is shown

TC-03: Weight-based item displays estimated price

1. Search for "Tomatoes"
2. Verify the price shows the per-kg rate and the estimated total
3. Add 500g of Tomatoes to the cart
4. Verify the cart shows the estimated price with the note "Final price may vary"

TC-04: Category browsing with real-time availability

1. Browse the "Fruits & Vegetables" category
2. Verify each item displays its availability status
3. Verify out-of-stock items are greyed out or marked "Unavailable"
4. Verify available items have an active "Add" button

TC-05: Cart minimum order validation

1. Add items below the minimum order value
2. Tap "Checkout"
3. Verify the message "Minimum order of 149 required" appears
4. Verify checkout is blocked until the minimum order value is met
5. Add more items to exceed the minimum order value
6. Verify the "Checkout" button becomes active

TC-06: Delivery fee threshold change

1. Add items totaling 250 (below the free delivery threshold)
2. Verify the delivery fee is displayed (e.g., 25)
3. Add more items to reach 300 (above the threshold)
4. Verify the delivery fee changes to "FREE"
5. Remove an item to drop below the threshold
6. Verify the delivery fee reappears

Substitution Flows (TC-07 to TC-11)

TC-07: Accept substitution

1. Place an order and trigger a substitution prompt (via the test API)
2. Verify the substitution popup displays the original item and the suggested replacement
3. Verify a price comparison is displayed
4. Tap "Accept"
5. Verify the cart updates with the substitute item
6. Verify the order total recalculates

TC-08: Reject substitution

1. When the substitution prompt appears
2. Tap "Reject" or "Remove Item"
3. Verify the original item is removed from the order
4. Verify the order total decreases
5. Verify an "Item removed" confirmation appears

TC-09: Substitution timeout

1. When the substitution prompt appears
2. Do not respond for 60 seconds
3. Verify the default action is applied (auto-accept or auto-reject, based on the platform setting)
4. Verify the cart updates accordingly

TC-10: Multiple substitutions in one order

1. Place an order with 10+ items
2. Trigger 3 substitution prompts sequentially (via the test API)
3. Verify each prompt displays the correct original item and suggested replacement
4. Accept the first substitution
5. Reject the second substitution
6. Allow the third substitution request to timeout
7. Verify the final cart reflects all three decisions correctly

TC-11: Substitution with price difference

1. Trigger a substitution where the replacement item is more expensive
2. Verify the substitution prompt clearly displays the price difference
3. Tap "Accept"
4. Verify the cart total increases by the correct amount

Picking and Live Status (TC-12 to TC-15)

TC-12: Picking progress updates

1. After the order is placed, navigate to the tracking screen
2. Verify the "Picking in progress" status is displayed
3. Verify the item picking progress is displayed (e.g., "3 of 8 items picked")
4. Wait 15 seconds
5. Verify the picking progress count has increased

TC-13: Order packed status

1. After all items are picked (via the test API trigger)
2. Verify the status changes to "Order Packed"
3. Verify the message "Waiting for delivery partner" (or similar) is displayed

TC-14: Weight adjustment notification

1. After the picker weighs the produce
2. Verify a "Price adjusted" notification appears for weight-based items
3. Verify the adjusted price is displayed in the order details
4. Verify the order total updates accordingly

TC-15: Delivery partner assigned after packing

1. After the order is packed, trigger delivery partner assignment (via the test API)
2. Verify the status changes to "Delivery partner on the way"
3. Verify the delivery partner's name and ETA are displayed
4. Verify live map tracking is activated

Checkout and Payment (TC-16 to TC-18)

TC-16: Checkout with delivery slot selection

1. Add items to the cart above the minimum order value
2. Tap "Checkout"
3. Verify available delivery slots are displayed
4. Select a delivery slot
5. Verify the selected slot is highlighted
6. Verify the selected delivery time is reflected in the order summary

TC-17: Delivery slot expiry during checkout

1. Select a delivery slot
2. Wait for the slot to expire (or trigger expiry via the test API)
3. Verify an expired slot message appears
4. Verify new available delivery slots are displayed
5. Verify selecting a new slot updates the delivery time

TC-18: Final price adjustment at checkout

1. Complete an order containing weight-based items
2. After picking and weight adjustment
3. Verify the final total on the payment screen reflects the actual weights
4. Verify the itemized breakdown displays the adjusted prices
5. Complete the payment
6. Verify the receipt displays the final adjusted amounts

Delivery and Post-Order (TC-19 to TC-20)

TC-19: Delivery within promised window

1. After the delivery partner is assigned
2. Verify an ETA countdown is displayed
3. Verify the ETA falls within the promised delivery window
4. After delivery (via the test API)
5. Verify the status changes to "Delivered"
6. Verify the delivery timestamp is within the promised delivery window

TC-20: Report missing or wrong item

1. After delivery, navigate to the order details
2. Tap "Help" or "Report Issue"
3. Select "Missing Item" or "Wrong Item"
4. Verify the order's item list is displayed for selection
5. Select the affected item
6. Verify a refund or redelivery option is offered

How Does Vision AI Handle Quick Commerce Testing?

Quick commerce is where Vision AI's advantage is sharpest. The three hardest flows substitutions, live picking status, and weight-based price adjustments are all visual, ephemeral, and dynamic.

Substitution prompts: Drizz sees the substitution popup the moment it appears on screen, reads the original item name, replacement name, and price comparison visually, and taps Accept or Reject. No element ID needed. When the platform redesigns the substitution prompt next sprint, Drizz still sees a popup with two item names and two buttons.

Picking progress: "Verify picking progress shows a count that increases over time" is a visual observation. Drizz reads "3 of 8 items picked," waits, reads "5 of 8," and confirms progress. No dependency on the specific component rendering the progress count.

Price adjustments: "Verify total updated after weight adjustment" is a visual check. Drizz reads the displayed total before and after the adjustment event and confirms it changed. No need to assert a specific amount that varies with every order.

Out-of-stock indicators: Greyed-out items, "Unavailable" badges, crossed-out prices these are visual treatments that Appium can't reliably distinguish from active items through element properties. Drizz sees the visual difference the same way a customer does.

Delivery slot selection:  Slot cards with time windows, availability indicators, and fee labels are visually identifiable. When a slot expires, it visually changes (greyed out, removed, or marked "Expired"). Drizz observes the change without querying slot element states.

Conclusion

Quick commerce grocery testing requires a mindset shift from every other type of delivery testing. The 15-minute promise compresses every flow to the point where traditional test execution is slower than the product itself. Inventory is a moving target. Prices are estimates until the picker weighs the produce. Substitution prompts appear and disappear in seconds. Delivery slots expire while the customer is still browsing.

The teams that test quick commerce successfully don't write tests that assert specific inventory, specific prices, or specific slot times. They write tests that validate patterns: "an item was substituted and the cart updated," "the total changed after weight adjustment," "the delivery slot expired and new options appeared." Structural validation over data validation.

Vision AI is architecturally suited for this because every critical quick commerce flow substitutions, picking progress, price adjustments, slot expiry is a visual, dynamic event that the customer observes on screen. If the customer can see it, Drizz can test it. If the customer can't see it, the test should fail.

Get started with Drizz

Frequently Asked Questions

How is grocery app testing different from food delivery app testing?

Grocery apps add real-time inventory management, mid-order substitution flows, weight-based variable pricing, dark store catalog discrepancies, and 2-minute delivery slot windows. Food delivery has fixed menu prices, no substitution during preparation, and longer delivery windows (25-45 minutes). Grocery testing must handle significantly more dynamic state changes during a single order.

Can you automate substitution flow testing?

Yes, using a test API that triggers substitution events combined with Vision AI to observe the visual result. The test API pushes "item X unavailable, suggest Y as substitute," and Drizz validates that the substitution prompt appears with the correct items, responds to accept/reject, and confirms the cart updates accordingly.

How do you test weight-based pricing when the weight varies every order?

Test structurally: "verify the price displayed changes after weight adjustment" rather than "verify price is 19.20." Vision AI reads whatever price appears on screen and confirms it changed from the original estimate. The specific amount doesn't matter for regression testing — what matters is that the recalculation logic works and the UI updates correctly.

What's the biggest QA challenge in quick commerce?

Inventory-catalog discrepancy: the customer sees "In Stock" but the picker finds empty shelves. This creates substitution cascades, cart modifications, and price changes mid-order all within a 5-minute picking window. Testing this requires simulating real-time inventory changes during order processing, which most QA environments aren't set up to do.

How many test cases does a grocery quick commerce app need?

A production quick commerce app typically maintains 80-120 automated test cases: 20-25 for browse and cart (including inventory edge cases), 15-20 for substitution flows, 10-15 for picking and live status, 15-20 for checkout and payment (including weight adjustments), 10-15 for delivery and post-order, and 10-15 for device compatibility and performance under low memory.