Use case testing

Use Case Testing Skill

Overview

Use Case Testing is a black-box test design technique defined in ISTQB Foundation Level Syllabus where test cases are derived from use case specifications. A use case describes an interaction between one or more actors (human users or external systems) and the system under test (SUT) to achieve a specific goal.

The technique systematically derives test cases by identifying all meaningful paths through the use case — the main flow (the happy path) and all alternate flows (deviations due to optional choices, validation failures, or exception conditions) — then combining them into scenarios that represent complete end-to-end journeys from the use case's starting point to an endpoint.

Core purpose: Verify that the system correctly delivers business value to actors through every meaningful path — not just the happy path — ensuring all flows are exercised and all preconditions/postconditions are verified.

Role of Use Case Testing vs. other techniques: Use Case Testing is responsible for identifying which flows and paths to test. It does not design the specific data values used within those paths. Once scenarios are identified, use Domain Testing (EP/BVA) to select specific test data for input fields, and Decision Table Testing for steps with multiple simultaneous conditions. These techniques are complementary: Use Case Testing provides the flow structure; other techniques populate the data.

→ For full theoretical background, see resources/theory.md.

Invoke Syntax

/use-case-testing [--file="path/to/output.md"]

Modes:

Mode	Syntax	Behavior
Default (conversation)	/use-case-testing	All analysis and test cases printed inline in the conversation as Markdown
File output	/use-case-testing --file="path/to/output.md"	All output (Flow Analysis, Scenario Matrix, Test Case Suite) written to the specified file. AI confirms path before writing.

Notes:

• --file mode requires a file-capable environment (e.g., claude.ai with computer tools enabled). If file tools are unavailable, AI will notify the user and fall back to conversation output.
• The path in --file is the desired output location. If the file already exists, AI will ask before overwriting.
• Both modes produce identical content — only the delivery differs.
• --file can be combined with any input: /use-case-testing --file="path/to/output.md" then paste the requirements.

When to Use

• A use case specification (UC spec) exists with defined: actor(s), preconditions, main flow, alternate flows, postconditions.
• A user story with acceptance criteria that describes actor-system interactions toward a goal (can be treated as an informal use case spec).
• Testing a feature end-to-end where the behavior is defined as a sequence of actor-system interactions.
• When the goal is to verify complete business flows — not isolated field validation or individual API endpoints.
• When integration between system components needs to be exercised through a realistic actor journey.
• As the primary technique for acceptance testing — verifying the system delivers the intended business value.

Key signal: If the requirement describes what an actor does step-by-step and what the system does in response, Use Case Testing is the right technique.

When NOT to Use

• No use case specification or equivalent exists — use requirements cannot be mapped to actor-goal-flow structure → clarify requirements first.
• The requirement describes only input field constraints with no multi-step interaction → use Domain Testing instead.
• The requirement describes combinations of simultaneous conditions with no sequence → use Decision Table Testing instead.
• The requirement describes system state transitions over time → use State Transition Testing instead.
• Do not use Use Case Testing as a complete test strategy alone — combine with Domain Testing for input data selection within steps, and Error Guessing for additional negative paths.

Inputs Required

Before applying this skill, you must have:

1. Use Case Specification (or equivalent) containing:
   • Use Case ID and Name
   • Actor(s)
   • Preconditions
   • Main Flow (step-by-step)
   • Alternate Flows (each referencing the Main Flow step where deviation occurs)
   • Postconditions
   • Business Rules / Constraints
2. Business Rules (BR) referenced within the use case
3. System context: what layer is being tested (UI, API, or both); what backend state changes are expected
4. (Optional but valuable) Historical defect data for the feature; risk information for flow prioritization

Core Principles

1. Actor-goal orientation: Every use case has exactly one actor initiating it and one goal being pursued. Test cases must be designed from the actor's perspective — verifying the system delivers (or correctly refuses to deliver) the goal.
2. Flow completeness: The main flow and every identified alternate flow must have at least one test scenario covering it. No alternate flow may be silently omitted.
3. Scenario = complete path: Every scenario traces a complete path from the use case's starting point to an endpoint. There are no partial paths — a scenario either reaches a success endpoint or a defined failure/rejection endpoint.
4. Preconditions are mandatory: Every test case must specify exact preconditions — the system state required before the first actor action. Without preconditions, test cases are non-deterministic.
5. Postconditions are verified assertions: Postconditions are not narrative descriptions — they are test assertions that must be explicitly verified, including backend state (database records, audit logs, email delivery) not just UI responses.
6. Flow structure before data: Identify all scenarios (paths) first, then apply data selection techniques. Do not let data concerns drive flow identification.
7. Alternate flows require explicit triggering data: Each alternate flow must be exercised with specific test data or preconditions that reliably force the system down that path — not hoped to be reached by chance.

Design Process

Follow these steps sequentially. Do not skip any steps.

Step 1 — Parse and Validate the Use Case Specification

Read the use case specification thoroughly. For each section, perform validation:

