Acceptance criteria follow a single format: "Given [context], when [action], then [observable outcome]." This template provides 25 real acceptance criteria patterns across five feature categories. Each pattern is written so a QA engineer can test it without asking the PM for clarification, the only standard that matters for acceptance criteria.
The acceptance criteria format
Given [the specific context or precondition],
When [the specific action or event],
Then [the specific, observable outcome].
The word "observable" is the critical constraint. The outcome must be something a QA engineer can verify without asking anyone. "The user is happy" is not observable. "The user sees a success toast notification with the text 'PRD saved' within 2 seconds" is observable.
25 acceptance criteria patterns
Authentication (5 patterns)
1. Given a user enters a valid email and password, when they click Login, then they are redirected to their dashboard within 3 seconds and their name appears in the top navigation.
2. Given a user enters an invalid password, when they click Login, then they see the error message "Incorrect email or password" and the password field is cleared. The email field retains its value.
3. Given a user enters an invalid password 5 consecutive times, when they attempt the 5th login, then their account is locked for 15 minutes and they receive an email notification of the lockout.
4. Given a logged-in user clicks Log Out, when the logout action completes, then their session token is invalidated server-side and they are redirected to the login page. The back button does not restore the authenticated session.
5. Given a user's session token expires, when they attempt any authenticated action, then they are redirected to the login page with the message "Your session has expired. Please log in again." Their current URL is preserved so they are returned to it after login.
Forms and data entry (5 patterns)
6. Given a required field is left empty, when a user submits the form, then the form does not submit, the empty field is highlighted with a red border, and an inline error message "This field is required" appears below it.
7. Given a user enters an email address without an @ symbol, when they move focus to the next field, then an inline error message "Please enter a valid email address" appears below the email field immediately.
8. Given a text input has a 280-character limit, when a user types and reaches 260 characters, then a character counter "20 characters remaining" appears below the field. At 0 characters, the counter shows "0 characters remaining" and further input is prevented.