Use Case Testing Explained | Basic, Alternative & Exception Flow Design + Playwright Implementation

Use case testing is a test design technique that converts a user’s end-to-end operation flow — the sequence of actions a user takes to achieve a goal — into test scenarios. It’s especially effective for E2E test scenario design and for prioritizing regression testing.

Use case testing lets you convert “what users actually do” directly into test scenarios — catching the user-perspective bugs that slip through as “technically works, but unusable in practice.”

“All the unit tests pass, but the app breaks when you actually use it.” “We only tested the happy path, and a bug from a real user flow hit production.” — these problems stem from a lack of user-perspective test design.

• Unit and functional tests alone can’t verify the full user operation flow
• Only the basic flow (happy path) gets tested — alternative and exception flows are overlooked
• Test scenarios are written from an engineer’s perspective, not a user’s — diverging from real usage

Use case testing solves these problems. This article covers everything from the concept, to designing scenarios, to implementing them as Playwright E2E tests.

What Is Use Case Testing?

Use case testing is a test design technique that converts “the sequence of actions a user takes to achieve a goal using the system (the use case)” into test scenarios.

For the use case “purchase a product,” the sequence is: log in → select item → add to cart → enter payment details → confirm order → view completion. Use case testing turns this sequence directly into test scenarios. Because it verifies the system from the user’s perspective, it finds bugs that only appear across the full flow — things unit tests will never catch.

What’s the Difference Between Use Case Testing and State Transition Testing?

Both techniques deal with flows, but use case testing and state transition testing have different perspectives and goals. They’re easy to confuse in practice, so let’s clarify.

What’s the Difference Between Use Case Testing and E2E Testing?

These two concepts are commonly confused, but they serve completely different roles.

What Are the Core Components of Use Case Testing?

Use case testing is built on three flow types: the basic flow, alternative flows, and exception flows.

Example ①: Test Design for a Purchase Use Case

Here’s the “purchase a product” use case for an e-commerce site, broken down into basic flow, alternative flows, and exception flows.

Basic Flow (Happy Path)

Alternative Flows (Valid, Different Path)

Exception Flows (Error / Abnormal)

Example ②: Test Design for a User Registration Use Case

Another common use case — “register as a member” — with all three flow types in a single table.

Applying Use Case Testing to Playwright × pytest

Scenarios designed with use case testing translate directly into Playwright × pytest E2E tests. The production best practice is 1 use case = 1 test file.

Folder Structure

tests/
├── conftest.py
└── e2e/
    ├── test_purchase.py        # Use case: Purchase a product
    ├── test_register.py        # Use case: Register as a member
    └── test_login.py           # Use case: Log in

test_purchase.py — E2E Tests for the Purchase Use Case

import pytest
from playwright.sync_api import Page, expect

# ── Basic Flow ───────────────────────────────────
def test_purchase_basic_flow(logged_in_page: Page):
    """Basic flow: logged-in user purchases a product"""
    # Step 2: Select product
    logged_in_page.goto("localhost:3000/products/1")
    expect(logged_in_page.locator("h1.product-title")).to_be_visible()

    # Step 3: Add to cart
    logged_in_page.click("#add-to-cart")
    expect(logged_in_page.locator(".cart-badge")).to_have_text("1")

    # Step 4: Proceed to checkout
    logged_in_page.goto("localhost:3000/cart")
    logged_in_page.click("#checkout-btn")

    # Step 5: Confirm order
    logged_in_page.fill("#card-number", "4111111111111111")
    logged_in_page.fill("#expiry", "12/26")
    logged_in_page.fill("#cvv", "123")
    logged_in_page.click("#confirm-order-btn")
    expect(logged_in_page.locator(".order-complete")).to_be_visible()

# ── Alternative Flow ─────────────────────────────
def test_purchase_with_coupon(logged_in_page: Page):
    """Alternative flow: purchase with coupon applied"""
    logged_in_page.goto("localhost:3000/cart")
    logged_in_page.fill("#coupon-input", "DISCOUNT10")
    logged_in_page.click("#apply-coupon-btn")
    # Verify the discounted amount is displayed
    expect(logged_in_page.locator(".discount-amount")).to_be_visible()

# ── Exception Flow ───────────────────────────────
def test_purchase_payment_failure(logged_in_page: Page):
    """Exception flow: error shown on payment failure, cart retained"""
    logged_in_page.goto("localhost:3000/cart")
    logged_in_page.click("#checkout-btn")
    # Pay with an invalid card number
    logged_in_page.fill("#card-number", "0000000000000000")
    logged_in_page.click("#confirm-order-btn")
    # Verify error message is shown
    expect(logged_in_page.locator(".payment-error")).to_be_visible()
    # Verify cart contents are retained
    expect(logged_in_page.locator(".cart-badge")).to_have_text("1")

⚠️ 4 Common Pitfalls in Use Case Testing

Here are the mistakes that are easy to make when designing use case tests in practice.

FAQ

📋 Summary

The greatest value of use case testing is starting from “what users actually do” — systematically uncovering cross-flow bugs that unit tests will never find. Start by writing out the basic, alternative, and exception flows for a “purchase a product” or “register an account” use case in a service you already work on.