Use Case Testing

Yuri Kan

Use Case Testing

Learn use case testing — derive comprehensive test cases from use case documents by covering main success scenarios and all alternative flows.

Quick Answer

Use Case Testing covers essential QA skills — after this lesson you can understand use case structure: actors, preconditions, main flow, and alternative flows.

— Yuri Kan, Senior QA Lead

What You Will Learn

Understand use case structure: actors, preconditions, main flow, and alternative flows
Derive test cases from use case main and alternative scenarios
Identify gaps in use cases that indicate missing test coverage

Table of Contents

What Is Use Case Testing?

Use case testing derives test cases from use case documents — structured descriptions of how actors interact with a system to achieve goals. Each use case contains a main success scenario and alternative flows, providing natural test scenarios.

Use Case Anatomy

A well-written use case includes:

Element	Description	Example
Name	Brief descriptive title	“Place Order”
Actor	Who initiates the interaction	Customer, Admin
Precondition	What must be true before starting	User is logged in, cart is not empty
Main flow	Step-by-step happy path	1. Select shipping… 2. Enter payment…
Alternative flows	Deviations from the main flow	2a. Payment declined → show error
Postcondition	What is true after success	Order is created, email sent

Example: Place Order Use Case

Actor: Registered Customer Precondition: Customer is logged in, cart has 1+ items

Main Flow:

System displays cart summary with items and total
Customer selects shipping method
System calculates shipping cost and updates total
Customer enters payment information
System validates payment details
Customer confirms order
System processes payment
System creates order and sends confirmation email
System displays order confirmation page

Alternative Flows:

2a. Only one shipping method available → system auto-selects it
4a. Customer selects saved payment method → skip to step 6
5a. Payment validation fails → system shows error, return to step 4
7a. Payment processing fails → system shows error, suggest retry or different method
7b. Payment timeout → system shows timeout message, order not created
8a. Email service unavailable → order created, email queued for later

Deriving Test Cases

Rule: Create at least one test case per flow (main + each alternative).

TC	Flow	Description	Key Steps
TC1	Main	Happy path	All steps 1-9 succeed
TC2	2a	Auto-select shipping	Only one method → auto-selected
TC3	4a	Saved payment	Select saved card → skip to confirm
TC4	5a	Invalid payment	Wrong card number → error → retry
TC5	7a	Payment fails	Card declined → suggest retry
TC6	7b	Payment timeout	Timeout → order not created
TC7	8a	Email fails	Order created, email queued

7 test cases from 1 use case — each covering a distinct scenario.

Finding Missing Coverage

Use cases often reveal testing gaps. Ask:

What if the cart becomes empty between steps 1 and 6? (Concurrent modification)
What if the price changes during checkout? (Race condition)
What about the actor’s permissions? (Authorization)
What happens after the postcondition? (Order lifecycle)

Advanced Use Case Testing

Combining Flows

Real scenarios often combine multiple alternative flows in sequence:

TC	Combined Flows	Scenario
TC8	5a → Main	Payment invalid, retry with correct data → success
TC9	7a → 4a	Payment fails, use saved payment method → success
TC10	5a → 5a → 7a	Two invalid attempts, then valid but card declined

This combinatorial approach catches defects in flow transitions.

Use Case Testing for APIs

Map use cases to API call sequences:

Use Case: Place Order

Step 1: GET /cart → 200 (cart summary)
Step 2: PUT /cart/shipping → 200 (select shipping)
Step 3: GET /cart/total → 200 (recalculated total)
Step 4: POST /orders/payment-intent → 200 (payment info)
Step 5: POST /orders/validate → 200 or 400 (validation)
Step 6: POST /orders/confirm → 201 (order created)

Each alternative flow maps to an error response or different sequence.

Coverage Criteria

Flow coverage (minimum): Every flow executed at least once.

Step coverage: Every step in every flow executed at least once.

Data variation: Same flow with different valid/invalid data (combine with EP/BVA).

Extending Use Cases with Exception Scenarios

Beyond documented alternatives, test:

Category	Scenarios
Timeout	Network timeout at each step
Concurrency	Same user in two sessions
Permission	Actor without required role
Data integrity	Referenced data deleted mid-flow
Session	Session expires during flow

Exercise: Derive Test Cases from a Use Case

Use Case: Reset Password

Actor: Registered User Precondition: User has a registered account with verified email