• Actor(s): Is every actor identified? Could the same use case be initiated by different actor types with different behavior?
• Preconditions: Are they specific and testable? Can each be set up reliably before test execution? If a precondition is vague ("system is operational"), clarify what observable condition confirms it.
• Main Flow: Is each step clearly defined as actor action or system response? Are there any implicit steps (actions the spec assumes but does not state)?
• Alternate Flows: Does each alternate flow reference the specific Main Flow step where it branches? Does it define an endpoint (does it rejoin Main Flow, or terminate)? Are any alternate flows missing — conditions the system must handle but the spec does not document?
• Business Rules / Constraints: Are they complete? Do they define behavior for boundary conditions?
• Postconditions: Do they include backend state verification requirements (database changes, audit logs, notifications)?

Document all gaps and ambiguities found. Raise them with the product owner or BA before proceeding to test design.

→ See resources/spec-and-flow-guide.md — Part 1 for validation checklist and common spec gaps.

Step 2 — Analyze and Enumerate All Flows

Produce a complete Flow Inventory:

1. Main Flow: Number each step explicitly (Step 1, Step 2, Step 3...). Identify the single success endpoint.
2. Alternate Flows: For each alternate flow:
   • Assign an ID (e.g., AF-1, AF-2, AF-3)
   • Identify the Main Flow step it branches from (e.g., "Branches from Step 2")
   • Classify as Optional Flow (valid but non-default path) or Exception Flow (error, rule violation, system failure)
   • Identify the endpoint: Rejoins Main Flow at step N / Terminates use case / Loops back
3. Discover hidden alternate flows: Look for:
   • Every step in the Main Flow where the system performs a conditional action
   • Every Business Rule that implies a rejection case
   • Every postcondition that implies multiple possible states
   • System/network failure scenarios at each step
   • Concurrent access scenarios if applicable

→ See resources/spec-and-flow-guide.md — Part 2 for flow enumeration patterns and hidden flow discovery.

Step 3 — Build the Scenario Matrix

Construct the Scenario Matrix — a systematic enumeration of all meaningful path combinations:

Fundamental rule: Every scenario must:

• Begin with the Main Flow
• Incorporate one or more alternate flows at the points where they branch
• Terminate at a defined endpoint (success or defined failure)

Scenario construction procedure:

1. S1 always = Main Flow only (the happy path)
2. For each alternate flow AFn, create a scenario = Main Flow + AFn
3. For combinations where alternate flows interact (one alternate flow enabling or blocking another), enumerate the relevant combinations
4. Apply risk-based selection to prioritize: not all combinations need to be tested if the risk is low

Combinatorial explosion mitigation: When the use case has many alternate flows, apply:

• Risk-based path selection: Prioritize flows by probability of defect × business impact. High-risk flows get individual scenarios; low-risk flows may be bundled.
• Pairwise coverage: Ensure every pair of alternate flows is covered in at least one scenario — mathematically reduces the scenario count while maintaining high defect detection.

→ See resources/scenario-matrix-guide.md for construction procedure and combinatorial reduction strategies.

Step 4 — Design Test Cases from Scenarios

Translate each scenario into one or more executable test cases:

Flow → Test Case mapping:

• One scenario = one or more test cases (multiple test cases when the same path must be exercised with different test data to cover different input partitions)
• Scenarios covering the same path with the same data must not be duplicated

For each test case, specify:

• Preconditions: Exact system state required. Include: data setup (which records must exist in DB), system state (feature flags, configuration), actor state (logged in as which role).
• Steps: Sequential actor actions and expected system responses per step — not just final result.
• Test data: Specific input values for each data-entry step. Derived using Domain Testing (EP/BVA) to select the most revealing values for the path being exercised.
• Expected results per step: Observable system response after each actor action — not just the final state.
• Postconditions: All backend state assertions to verify after the final step: database record changes, audit log entries, email/notification delivery, state of related entities.
• Alternate flow trigger: For non-happy-path scenarios, document exactly what input or condition forces the system into the alternate flow.

→ Use resources/output-template.md for test case format.

Step 5 — Apply Domain Testing for Test Data Selection

For each test case that involves data entry steps:

• Apply Equivalence Partitioning to identify valid and invalid data classes for each input field.
• Apply BVA to select specific values at boundaries of ordered classes.
• Select the data value that best exercises the intended path: for valid paths, use a nominal valid value; for alternate flows triggered by invalid data, use the specific invalid class representative or boundary value.

This step refines test data within scenarios already identified — it does not add new scenarios. If applying EP/BVA reveals a data class that would exercise a different alternate flow not yet in the scenario matrix, add that flow to the matrix first (Step 3), then design its test case here.

Step 6 — Verify Postconditions Coverage

Review every test case for postcondition completeness:

For each test case, confirm:

• UI/API response assertion is specified
• Database state assertion is specified (if the use case modifies data)
• Audit/logging assertion is specified (if the use case spec lists audit events as a postcondition)
• Related entity state assertion is specified (if the use case affects more than one entity)
• Notification/email assertion is specified (if applicable)

