How to Write Test Cases for Onboarding Flow (With Examples)

June 24, 2026 · 17 min read · How-To Guides

How to Write Test Cases for Onboarding Flow (With Examples): Core Principles

Writing test cases for an onboarding flow starts with a clear definition of what onboarding means for the product under test. Onboarding is the sequence of screens, forms, permissions, and optional tutorials that a new user encounters from the moment they launch the app or visit the site until they reach the first “core” screen where they can accomplish a primary task. Because onboarding sets expectations, any friction here directly impacts activation, retention, and brand perception. Therefore, test cases must verify not only that each step works as designed but also that the flow gracefully handles invalid input, interruptions, and varied user contexts.

A test case is a single, executable verification that maps to one or more requirements. Its anatomy consists of:

Test Case ID – a unique, stable identifier (e.g., ONB‑001).
Title – a short, descriptive phrase that can be read in a test‑run report.
Preconditions – the state of the system, device, or account before the first step (e.g., “fresh install, no existing user data, network available”).
Steps – an ordered list of actions the tester or automation script performs. Each step should be atomic and unambiguous (e.g., “Tap the ‘Get Started’ button”).
Expected Result – the observable outcome after the final step, expressed as a pass/fail criterion (e.g., “Welcome screen displays with the user’s name pre‑filled from the OAuth token”).
Postconditions (optional) – the state left behind that may affect subsequent tests (e.g., “User is logged in and redirected to the home dashboard”).

When you write test cases, keep each one focused on a single verification point. Avoid bundling multiple assertions into a single case; instead, split them so that a failure points directly to the offending step. This practice improves traceability, simplifies root‑cause analysis, and makes maintenance easier when the UI changes.

How to Write Test Cases for Onboarding Flow (With Examples): Building the Test Matrix

A test matrix is a tabular view of all test cases that lets you see coverage at a glance. The matrix should include the columns described above plus any metadata that helps prioritization (e.g., priority, risk level, associated requirement IDs). Below is a worked example that contains more than twenty test cases for a typical mobile‑app onboarding flow that includes:

Welcome screen with a “Get Started” button.
Permission request for push notifications.
Email/phone entry with password sign‑up form (email, password, confirm password).
Optional social‑login buttons (Google, Apple).
Terms of service checkbox.
Final “Create Account” button that leads to a tutorial carousel.
Skip tutorial option).

