How to Write Test Cases From Acceptance Criteria: Positive, Negative and Boundary Tests

Why acceptance criteria are the best source for test cases

Acceptance criteria describe what must be true for a story to be accepted. A test case describes how someone will check that it is true. When you write test cases from acceptance criteria, you are not inventing new requirements. You are turning agreed conditions into steps that a tester or business user can follow and judge as pass or fail.

This matters most in UAT. Business users have limited time, and they need tests written in their language, using situations they recognise. If the criteria were written well (see How to Write User Stories), most of the test design is already done. Your job is to make each criterion concrete, then add the tests the criteria imply but do not spell out: negative tests and boundary tests.

Test design is also one of the clearest ways to show analytical thinking. It sits alongside requirements, modelling and communication in the core business analyst skills that delivery teams expect from a BA.

Anatomy of a test case

Templates differ between teams, but almost every useful test case has the same fields. If a field is missing, someone will have to guess, and guessing is how tests pass when they should fail.

• Test case ID: a unique, stable reference such as TC-12-03, so links never break.
• Title: one behaviour in plain words, for example 'Error shown when email is missing'.
• Linked requirement: the story ID and the criterion number it proves.
• Preconditions: what must already be true before you start, such as the user role or existing records.
• Test data: the exact values to enter or use.
• Steps: numbered actions, one action per step.
• Expected result: the observable outcome, such as a message, a value or a screen.
• Actual result and status: filled in during execution as pass, fail or blocked.
• Defect reference: a link to the bug report if the test failed.

Keep each test case focused on one behaviour. If a test checks five things and fails, nobody knows which one broke. A simple rule: if the title needs the word 'and', think about splitting it.

Teams store test cases in spreadsheets, test management tools or as linked items in a tracker. The fields matter more than the tool. If your team works in a Jira-style tool, Jira for Business Analysts explains how tickets and links fit together.

How to turn acceptance criteria into test cases, step by step

Criteria written in Given/When/Then format make the mapping almost mechanical. The Given becomes your preconditions and test data. The When becomes your steps. The Then becomes your expected result. If you need a refresher on the format, see the Gherkin glossary entry.

1. Check each criterion is testable. Look for vague words such as 'fast', 'easy' or 'correct'. Ask the product owner to replace them with something observable before you write tests.
2. Write one positive test per scenario. Use realistic data that clearly meets the Given. This proves the main path works.
3. Turn the Given into preconditions and data. Name the exact user, account or record, so two testers get the same result.
4. Turn the When into numbered steps. One action per step, written from the user's point of view.
5. Turn the Then into expected results. Be specific: which screen, which message text, which value.
6. Add negative tests. For each criterion, ask what must not happen, and what happens when input is wrong, missing or out of order.
7. Add boundary tests. For every limit in the criteria, test just below, exactly at and just above it.
8. Link every test to its criterion and review coverage. Every criterion needs at least one test, and every test needs a criterion.

Negative and boundary tests: where defects usually hide

Positive tests prove the system does what it should when everything goes right. Real users do not always go right. They leave fields empty, press back, use the wrong account and type values nobody expected. Negative and boundary tests check those situations.

Negative tests

A negative test checks that the system handles a bad or unexpected situation safely. It often proves that something does not happen. Good sources of negative tests are:

• Missing or blank input in a required field.
• Input in the wrong format, such as letters in a phone number.
• A user without permission trying the action.
• Steps done out of order, or repeated twice.
• The opposite of a criterion: if a fee is added when a total drops, check it is not added when the total stays high.

Boundary tests

Wherever a rule has a limit, developers have to choose between 'greater than' and 'greater than or equal to'. That choice is a common source of defects. So for each limit, test three values: just below, exactly at and just above. If a password must be between eight and twenty characters, test seven, eight, twenty and twenty-one characters.

Equivalence groups keep the test count sensible

You cannot test every possible value. Instead, group values that should behave the same way and pick one from each group, plus the boundaries between groups. For a minimum order rule, that means one value clearly below, one clearly above, and the three boundary values.

Worked example: free delivery at Lumen Pantry

Lumen Pantry is a fictional online grocery store. Story US-31 says: as a customer, I want free delivery when my basket is large enough, so that I am encouraged to buy more in one order. The product owner agreed three acceptance criteria.

