Turning User Stories into Test Scenarios

From user story to testable statements

A user story is a short description of who needs something, what they want to do, and why it matters. To turn it into test scenarios, you first translate the story into testable statements: specific behaviors you can observe and verify.

Identify user, goal, and value

Use the story format to extract three anchors:

• User: the role or persona (who performs the action).
• Goal: the capability or task (what they are trying to do).
• Value: the benefit or outcome (why it matters).

Then rewrite the story as one or more testable statements by making the goal measurable and the outcome observable.

• Story: “As a shopper, I want to save items to a wishlist so I can buy them later.”
• Testable statement: “A shopper can add an item to a wishlist, and the item remains available in the wishlist for later purchase.”

Extract behaviors from acceptance criteria

Acceptance criteria (AC) are your primary source of behaviors. Each criterion usually contains one or more conditions and expected outcomes. Your job is to split them into atomic behaviors that can be tested independently.

How to spot multiple behaviors inside one criterion

• Look for conjunctions like “and”, “or”, “unless”, “except”. These often indicate multiple scenarios.
• Look for ranges or lists (e.g., “Visa, Mastercard, Amex”). Each option may need its own scenario.
• Look for conditional phrases (e.g., “if the user is not logged in…”). These usually create at least two scenarios (condition true vs false).

Example AC: “If the password is incorrect, show an error and do not log the user in.” This contains two expected outcomes (error shown, login blocked). They belong in the same scenario because they are part of one behavior: handling incorrect credentials.

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

A step-by-step method to rewrite acceptance criteria into test scenarios

Use this repeatable method for each acceptance criterion. The goal is consistent language and scenarios that are clear, atomic, and measurable.

Step 1: Copy one acceptance criterion and underline the condition and the expected result

Ask: “What must be true before the action?” (condition) and “What must happen after?” (expected result).

Step 2: Normalize terms and define the subject

Replace vague words with consistent product terms. Decide the subject explicitly (the user role from the story). If the AC says “user”, rewrite as “registered customer”, “admin”, etc., matching the story.

Step 3: Choose a scenario style and stick to it

Pick one of these and use it consistently within your project:

• Given/When/Then: good for clarity and structure.
• Plain steps: numbered steps with expected results.

Both are acceptable as long as each scenario is unambiguous and testable.

Step 4: Split the criterion into atomic behaviors

If the criterion contains multiple conditions or outcomes that can vary independently, split into multiple scenarios. Keep each scenario focused on one behavior and one primary outcome.

Step 5: Make it measurable

Add observable checks. Replace “works”, “properly”, “quickly”, “securely” with verifiable outcomes such as:

• Specific message text or message type (e.g., “Error banner is shown”).
• State change (e.g., “Order status becomes ‘Paid’”).
• Navigation result (e.g., “User is redirected to the dashboard”).
• Data persistence (e.g., “Item appears in wishlist after refresh”).

Step 6: Write the scenario using consistent language

Template (Given/When/Then):

Scenario: [short behavior-focused name] Given [preconditions] When [user action] Then [expected outcome]

Template (plain steps):

Scenario: [short behavior-focused name] 1. [Precondition] 2. [Action] 3. [Expected result]

Step 7: Quick quality check (clear, atomic, measurable)

• Clear: A new tester can execute it without guessing.
• Atomic: It tests one behavior; failures point to one cause.
• Measurable: Expected results are observable and specific.

Worked example: rewriting acceptance criteria into scenarios

Mini user story: “As a registered user, I want to reset my password so I can regain access to my account.”

Acceptance criteria:

• AC1: “If the email is registered, send a password reset link.”
• AC2: “If the email is not registered, show a generic message.”
• AC3: “The reset link expires after 30 minutes.”

Scenarios (Given/When/Then):

Scenario: Send reset link for registered email Given a registered user email exists in the system When the user requests a password reset with that email Then a password reset email is sent to that address Scenario: Show generic message for unregistered email Given an email address that is not registered When the user requests a password reset with that email Then a generic confirmation message is shown and no account existence is revealed Scenario: Expired reset link is rejected Given a password reset link was generated more than 30 minutes ago When the user opens the reset link Then the system rejects the link and prompts the user to request a new one

Notice how each scenario is focused: one condition, one main behavior, and observable outcomes.

Exercise: convert two user stories into a scenario list

Goal: For each user story below, produce a list of scenarios. Each scenario must be clear, atomic, and measurable. Use either Given/When/Then or plain steps, but be consistent.

User story 1: Add item to cart

Story: “As a shopper, I want to add a product to my cart so I can purchase it later.”

Acceptance criteria:

• AC1: “From a product page, the shopper can add the product to the cart.”
• AC2: “If the product is out of stock, the shopper cannot add it to the cart and sees an out-of-stock message.”
• AC3: “After adding a product, the cart icon shows the updated item count.”
• AC4: “The cart retains items after a page refresh.”

Your task: Rewrite each AC into one or more scenarios. Split AC2 if needed (blocking add + message) only if you can make them independently variable; otherwise keep them together as one behavior.

Example scenario list (one possible answer):

Scenario: Add in-stock product to cart from product page Given a product is in stock and the shopper is on the product page When the shopper clicks “Add to cart” Then the product appears in the cart Scenario: Prevent adding out-of-stock product Given a product is out of stock and the shopper is on the product page When the shopper clicks “Add to cart” Then the product is not added to the cart and an out-of-stock message is displayed Scenario: Cart icon updates item count after add Given the cart is empty and a product is in stock When the shopper adds the product to the cart Then the cart icon item count increases by 1 Scenario: Cart retains items after refresh Given the shopper has at least one item in the cart When the shopper refreshes the page Then the cart still contains the same items

User story 2: Download invoice PDF

Story: “As a customer, I want to download a PDF invoice for my order so I can keep it for my records.”

Acceptance criteria:

• AC1: “On the order details page, the customer can download an invoice PDF.”
• AC2: “If the order is cancelled, the invoice download is not available.”
• AC3: “The downloaded file is a PDF and includes the order number and total amount.”
• AC4: “If the customer is not logged in, they are redirected to the login page when trying to access order details.”

Your task: Convert these into scenarios. Pay attention to AC3: it contains multiple checks (file type + content). Decide whether to keep them in one scenario (single behavior: correct invoice generation) or split into two scenarios if your team prefers smaller checks.

Example scenario list (one possible answer):

Scenario: Download invoice PDF from order details Given the customer is logged in and is viewing an order that is not cancelled When the customer clicks “Download invoice” Then an invoice file is downloaded Scenario: Invoice download not available for cancelled order Given the customer is logged in and is viewing a cancelled order When the customer views the order details page Then the “Download invoice” option is not shown or is disabled Scenario: Downloaded invoice is a PDF with required fields Given the customer downloads an invoice for a non-cancelled order When the download completes Then the file type is PDF and the document contains the order number and total amount Scenario: Redirect unauthenticated user to login for order details Given the customer is not logged in When the customer attempts to open the order details page URL Then the customer is redirected to the login page

Self-check questions:

• Can someone execute each scenario without asking you what you meant?
• Does each scenario test one behavior with a specific expected result?
• Are the outcomes observable (UI change, file downloaded, content present, option disabled)?