One Scenario, Two Families of Tests
A single test scenario often contains an implied “happy path” (everything goes right) plus multiple “negative paths” (something goes wrong and the system must respond safely and clearly). Designing both from the same scenario helps you avoid two common gaps: (1) only testing success, and (2) writing negative tests that are not tied to real user behavior.
Think of a scenario as a small story with conditions and outcomes. The happy path validates that the user can complete the goal under normal conditions. Negative paths validate that the system prevents invalid actions, protects data, and communicates problems clearly when assumptions are violated.
Happy Path vs. Negative Path (What Changes?)
- Happy path: Inputs are valid, the user is allowed to do the action, and dependencies (network, services, data) are available. Expected result is successful completion.
- Negative path: One assumption is flipped (invalid input, missing permission, expired session, service down). Expected result is safe failure: no unintended changes, clear message, and correct recovery options.
Step-by-Step: Derive Negative Tests by Flipping Assumptions
Use this practical method whenever you have a scenario and want balanced coverage.
Step 1: Write the “baseline” happy path in one sentence
Example (login): “A registered user enters a valid email and password and is taken to their dashboard.”
Step 2: List the assumptions hidden inside that sentence
Common assumption types to look for:
Continue in our app.
You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.
Or continue reading below...
Download the app
- Valid input: required fields present, correct format, acceptable length, allowed characters.
- Correct permissions: user is allowed to access the feature; account status is active.
- System availability: authentication service is up; database reachable; network stable.
- Session state: session is valid; CSRF token present; user not timed out.
- Data state: account exists; cart has items; inventory available.
For the login example, assumptions might be: email is provided, password is provided, email format is valid, credentials match an active account, user is not locked, session is not expired mid-flow, auth service responds.
Step 3: Flip one assumption at a time to create a negative path
Each negative test should change one main factor so the failure reason is clear. This makes debugging and maintenance easier.
- Flip “email is provided” → email missing
- Flip “email format is valid” → invalid format
- Flip “credentials match” → wrong password
- Flip “user is allowed” → unauthorized/locked user
- Flip “session is valid” → expired session
- Flip “service is available” → auth service error/timeout
Step 4: Define what “safe failure” means for each flip
Negative tests are not only about seeing an error; they also confirm the system behaves safely. For each negative path, specify expected behavior in three parts:
- User-facing feedback: message shown, field highlighted, tone and clarity.
- System behavior: no login created, no order placed, no data changed, no duplicate actions.
- Recovery: user can correct inputs, retry, re-authenticate, or contact support.
Common Negative Categories (and What to Check)
1) Missing required fields
Typical flips: leave a required field blank, remove it after autofill, submit with whitespace only.
- Expected: inline validation near the field, submit blocked (or server returns validation error), focus moves to the first invalid field.
- Also check: no partial action occurs (e.g., no account created, no order submitted).
2) Invalid formats
Typical flips: invalid email, invalid phone number, invalid postal code, invalid card number format, invalid date.
- Expected: clear format guidance (example format), consistent behavior across browser/client and server.
- Also check: the system does not accept “almost valid” values that later break downstream steps.
3) Unauthorized access (permissions)
Typical flips: user not logged in, user role lacks permission, user tries to access a restricted URL directly.
- Expected: redirect to login or “access denied” page; no sensitive data displayed; no action performed.
- Also check: API responses do not leak details (e.g., “user exists” vs. generic message).
4) Expired sessions
Typical flips: session times out during checkout, token expires before submitting a form, user opens a stale tab.
- Expected: user is asked to log in again; work is preserved when possible (e.g., cart retained); clear message that session expired.
- Also check: resubmitting does not create duplicates after re-authentication.
5) System messages and service failures
Typical flips: server error, timeout, dependency unavailable, rate limiting.
- Expected: friendly error message, retry option if appropriate, no technical stack traces shown to the user.
- Also check: logging/monitoring hooks (if observable), and that the UI does not get stuck in a loading state.
Worked Example: Expanding a Login Scenario into Balanced Coverage
Baseline scenario
“User logs in with email and password.”
Happy-path tests (examples)
- Valid email + valid password → user lands on dashboard; session created.
- Valid email + valid password with leading/trailing spaces → spaces trimmed (if intended) and login succeeds.
Negative-path tests derived by flipping assumptions
- Missing required fields: email empty, password provided → show ‘Email is required’; no login.
- Missing required fields: email provided, password empty → show ‘Password is required’; no login.
- Invalid format: email = “user@” → show ‘Enter a valid email address’; no login attempt (or server rejects).
- Invalid credentials: valid email, wrong password → show generic ‘Invalid email or password’; no session created.
- Unauthorized access/account state: locked/disabled account credentials → show appropriate message (often generic); user not logged in.
- Expired session/token: login page open for a long time, then submit → prompt to refresh/retry; no unexpected error page.
- System failure: auth service returns 500/timeout → show ‘We can’t log you in right now. Try again.’; user remains on login page; no partial login state.
Notice how each negative test changes one main assumption and checks both the message and the safety outcome (no session, no access).
Checklist: Negative Path Design from Any Scenario
- Identify assumptions: What must be true for success? (inputs, permissions, session, availability, data state)
- Flip one assumption per test: Keep the failure reason isolated.
- Cover required-field gaps: empty, whitespace, removed autofill values.
- Cover invalid formats: wrong pattern, too short/long, invalid characters, boundary values.
- Cover authorization: not logged in, wrong role, direct URL/API access.
- Cover session issues: timeout mid-step, stale tab, expired token.
- Cover system messages: timeout, 4xx/5xx errors, dependency down, rate limit.
- Define safe failure: no unintended changes, no duplicates, no data leaks.
- Define user recovery: can correct inputs, retry, re-authenticate, or get guidance.
- Keep expected results observable: message text/placement, navigation outcome, state changes (or lack of them).
Practice Task: Turn One Scenario into Balanced Positive/Negative Coverage
Option A: Login
Scenario: “A user logs in to access their account.”
Your task: Create 2 happy-path tests and 8 negative-path tests using the checklist.
- Happy path ideas: normal login; login with trimmed spaces; login with remembered email.
- Negative categories to include (at least one each): missing required fields, invalid formats, unauthorized access/account state, expired session, system message.
Template you can copy for each test:
Test idea: [short name] Assumption flipped: [e.g., “email format is valid” → invalid] Input/condition: [what you do] Expected: [message + no unintended state change + recovery]Option B: Checkout
Scenario: “A shopper checks out and places an order.”
Your task: Create 3 happy-path tests and 10 negative-path tests.
- Happy path ideas: card payment success; saved address; guest checkout (if supported).
- Negative categories to include: missing required fields (shipping address), invalid formats (postal code, card expiry), unauthorized access (attempt checkout without login if login required), expired session (cart/checkout timed out), system messages (payment gateway timeout).
For each negative test, explicitly state: 1) what should NOT happen (e.g., “order is not created”), 2) what message should appear, 3) what the user can do next (retry/edit/login).