ID	Preconditions	Steps	Expected Result
ONB‑001	Fresh install, no network	1. Launch app. 2. Observe welcome screen.	Welcome screen is displayed; “Get Started” button is enabled but shows a toast “No internet connection”.
ONB‑002	Fresh install, network available Launch app app.. 2 2. . Tap Tap the the ““Get Get Started Started”” button button..	Permission Permission dialog dialog for for push push notifications notifications appears appears..
ONB‑003	App launched, permission dialog shown	1. Tap “Allow” on the push‑notification prompt.	Permission is granted; app proceeds to the email/phone entry screen.
ONB‑004	App launched, permission dialog shown	1. Tap “Deny” on the push‑notification prompt.	Permission is denied; app proceeds to the email/phone entry screen (no push‑notification feature enabled).
ONB‑005	Email/phone entry screen displayed, no prior data	1. Enter a valid email address “user@example.com”. 2. Tap “Next”.	Password field becomes visible and enabled; email address is retained in the field.
ONB‑006	Email field contains a valid email, password field visible	1. Enter a password that meets policy (≥8 chars, 1 upper, 1 lower, 1 digit). 2. Tap “Next”.	Confirm‑password field becomes visible; password is masked.
ONB‑007	Confirm‑password field visible	1. Re‑enter the same password. 2. Tap “Next”.	Terms of service screen appears with checkbox unchecked.
ONB‑008	Terms of	1. Scroll to read the full terms (if scrollable). 2. Tap the checkbox to select it. 3. Tap “Create Account”.	Account is created; backend returns a 201 response; user is redirected to the tutorial carousel.
ONB‑009	Terms screen, checkbox unchecked	1. Tap “Create Account” without checking the box.	Inline validation error appears: “You must accept the terms of service”.
ONB‑010	Email entry screen	1. Enter an email with missing “@” (e.g., “userexample.com”). 2. Tap “Next”.	Inline error: “Please enter a valid email address”.
ONB‑011	Email entry screen	1. Enter an email longer than 254 characters. 2. Tap “Next”.	Inline error: “Email address is too long”.
ONB‑012	Password field	1. Enter a password with only lowercase letters (e.g., “password”). 2. Tap “Next”.	Inline error: “Password must contain at least one uppercase letter, one digit, and be 8+ characters”.
ONB‑013	Password field	1. Enter a password with leading/trailing spaces (e.g., “ Abcdef1 ”). 2. Tap “Next”.	System trims spaces and accepts the password if it meets policy after trimming; otherwise shows appropriate error.
ONB‑014	Confirm‑password field	1. Enter a password that differs from the first password entry. 2. Tap “Next”.	Inline error: “Passwords do not match”.
ONB‑015	Any screen with a network call	1. Enable airplane mode before launching the app. 2. Attempt to proceed through the flow.	At the first network‑dependent step (usually after “Create Account”), an offline‑friendly message appears and the user can retry when connectivity returns.
ONB‑016	Account created successfully, tutorial carousel shown	1. Swipe left on the first tutorial card. 2. Swipe left on the second card. 3. Tap “Got It” on the final card.	Tutorial carousel dismisses; user lands on the home dashboard.
ONB‑017	Tutorial carousel shown	1. Tap the skip link (usually top‑right) on the first card.	Tutorial carousel dismisses immediately; user lands on the home dashboard.
ONB‑018	Home dashboard reached	1. Press the device back button.	App shows a confirmation dialog: “Are you sure you want to exit? Your progress will be saved.”
ONB‑019	Confirmation dialog shown	1. Select “Stay”.	Dialog dismisses; user remains on the home dashboard.
ONB‑020	Confirmation dialog shown	1. Select “Exit”.	App closes; no data is lost because the account was already created on the server.
ONB‑021	Fresh install, language set to Spanish (via device settings)	1. Launch app. 2. Observe all onboarding screens.	All text appears in Spanish; placeholders and validation messages are correctly localized.
ONB‑022	Fresh install, TalkBack enabled (Android) or VoiceOver enabled (iOS)	1. Launch app. 2. Navigate using swipe gestures and listen to spoken hints.	Every interactive element announces its purpose, state, and value; focus order follows visual order; no trapped focus.
ONB‑023	Fresh install, font size set to largest accessibility setting	1. Launch app. 2. Verify that all text scales without clipping or overflow.	UI elements resize gracefully; no horizontal scrolling is required; all buttons remain tappable.
ONB‑024	Fresh install, low‑end device (≤1 GB RAM, Android 8)	1. Launch app. 2. Complete the onboarding flow.	Flow completes within 15 seconds; no dropped frames; memory usage stays below 200 MB.
ONB‑025	Fresh install, high latency network (simulated 200 ms RTT)	1. Launch app. 2. Proceed through each step, observing spinner behavior.	Network‑dependent steps show a spinner; timeout is not reached; retry mechanism works if a request fails.
ONB‑026	Fresh install, date set to a future date (e.g., +1 year)	1. Launch app. 2. Attempt to create an account.	If the backend validates birth‑date or expiration fields, appropriate error is shown; otherwise account creation proceeds normally.
ONB‑027	Fresh install, device locale uses right‑to‑left language (e.g., Arabic)	1. Launch app. 2. Observe layout direction.	All layouts mirror correctly; text is right‑aligned; icons that have directional meaning are mirrored.
ONB‑028	Fresh install, user has an existing account (data cleared from app but not server)	1. Launch app. 2. Enter credentials for the existing account on the sign‑in screen (if offered).	Sign‑in succeeds; user is taken directly to home dashboard, bypassing the sign‑up flow.
ONB‑029	Fresh install, user attempts to sign up with an email already registered	1. Enter an email that exists in the backend. 2. Complete password fields and terms. 3. Tap “Create Account”.	Backend returns a 409 conflict; app shows error: “An account with this email already exists. Please sign in or use a different email.”
ONB‑030	Fresh install, user enables “Hide password” toggle (if provided)	1. Enter a password. 2. Tap the eye‑icon to hide/show. 3. Verify masking behavior.	Password characters are replaced with dots when hidden; visible when shown; toggle state persists across screen rotations.

How to use the table

Each row represents a single test case that can be executed manually or automated.
The Preconditions column captures the exact device, network, and state setup required.
The Steps column is written in imperative mood, avoiding ambiguous pronouns.
The Expected Result column is observable and measurable (UI text, toast, dialog, network response, screen transition).
For automation, you can map each step to a command in your test framework (see the snippets later in this article).

How to Write Test Cases for Onboarding Flow (With Examples): Negative and Edge Cases

While the matrix above already contains a number of negative scenarios (invalid email, missing terms, network loss), it is useful to categorize them explicitly so that reviewers can see the balance between positive and negative coverage.

Negative Test Cases (validation & error handling)

ID	Description	Expected Result
ONB‑N01	Submit email without “@” character	Inline error: “Please enter a valid email address”.
ONB‑N02	Submit email with multiple “@” characters	Inline error: “Please enter a valid email address”.
ONB‑N03	Submit password shorter than 8 characters	Inline error: “Password must be at least 8 characters”.
ONB‑N04	Submit password lacking an uppercase letter	Inline error: “Password must contain at least one uppercase letter”.
ONB‑N05	Submit password lacking a digit	Inline error: “Password must contain at least one digit”.
ONB‑N06	Submit password containing only spaces	Inline error: “Password cannot be empty”.
ONB‑N07	Submit confirm‑password that does not match password	Inline error: “Passwords do not match”.
ONB‑N08	Attempt to create account without accepting terms of service	Inline error: “You must accept the terms of service”.
ONB‑N09	Attempt to create account with an email already registered (case‑insensitive)	Error dialog: “An account with this email already exists”.
ONB‑N10	Submit form while device is in airplane mode (network unavailable)	Friendly offline message; option to retry when connectivity returns.
ONB‑N11	Submit form with a future birth‑date (if collected)	Validation error: “Birth date must be in the past”.
ONB‑N12	Submit form with special characters that could lead to injection (e.g.,