UAT Acceptance Criteria: Examples and Templates

What are UAT acceptance criteria?

Acceptance criteria are the conditions a feature must meet to be accepted by the business. In User Acceptance Testing, they are the yardstick a UAT tester measures the software against, and the basis for the final UAT approval. Each requirement or user story should have its own criteria, written before development so everyone agrees on what "done" means.

What makes good acceptance criteria?

• Specific: one clear behavior, not a paragraph of intentions.
• Testable: a person (or a test) can objectively mark it pass or fail.
• User-focused: written in terms of outcomes, not implementation.
• Unambiguous: two testers would reach the same verdict.
• Complete enough: covers the happy path plus key edge and negative cases.

Compare a weak criterion, "Login should work", with a strong one: "A registered user who enters a valid email and correct password is taken to their dashboard; an incorrect password shows an error and does not log them in." Only the second can actually be tested.

Two common formats

1. Given / When / Then (scenario-based)

Best for workflows and behavior. Borrowed from Gherkin/BDD:

Scenario: Successful checkout
  Given a shopper with one item in their cart
  When they enter valid payment details and place the order
  Then the order is confirmed
  And an order confirmation email is sent
  And the item stock count is reduced by one

2. Rule-based checklist

Best for constraints and validation rules:

The password reset request must:
  - accept only a registered email address
  - send a reset link that expires after 60 minutes
  - reject an expired or reused link with a clear message
  - never reveal whether an email is registered

UAT acceptance criteria examples

Concrete examples across common scenarios:

User login

Given a registered, active user on the login page
When they submit a valid email and correct password
Then they land on their dashboard within 3 seconds

Given a registered user
When they submit a valid email but the wrong password
Then an "incorrect email or password" error is shown
And they remain on the login page

E-commerce checkout

Given a cart subtotal over the free-shipping threshold
When the shopper reaches the shipping step
Then shipping cost shows as $0.00
And the free-shipping message is displayed

Role-based permissions

Given a user with the "Viewer" role
When they open a record
Then the Edit and Delete actions are hidden
And attempting the edit URL directly returns "not authorized"

Form validation

Given the sign-up form
When a required field is left blank and the user submits
Then the form is not submitted
And an inline error identifies each missing field

A reusable acceptance-criteria template

Story: <as a [role], I want [goal], so that [benefit]>

Acceptance criteria:
  Scenario 1 (happy path):
    Given <starting context>
    When  <action>
    Then  <expected, observable outcome>

  Scenario 2 (edge / negative):
    Given <context>
    When  <invalid action>
    Then  <expected handling>

Definition of done:
  - all scenarios pass in UAT
  - no open critical/high defects
  - evidence attached for sign-off

From acceptance criteria to automated tests

Well-written Given/When/Then criteria are, in effect, test scripts, which means they can be automated almost directly. DebuggAI turns real user workflows into end-to-end tests that run on every pull request, so each acceptance criterion has a fresh, repeatable pass/fail result. Instead of re-checking the same flows by hand every UAT cycle, your team reserves manual acceptance testing for the judgment calls that genuinely need a human.