The help button is the most important button in your delivery app that your QA team almost never clicks during regression.
Every delivery app has an in-app support layer: chatbot flows, live agent chat, order-specific help menus, photo uploads for issue reporting, refund request forms, and escalation paths. This system sits behind one tap the "Help" or "?" icon on the order screen and it determines whether a failed delivery becomes a retained customer or a one-star review followed by an uninstall.
Yet in most delivery app QA teams, support flows get tested once during initial development and never again. The chatbot conversation trees change weekly as the support team optimizes deflection rates. The live agent handoff logic gets updated monthly. The refund calculation rules change with every policy revision. And none of these changes trigger a regression run because the help button isn't in anyone's critical path test suite.
This guide covers what specifically needs testing in in-app support, why it breaks more often than teams realize, why traditional automation struggles with chat interfaces, and how to build support flow testing that actually runs on every build.
For the complete delivery app testing checklist, see 30 Test Cases from Order to Doorstep. For checkout-specific testing, see Why Checkout Flows Break More Than Anything Else. QA regression suites are built around the happy path: search, browse, cart, checkout, payment, tracking, delivery. Support flows are unhappy paths they only trigger when something goes wrong. Most automated test suites don't simulate failure scenarios that push users to the help button.
Chatbot trees are typically managed by the support operations team through a chatbot platform (Intercom, Freshdesk, Zendesk, custom), not through the app's codebase. When the support team adds a new conversation branch or changes the refund flow, no app release is triggered meaning no regression suite runs. The chatbot UI changes silently.
A single support interaction touches the chatbot engine (conversation logic), the live agent platform (handoff and routing), the order management system (fetching order details), the payment system (processing refunds), the notification system (sending resolution updates), and the app's UI layer (rendering all of this). A failure in any one system breaks the support experience, but each system is owned by a different team.
The support operations team owns the chatbot content. The engineering team owns the app UI. The payments team owns refund logic. The platform team owns the live agent infrastructure. Support flow testing falls between all of them and often falls through the cracks entirely.
A typical chatbot has 3 levels: issue category ("Order issue") → specific problem ("Missing item") → resolution ("Request refund"). Each path is a test case, and the tree changes weekly as the support team optimizes.
Test: Every L1 → L2 → L3 path navigates correctly, "Back" returns without losing context, correct resolution triggers at each endpoint, and new branches render properly.
When the chatbot can't resolve, the user hits a live agent queue. This transition is where most support flows fail.
Test: Queue position displays and updates in real-time, agent assignment shows a visual change, agent's first message appears in the same thread (not a new screen), no-agent fallback works (email form or callback), and mid-chat agent disconnection recovers gracefully.
Tapping "Help" on a specific order should pre-load that order's context ID, items, status, payment method. The agent shouldn't ask "What's your order number?"
Test: Chat opens with correct order context visible, references the right order (not a recent different one), and opening from the general help menu prompts order selection.
Users report issues with photos: wrong item, damaged packaging, spilled food.
Test: Camera and gallery both launch from chat, photo uploads with thumbnail in thread, works on 3G with progress indicator, failure shows retry (not silent drop), and multiple photos upload in sequence.
The most sensitive flow. Refund amount must be correct, routed to the right payment method, and confirmed with a timeline.
Test: Partial refund matches correct items, refund routes to original method (UPI to UPI, card to card), timeline displays ("5-7 business days"), status is trackable after chat ends, and double-submit doesn't process twice.
Test: Rating prompt appears after chat closes (not during), star/emoji scale is tappable, optional text feedback works, submit shows confirmation, skip closes without error.
The hardest scenario: user opens chat while their order is still in transit. Chat must show real-time order status alongside the conversation without either interfering.
Test: Order status bar updates in real-time while chatting, sending a message doesn't interrupt tracking, delivery notification appears even while in chat, and chat history persists if user navigates to tracking and back.
Delivery apps use custom chat SDKs or third-party platforms (Intercom, Freshdesk, custom WebView) that render messages with proprietary component structures. The element IDs inside these chat UIs don't follow standard conventions, change with SDK updates, and vary between chatbot messages, agent messages, and system messages. Appium tests written against Intercom SDK v3 break when v4 ships with different element structures.
Chat messages appear in real-time as they're received. The message list is a dynamic, growing view where new elements are appended at the bottom. Tests that assert "the third message says X" break when a system message is inserted above it, pushing everything down. Element position is unreliable in a chat thread.
When the support team changes a chatbot branch on Tuesday, no app build is triggered. The CI pipeline doesn't run. The existing tests don't execute against the new chatbot tree. By Friday, the chatbot has a new path that's completely untested and users who follow it hit a dead end.
Live agent handoff, queue position updates, and message delivery all have timing dependencies. A test that asserts "agent connected" 5 seconds after requesting handoff fails when the agent takes 15 seconds. A test that checks queue position may see "3" or "2" depending on when it reads the element.
Drizz validates support flows by reading the chat screen visually, the same way a customer reads messages, taps buttons, and observes status changes.
Chatbot navigation: "Tap 'Order issue,' verify next options appear, tap 'Missing item,' verify refund options appear." Drizz reads the button text visually and taps it regardless of which chatbot SDK rendered it or what element IDs the buttons have. When the support team renames "Missing item" to "Item not received" next week, update one line in the test.
Message verification: "Verify agent message appears in chat thread with timestamp." Drizz sees the message rendered on screen, reads the text, and confirms it appeared without needing to locate it by element index in a dynamic list.
Photo upload: "Tap camera icon, verify camera launches, take photo, verify thumbnail appears in chat." Drizz sees the camera icon visually, observes the camera viewfinder, and confirms the uploaded thumbnail renders in the chat thread.
Order context: "Open help on Order #12345, verify chat shows order ID and item list." Drizz reads the order information displayed in the chat header or context card visually.
Live order + chat: "While in chat, verify order status bar shows 'On the Way' and updates to 'Delivered.'" Drizz observes both the chat messages and the status indicator on the same screen simultaneously a visual test that captures the full user experience.
CSAT rating: "After chat closes, verify rating prompt appears, tap 4 stars, verify confirmation." Visual interaction that works regardless of how the rating component is implemented.
In-app support is the feature that saves customers you've already lost. A delivery that went wrong missing item, late arrival, wrong order is recoverable if the support experience is fast, contextual, and leads to resolution. It's unrecoverable if the chatbot hits a dead end, the agent handoff fails, the refund doesn't process, or the photo upload silently drops.
QA teams that add support flows to their regression suite catch the chatbot changes that break paths weekly, the SDK updates that break rendering monthly, and the refund logic changes that break calculations quarterly. The teams that don't test support flows learn about the breakage from customer churn data weeks after the damage is done.
For delivery apps where the help button is tapped thousands of times daily, support flow testing isn't a nice-to-have. It's the difference between a retained customer and a lost one. Support flows sit behind the "Help" button on the unhappy path they only trigger after a failed experience. Most regression suites are built around the happy path (browse, order, pay, receive). Additionally, chatbot content is managed by the support team, not engineering, so chatbot changes don't trigger app releases or regression runs.
Test structurally: "tap first option in Level 1, verify Level 2 options appear, tap first option in Level 2, verify resolution screen appears." This validates the navigation structure regardless of what the specific options are named. For content validation, maintain a lightweight chatbot tree map that's updated when the support team makes changes.
Vision AI can test the handoff flow (request agent, verify queue position, verify agent connected, verify first message appears) and the visual chat experience (messages render, timestamps display, photos upload). It cannot test the agent-side experience or agent routing logic those require agent platform testing tools.
Dead-end chatbot paths: the user taps through 3 levels of options and reaches a screen with no resolution action no refund button, no agent handoff, no ticket creation. Just a dead end with a "Was this helpful?" prompt. This happens when the support team adds a new category without connecting it to a resolution path.
A production delivery app typically needs 15-25 support-specific test cases: 5-8 chatbot tree paths (one per major issue category), 3-4 agent handoff scenarios (available, unavailable, disconnection), 2-3 photo upload scenarios, 2-3 refund processing paths, 1-2 CSAT rating flows, and 1-2 edge cases (live order + chat, multi-order context).