A test scenario is a one-line description of what you're testing. It says WHAT to verify, not HOW to verify it. "Verify that a user can log in with valid credentials" is a test scenario. The specific steps (tap email field, type "user@test.com," tap password field, type "Test@1234," tap "Log in," verify home screen loads) are the test case.
The distinction matters because scenarios are fast to write, easy to review with stakeholders, and give you a bird's-eye view of test coverage. Test cases are slow to write, hard to review in a meeting, and give you execution-level detail. You need both. Scenarios first (what are we testing?), then test cases underneath them (how exactly?).
Most test scenario guides give you 10-15 generic web examples. In this we gives you 30 scenarios organized by mobile app module, including the mobile-specific scenarios (interrupts, OEM behavior, device rotation, push notifications) that web-focused guides don't cover. For the detailed test case format, see our test case template. For a guide on writing good test cases underneath these scenarios, see how to write test cases for mobile apps.
How to write a good test scenario
A good scenario follows three rules:
One feature per scenario. "Verify login and checkout" is two scenarios smashed together. Split them.
Start with a verb. "Verify," "Validate," "Ensure," "Confirm." This keeps scenarios action-oriented: "Verify that the user can apply a promo code at checkout."
Write from the user's perspective. "Verify that the login API returns a 200 status code" is an API test, not a user scenario. "Verify that a user can log in with valid credentials" is a user scenario. Scenarios describe what the user experiences, not what the system does internally.
Module 1: authentication (6 scenarios)
- Verify that a new user can sign up with valid email and password
- Verify that a registered user can log in with valid credentials
- Verify that the app shows an error when the user enters an incorrect password
- Verify that the app locks the account after 5 consecutive failed login attempts
- Verify that a user can log in using biometrics (Face ID or fingerprint) after an initial email login
- Verify that the user remains logged in after closing and reopening the app
For the full breakdown of login test cases across credentials, biometrics, SSO, and OTP, see our login testing guide.
Module 2: search and browsing (5 scenarios)
- Verify that search results appear within 2 seconds after the user types a query
- Verify that search results update when the user applies a filter (price range, rating, category)
- Verify that the app shows a "No results found" message when the search query has no matches
- Verify that the restaurant/product list updates when the user changes their delivery address or location
- Verify that infinite scroll loads the next batch of results when the user scrolls to the bottom of the list
Module 3: cart and checkout (6 scenarios)
- Verify that adding an item updates the cart icon with the correct item count
- Verify that removing the last item from the cart shows an "Empty cart" message
- Verify that the cart total recalculates correctly when item quantity is increased or decreased
- Verify that a valid promo code reduces the total by the correct percentage or amount
- Verify that an expired promo code shows an appropriate error message
- Verify that the user can complete checkout with a saved payment method
Module 4: payments (4 scenarios)
- Verify that a payment with a valid credit card completes and shows an order confirmation
- Verify that a payment with an expired card shows a clear error message
- Verify that the app does not double-charge the user if the payment request times out and retries
- Verify that the order confirmation shows the correct total after promo code, tax, and delivery charges
Module 5: push notifications and deep links (4 scenarios)
- Verify that the user receives a push notification when their order status changes to "Out for delivery"
- Verify that tapping a push notification opens the correct screen (order tracking, not the home screen)
- Verify that a deep link from an email or SMS opens the app directly to the linked screen
- Verify that a deep link works correctly when the app is not running (cold start)
Module 6: mobile-specific scenarios (5 scenarios)
These are the scenarios that web-focused test scenario guides don't include. They're unique to mobile because they depend on device behavior, hardware, and real-world interruptions.
- Verify that the checkout state (items, address, payment) is preserved after the user receives and answers a phone call
- Verify that form data (name, email, address) is preserved after the user rotates the device from portrait to landscape
- Verify that all button labels and text remain readable when the device font size is set to "Large" or "Extra Large"
- Verify that the app recovers gracefully after being killed during a payment (no double-charge, no lost confirmation)
- Verify that OEM-specific permission dialogs (Samsung battery optimization, Xiaomi security popup) do not permanently block the app on first launch
Scenarios 26-30 are where mobile teams find the bugs that users report most frequently. A checkout flow that works perfectly on the emulator can fail on a real Samsung because the keyboard covers the "Place Order" button (related to scenario 28), or on a Xiaomi because the security popup blocks the first screen (scenario 30). For more on these device-specific patterns, see our android emulator vs real device comparison.
Scenario vs test case: when to use which
Use scenarios when you're planning. In a sprint planning meeting, you review the 30 scenarios above and ask: "Are we covering everything? What's missing?" Scenarios are fast to create, easy for PMs and developers to review, and give you a coverage map.
Use test cases when you're executing. The tester opens scenario #17 ("Verify that the user can complete checkout with a saved payment method") and follows the detailed test case: preconditions (user logged in, saved card on file, item in cart), steps (tap Checkout, select saved card, tap Place Order), expected result (confirmation screen in under 3 seconds, correct total displayed).
Use both when you're building a test plan. The plan lists which scenarios are in scope for this release. Each scenario references the test cases underneath it.
Automating scenarios
Each of the 30 scenarios above can be automated. The question is how.
With traditional tools, you'd write the scenario as a title, then implement each test case as code: Espresso for Android, XCUITest for iOS, or Appium for cross-platform. Each test case requires selectors, page objects, and maintenance when the UI changes.
With Drizz, the scenario almost IS the test. Scenario #2 ("Verify that a registered user can log in with valid credentials") becomes:
Tap on the email field
Type "user@test.com"
Tap on the password field
Type "Test@1234"
Tap "Log in"
Validate "Welcome" is visible
No translation step between the scenario description and the executable test. The Vision AI finds elements visually on real devices. Marcus Johnson, a Senior SDET, described what changed for his team: "Our biggest pain was flaky tests on dynamic screens. Drizz handled those flows way better than what we had before."
For the full automation strategy and which scenarios to automate first, see our strategy guide.
FAQ
What is a test scenario?
A one-line description of what functionality to test, written from the user's perspective. It says WHAT to verify ("Verify that a user can log in"), not HOW to verify it. Multiple test cases sit underneath each scenario.
What's the difference between a test scenario and a test case?
A scenario is high-level: "Verify checkout works." A test case is detailed: specific steps, test data, device, expected result. Scenarios are for planning and coverage review. Test cases are for execution. You need both.
How many test scenarios should a mobile app have?
It depends on the app's complexity. A simple app might have 30-50 scenarios. A complex e-commerce or fintech app might have 200+. Organize them by module (auth, search, cart, payment) and prioritize by revenue impact.
Should test scenarios include mobile-specific conditions?
Yes. Scenarios for interrupts (phone calls during checkout), device rotation, font scaling, push notification deep links, and OEM popup handling are the ones that catch the bugs users actually report. Web-focused guides miss these entirely.
Can non-technical team members write test scenarios?
Yes. Scenarios don't require technical knowledge because they describe user behavior, not system internals. A PM can write "Verify that a user can apply a promo code at checkout" without knowing how the promo service works.
How do test scenarios relate to test plans?
A test plan defines which scenarios are in scope for a release, who tests them, on which devices, and by when. Scenarios are the building blocks of the plan. Each scenario references the test cases underneath it.