Feature: Free delivery at checkout (US-31)

  Scenario: AC1 Basket qualifies for free delivery
    Given my basket total is ₹500 or more
    When I open the checkout page
    Then the delivery fee is ₹0
    And I see the label 'Free delivery'

  Scenario: AC2 Basket is below the threshold
    Given my basket total is below ₹500
    When I open the checkout page
    Then the delivery fee is ₹40
    And I see how much more I need to add for free delivery

  Scenario: AC3 Basket drops below the threshold
    Given my basket qualified for free delivery
    When I remove items and the total falls below ₹500
    Then the ₹40 delivery fee is added before payment

The BA started with one positive test per criterion, then added boundary tests around ₹500 and one negative test for AC3. The final set has seven test cases, numbered in the order they appear below:

• TC-31-01 (AC1, positive): basket ₹650. Expected: fee ₹0 and the 'Free delivery' label.
• TC-31-02 (AC2, boundary just below): basket ₹499. Expected: fee ₹40 and the message 'Add ₹1 more for free delivery'.
• TC-31-03 (AC1, boundary at the limit): basket ₹500. Expected: fee ₹0 and the 'Free delivery' label.
• TC-31-04 (AC1, boundary just above): basket ₹501. Expected: fee ₹0 and the 'Free delivery' label.
• TC-31-05 (AC2, positive): basket ₹300. Expected: fee ₹40 and the message 'Add ₹200 more for free delivery'.
• TC-31-06 (AC3, positive): basket ₹520, remove a ₹50 item. Expected: total ₹470, fee ₹40, amount to pay ₹510.
• TC-31-07 (AC3, negative): basket ₹600, remove a ₹50 item. Expected: total ₹550 and the fee stays ₹0.

Coverage check: AC1 has three tests (TC-31-01, TC-31-03, TC-31-04). AC2 has two (TC-31-02, TC-31-05). AC3 has two (TC-31-06, TC-31-07). Three plus two plus two makes seven, and every test points to exactly one criterion.

Boundary tests as a scenario outline

The three boundary tests share the same steps, so the BA wrote them as one scenario outline. The Examples table includes a test ID column, and its rows run in the same order as the IDs: ₹499 is TC-31-02, ₹500 is TC-31-03 and ₹501 is TC-31-04. No reordering is needed.

Scenario Outline: Delivery fee at the free delivery threshold
  Given my basket total is <total>
  When I open the checkout page
  Then the delivery fee shown is <fee>
  And the message shown is '<message>'

  Examples:
    | test_id  | total | fee | message                       |
    | TC-31-02 | ₹499  | ₹40 | Add ₹1 more for free delivery |
    | TC-31-03 | ₹500  | ₹0  | Free delivery                 |
    | TC-31-04 | ₹501  | ₹0  | Free delivery                 |

The coupon question became a new criterion, AC4, after the sponsor decided that delivery is judged on the total after discounts. That is a normal outcome: test design often exposes gaps in requirements, and finding them before UAT is much cheaper than finding them after go-live.

Linking test cases to requirements

A test case without a link to a requirement is hard to justify, and a requirement without a test is a risk nobody is checking. Traceability solves both problems. The usual tool is a requirements traceability matrix (RTM): a table where each row is a requirement or criterion, and the columns show its linked tests, their status and any open defects.

• Forward coverage: every criterion links to at least one test. A criterion with no test is untested scope.
• Backward coverage: every test links to a criterion. A test with no criterion either reveals a missing requirement or is testing something nobody asked for.
• Status roll-up: when all tests for a criterion pass, the criterion is ready for sign-off. If one fails, the defect is linked so everyone can see why.

Use stable IDs. If you renumber tests halfway through, every link in the matrix breaks. Add new tests at the end of the sequence instead. To practise building a matrix and running a small UAT cycle, try the Traceability Matrix and UAT exercise.

Common mistakes when writing test cases from acceptance criteria

Vague expected results

'System works correctly' cannot fail, so it proves nothing. Write the exact message, value or screen the tester should see.

Only testing the happy path

One positive test per criterion feels complete, but most defects live at limits and in bad input. Add boundary and negative tests for every rule that has a limit or a condition.

Guessing when the criteria are silent

If you find a case the criteria do not cover, do not invent the expected result. Log it as a question with an owner. Guessing hides a requirements gap that will reappear later as an argument.

Long tests that check many things

A twenty-step test that covers login, search, basket and payment is hard to run and harder to debug. Split it into focused tests, each linked to its own criterion.

Writing in developer language for business testers

UAT testers are business users. Use screen names and business terms they know, not database fields or internal codes.

Checklist before you hand test cases to UAT testers

Walk through the set with the QA tester and one business user before UAT. Ten minutes of review often finds a missing boundary or a confusing step, and it gives testers confidence that the tests reflect how they really work.

Frequently asked questions