Use Case Testing
Use Case Testing derives test cases directly from use cases or user stories — the documented descriptions of how users interact with the system to achieve goals. It bridges the gap between requirements and test cases, ensuring that every user journey the product team promised is actually tested. Use case tests are written from the user's perspective, not the developer's.
Use Case Test Design Process
- Step 1: Identify the use case or user story (e.g., 'As a customer, I want to add items to my cart so I can purchase them later')
- Step 2: Extract the main success scenario (happy path)
- Step 3: Identify alternative scenarios (valid variations of the main flow)
- Step 4: Identify exception scenarios (invalid inputs, system errors, edge cases)
- Step 5: Create test cases for each scenario
- Coverage target: Main flow + all alternatives + all exceptions = full use case coverage
Use Case Testing for Shopping Cart
// ══════════════════════════════════════════════════════════════
// USE CASE: UC-05 — Add Item to Shopping Cart
// Actor: Registered Customer (Alice)
// Goal: Add a product to the cart for later purchase
// ══════════════════════════════════════════════════════════════
// ── MAIN SUCCESS SCENARIO (Test Case 1) ───────────────────────
// TC-UC05-001: Add available item to cart
// Steps:
// 1. Alice is logged in, on the product detail page
// 2. Product "Wireless Headphones" is in stock (qty: 50)
// 3. Quantity is set to 1 (default)
// 4. Alice clicks "Add to Cart"
// Expected:
// - Cart icon shows badge (qty: 1)
// - Toast: "Wireless Headphones added to cart"
// - Cart page shows: Wireless Headphones, qty: 1, price: $79.99
// - Product stock: 49 (reserved)
// ── ALTERNATIVE SCENARIOS ─────────────────────────────────────
// TC-UC05-002: Add same item to cart twice
// Expected: Cart shows qty: 2, not two separate entries
// TC-UC05-003: Change quantity to 3 before adding
// Expected: Cart shows qty: 3, total = 3 × $79.99 = $239.97
// TC-UC05-004: Add item already in cart from different product page
// Expected: Quantity increments (existing: 1 → becomes: 2)
// TC-UC05-005: Add item as guest user (not logged in)
// Expected: Item added to guest cart, persists for session duration
// ── EXCEPTION SCENARIOS ───────────────────────────────────────
// TC-UC05-006: Add out-of-stock item
// Setup: Product has 0 stock
// Expected: "Add to Cart" button disabled, "Out of Stock" label shown
// TC-UC05-007: Request quantity exceeding available stock
// Setup: Product has 3 in stock, user selects qty: 10
// Expected: Error "Only 3 available in stock"
// TC-UC05-008: Add item while network is offline (offline mode)
// Expected: Graceful error, item not added, data not corrupted
// TC-UC05-009: Session expires during add-to-cart flow
// Expected: User redirected to login, cart item preserved after re-login
const testCases = [
{ id: "TC-UC05-001", type: "Main Success", description: "Add available item" },
{ id: "TC-UC05-002", type: "Alternative", description: "Add same item twice" },
{ id: "TC-UC05-003", type: "Alternative", description: "Custom quantity" },
{ id: "TC-UC05-004", type: "Alternative", description: "Add from different page" },
{ id: "TC-UC05-005", type: "Alternative", description: "Guest user cart" },
{ id: "TC-UC05-006", type: "Exception", description: "Out of stock" },
{ id: "TC-UC05-007", type: "Exception", description: "Exceeds stock qty" },
{ id: "TC-UC05-008", type: "Exception", description: "Network offline" },
{ id: "TC-UC05-009", type: "Exception", description: "Session expired mid-flow" },
];Common Mistakes
- Only testing the main success scenario — alternatives and exceptions contain the majority of real-world bugs
- Writing use cases from the developer's perspective — use case tests must be from the USER's perspective, not the implementation
- Missing actor pre-states — who the user is (guest vs logged-in, role, subscription tier) drastically changes expected behavior
- Not tracing test cases back to requirements — each use case test should reference its source requirement for traceability
Tip
Tip
Practice Use Case Testing in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Technical diagram.
Practice Task
Note
Practice Task — (1) Write a working example of Use Case Testing from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Use Case Testing is skipping edge case testing — empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Use Case Testing derives test cases directly from use cases or user stories — the documented descriptions of how users interact with the system to achieve goals.
- Step 1: Identify the use case or user story (e.g., 'As a customer, I want to add items to my cart so I can purchase them later')
- Step 2: Extract the main success scenario (happy path)
- Step 3: Identify alternative scenarios (valid variations of the main flow)