Junior tester trap: Only verifying the UI response and ignoring backend state. Use Case Testing requires verifying all postconditions stated in the spec, not just what is visible in the UI.

Step 7 — Review Against Quality Checklists

Before finalizing, verify the test suite against the Test Case Quality Checklist in resources/quality-checklist.md.

Design Rules

Rule	Description
Main Flow always first	S1 must be the Main Flow only; no alternate flows are injected into S1
Every alternate flow covered	Every identified alternate flow must appear in at least one scenario
Scenario = complete path	No partial paths — every scenario has a start and an end point
Precondition is mandatory	Every test case must specify the exact state the system must be in before execution
Postconditions are assertions	Every postcondition in the use case spec must have an explicit test assertion
Alternate flow needs a trigger	Every non-happy-path test case must specify what input or condition forces the alternate flow
Flow structure before data	Complete the Scenario Matrix before selecting test data
No silent omission of flows	Low-risk flows may be deprioritized but must be documented as acknowledged

Anti-Patterns

→ Full detail: resources/anti-patterns.md

Critical anti-patterns:

• Testing only the Main Flow (happy path only) — the most common failure; alternate flows are where most defects live
• Designing test cases without a Scenario Matrix — ad hoc scenario selection misses combinations and produces no coverage evidence
• Missing preconditions — test cases that do not specify system state before execution are non-deterministic and non-reproducible
• Verifying only UI response, ignoring postconditions — backend state changes (DB, audit log, emails) are unchecked; integration defects are invisible
• Confusing alternate flow trigger with expected result — the trigger is what forces the path; the expected result is what the system should do in response
• Treating every alternate flow combination as a required scenario — combinatorial explosion without risk-based selection; thousands of scenarios for no proportional quality gain

Best Practices

→ Full detail: resources/best-practices.md

Key best practices:

• Validate the use case spec before designing tests — gaps in the spec become gaps in the test suite.
• Discover hidden alternate flows by asking "what if?" at every Main Flow step.
• Apply risk-based prioritization to the Scenario Matrix — not all alternate flow combinations need testing.
• Always verify all postconditions — use DB queries, log checks, and notification verification in test assertions.
• Use Domain Testing (EP/BVA) to select test data for each scenario's input steps — do not choose data arbitrarily.
• Maintain a Requirements Traceability Matrix (RTM) linking: BR → Use Case → Scenario → Test Case → Defect.

Process Quality Checklist

Use this to verify the design methodology was applied correctly.

• Use case specification was validated before test design (all fields present, no vague preconditions, all alternate flows have defined endpoints).
• All gaps and ambiguities in the spec were raised and resolved or documented before proceeding.
• Complete Flow Inventory produced: main flow steps numbered, all alternate flows identified and classified (optional vs. exception).
• Hidden alternate flows were actively searched for at each main flow step.
• Scenario Matrix constructed before writing any test case.
• S1 = Main Flow only (no alternate flows injected).
• Every alternate flow appears in at least one scenario.
• Risk-based prioritization applied to scenario selection — low-risk combinations documented as acknowledged if not tested.
• Alternate flow trigger specified for every non-happy-path test case.
• Domain Testing (EP/BVA) applied to select test data for each data-entry step.
• All postconditions from the use case spec have explicit test assertions (not just UI assertions).

→ For the full Process Quality Checklist should be verified, see resources/quality-checklist.md.

Common Rationalizations to Reject

• "The happy path works — the alternate flows are obvious edge cases" → Alternate flows are where most production defects are found; "obvious" is not a testing criterion
• "We don't have time to test all the scenarios" → Apply risk-based selection and document what is being skipped — do not silently omit flows
• "If the UI shows success, the test passes" → Postconditions require backend verification; UI success does not guarantee database consistency, audit trail, or notification delivery
• "The precondition is 'the system is running'" → Preconditions must be specific and verifiable; set up exact data state before each test
• "I'll figure out the test data when I execute" → Test data must be designed before execution; ad hoc data selection produces inconsistent results and misses the data-driven alternate flows

Red Flags

Stop and re-evaluate if you observe:

• The Scenario Matrix has only one scenario (S1 = Main Flow) — alternate flows were not analyzed.
• A test case has no precondition or has "system is operational" as the precondition — not executable.
• Expected result is only "system shows success message" with no backend assertions — postconditions not verified.
• An alternate flow in the use case spec has zero corresponding scenarios — coverage gap.
• All test cases use the same test data — Domain Testing was not applied; specific paths may not be reliably triggered.

Output

The design process produces:

1. Flow Inventory — numbered main flow steps; all alternate flows with classification, branching point, and endpoint
2. Scenario Matrix — all scenarios with path composition and priority
3. Test Case Suite — using the template in resources/output-template.md
4. (Recommended) Requirements Traceability Matrix (RTM) — mapping BR → Use Case → Scenario → Test Case

Examples

→ examples/online-purchase.md — E-commerce online purchase use case: complete UC spec, flow inventory, scenario matrix with risk-based selection, full test case suite with preconditions, data selection rationale, and postcondition assertions