Main Flow:

User clicks “Forgot Password”
System displays email input form
User enters registered email
System sends reset link to email
User clicks link within 24 hours
System displays new password form
User enters new password (meeting policy: 8+ chars, 1 uppercase, 1 digit)
System validates and saves new password
System confirms password change and sends notification email

Alternative Flows:

3a. Email not registered → system shows generic “If account exists, email sent” (security)
5a. Link expired (>24 hours) → system shows “Link expired, request new one”
5b. Link already used → system shows “Link already used”
7a. Password doesn’t meet policy → system shows specific error
7b. New password same as old → system shows “Choose a different password”

Task: Derive test cases for all flows. Add 2 additional exception scenarios not listed.

Hint

Think about: What if the user requests multiple reset links? What happens if the user’s account is locked/deactivated? What about SQL injection or XSS in the email field?

Solution

Test cases from documented flows:

TC	Flow	Description
TC1	Main	Happy path: valid email → link → new password → success
TC2	3a	Unregistered email → generic message
TC3	5a	Click expired link → error message
TC4	5b	Click already-used link → error message
TC5	7a	Password too short → specific error
TC6	7a	Password no uppercase → specific error
TC7	7a	Password no digit → specific error
TC8	7b	Same as old password → rejection

Additional exception scenarios:

TC	Scenario	Expected
TC9	Multiple reset requests → only latest link works	Previous links invalidated
TC10	Account deactivated/locked → request reset	Generic message (don’t reveal status)
TC11	XSS in email field: `<script>alert(1)</script>@test.com`	Input sanitized, no execution
TC12	Concurrent: request reset, then change password normally, then click link	Link should be invalid

Total: 12 test cases covering documented flows + security + concurrency.

Pro Tips

Every alternative flow is a test case. Don’t skip them — alternative flows are where most defects hide.
Challenge preconditions. What happens if a precondition is NOT met? That’s another test scenario.
Think about postconditions. Verify not just that the action succeeded, but that all side effects occurred (emails sent, database updated, logs created).
Use cases pair well with exploratory testing. The documented flows guide structured testing; then explore beyond the documented paths.
Number your flows consistently. “5a” means “alternative at step 5, variant a” — this makes traceability easy when creating test cases.

Knowledge Check

1. What is a use case in the context of testing?

2. Why should you test alternative flows, not just the main success scenario?

3. What is the minimum number of test cases needed for a use case with 1 main flow and 3 alternative flows?

Frequently Asked Questions

What is use case testing?

Use Case Testing is a key concept in Test Design Techniques. This lesson teaches you to understand use case structure: actors, preconditions, main flow, and alternative flows, providing practical skills you can apply immediately in your testing work.

How do I apply use case testing in real projects?

Start by practicing the core techniques covered in this lesson. Specifically, you should derive test cases from use case main and alternative scenarios. Apply these skills in your current project to see immediate results.

Why is use case testing important for QA engineers?

Use Case Testing is a core skill that employers look for in QA professionals. It directly impacts test coverage, defect detection, and team efficiency. Mastering it strengthens your Test Design Techniques capabilities and makes you more effective at delivering quality software.

Do I need prior experience to learn use case testing?

No prior experience is required. This lesson is designed for beginners and explains use case testing from first principles with step-by-step examples that build your understanding progressively.

How does use case testing help my QA career?

Knowledge of use case testing is frequently listed in QA job descriptions and interview questions. It demonstrates expertise in use case testing, use case scenarios and shows you can contribute to quality assurance at a professional level. Senior roles especially value this competency.

Use Case Testing

What You Will Learn

What Is Use Case Testing? #

Use Case Anatomy #

Example: Place Order Use Case #

Deriving Test Cases #

Finding Missing Coverage #

Advanced Use Case Testing #

Combining Flows #

Use Case Testing for APIs #

Coverage Criteria #

Extending Use Cases with Exception Scenarios #

Exercise: Derive Test Cases from a Use Case #

Pro Tips #

Knowledge Check

Frequently Asked Questions

What Is Use Case Testing?

Use Case Anatomy

Example: Place Order Use Case

Deriving Test Cases

Finding Missing Coverage

Advanced Use Case Testing

Combining Flows

Use Case Testing for APIs

Coverage Criteria

Extending Use Cases with Exception Scenarios

Exercise: Derive Test Cases from a Use Case

Pro Tips