Acceptance Criteria Examples You Can Reuse

Quick answer

Effective criteria are observable, binary, and linked to verification. They define user context, trigger, and expected result without leaking implementation details. If QA has to ask follow-up questions before writing a test, the criterion isn't done yet.

What good criteria look like

• One behavior per criterion.
• Clear preconditions, including identity and permissions.
• Explicit output: status code, state transition, visible UI result.
• Coverage for happy path, validation errors, and authorization failures.
• Traceability to test cases and release scope.

Reusable criteria patterns

# Authentication
- Given valid credentials
  When user submits login
  Then return 200 and issue session token

- Given invalid password
  When user submits login
  Then return 401 with standardized error envelope

# Data update
- Given an authorized editor
  When profile displayName is changed to a valid value
  Then return 200 and persist updated value

# Permission control
- Given a viewer role user
  When user attempts to update profile
  Then return 403 and do not change persisted data

Anti-patterns to remove

• "System responds quickly" without target metric.
• "Handle errors properly" without status and payload definition.
• "Support edge cases" without listing which edge cases.
• Combining unrelated behaviors in a single criterion line.

When language is subjective, implementation and QA read it differently. Replace subjective words with measurable outcomes.

Definition of done for criteria

• Each criterion maps to at least one automated or manual test.
• No criterion depends on undocumented defaults.
• Error behavior uses a consistent system-wide contract.
• Criteria set is reviewed by PM, engineering, and QA before coding.

Domain-specific examples

The authentication and data-update examples above establish the pattern. These domain-specific examples show how the same structure applies to higher-stakes flows where precision matters most — payments, search, and async notifications.

# Payment authorization
- Given a cart with total $49.00 and a valid card on file
  When user submits checkout
  Then payment gateway is charged exactly $49.00
  And order.status transitions to payment_captured
  And confirmation email event is published

- Given a card with insufficient funds
  When user submits checkout
  Then return 402 with payment_failed error code
  And order.status remains pending
  And no charge is recorded

# Search with filters
- Given 200 active products, 50 tagged "sale"
  When user requests GET /products?tag=sale
  Then response contains exactly 50 products
  And each product.tag includes "sale"
  And total_count field equals 50

# Async notification
- Given a user with email_notifications = enabled
  When order status changes to shipped
  Then a notification job is enqueued within 5 seconds
  And job payload includes orderId, userId, and tracking number

Payment criteria must specify the exact amount, the status transition, and the side effects (email event, audit record). Search criteria must specify what is returned and what is excluded. Async criteria must specify timing constraints and payload completeness — not just "notification sent."

Non-functional acceptance criteria

Functional criteria define what the system does. Non-functional criteria define how well it does it. Both categories require observable, binary pass/fail statements — but non-functional criteria are frequently written in ways that cannot be tested, using language like "fast," "reliable," or "scalable."

• "Given 500 concurrent users, When each submits a search query, Then p95 response time is under 400ms."
• "Given a 30-day window, When uptime is measured, Then availability meets or exceeds 99.5%."
• "Given an error rate spike above 1%, When sustained for 5 minutes, Then PagerDuty alert fires within 2 minutes."
• "Given a user deletion request, When processed, Then all PII fields are zeroed within 24 hours and confirmed in audit log."

These examples cover performance, availability, error budgets, and data retention. Each follows the same Given/When/Then structure as functional criteria, with the key difference that the "Then" clause references a measurable threshold rather than a discrete state change.

Non-functional criteria belong in the same spec document as behavioral criteria — not in a separate "NFR document" that is reviewed once and forgotten. Separating them causes implementation teams to treat them as optional, which means they are discovered as failures in production.

How criteria evolve through the sprint

Criteria written before implementation begins are hypotheses. They should not change arbitrarily during the sprint, but they do need structured revision when the implementation reveals constraints that were not visible at spec time. The right process is not to quietly weaken the criterion — it is to document the change and get sign-off from the same stakeholders who approved the original.

• If a criterion is narrowed (fewer cases covered), QA must be informed and the test plan updated.
• If a criterion is expanded (more behavior added), the change requires a new spec review gate, not just a comment in the PR.
• If a criterion is deferred, it becomes a tracked item in the next sprint — not a silent omission.

Criteria that survive implementation unchanged are a sign of good upfront spec work. Criteria that are routinely revised during coding are a sign that the spec review was insufficient or rushed.

Use these templates

Related articles

• Given-When-Then Template
• Write Testable Specifications
• Performance Acceptance Criteria
• Writing Edge Cases for QA