Define testable acceptance criteria from requirements and design. Bridge product requirements with QE test scenarios. Use when: "define acceptance criteria", "how do we know it's done", "what should QE test", "definition of done"
Resources
1Install
npx skillscat add mikeparcewski/wicked-garden/wicked-garden-product-acceptance-criteria Install via the SkillsCat registry.
SKILL.md
Acceptance Criteria Skill
Transform requirements into testable acceptance criteria.
Core Concept
Acceptance criteria are the contract between product and delivery:
- Product: "Here's what success looks like"
- QE: "Here's how we verify it"
- Engineering: "Here's what we must deliver"
Given/When/Then Format
Given [precondition/context]
When [action/event]
Then [expected outcome]Why this format?
- Forces specificity
- Testable by definition
- Clear success criteria
- Language-agnostic
Process
1. Read Requirements
Understand:
- User stories
- Design documents
- Business rules
- Constraints
2. Identify Scenarios
For each requirement, consider:
- Happy path: Normal, expected flow
- Error conditions: Invalid inputs, failures
- Edge cases: Boundaries, empty states
- Non-functional: Performance, security, usability
3. Write Criteria
Format each scenario:
Given [specific context]
When [specific action]
Then [specific, measurable outcome]4. Validate
Check each criterion:
- Specific (not vague)
- Testable (can verify)
- Measurable (clear pass/fail)
- Independent (standalone)
- Complete (covers scenario)
5. Organize by Priority
- P0: Must have (blocker if missing)
- P1: Should have (important)
- P2: Nice to have (enhancement)
Example: Login Feature
### US1: User Authentication
**Happy Path (P0)**:
AC1: Given valid credentials, When user submits login, Then user redirected to dashboard
AC2: Given successful login, When checking session, Then session valid for 30 minutes
**Error Handling (P0)**:
AC3: Given invalid password, When user submits login, Then error message "Invalid credentials"
AC4: Given account locked, When user submits login, Then error message "Account locked"
AC5: Given 3 failed attempts, When user tries again, Then account locked for 15 minutes
**Edge Cases (P1)**:
AC6: Given empty email field, When user submits, Then error "Email required"
AC7: Given malformed email, When user submits, Then error "Invalid email format"
AC8: Given concurrent logins, When second login occurs, Then first session invalidated
**Non-Functional (P1)**:
AC9: Given 1000 concurrent logins, When system under load, Then response time < 2 seconds
AC10: Given login attempt, When credentials checked, Then password encrypted in transitCommon Patterns
Data Creation:
Given user on create form
When user enters valid data and submits
Then new record saved and confirmation shownData Validation:
Given user on form with required fields
When user submits without filling required field
Then error message shown and form not submittedAuthorization:
Given user without admin role
When user attempts admin action
Then access denied message shownAPI Response:
Given valid API request
When endpoint called
Then 200 status and expected JSON schema returnedIntegration with QE
Acceptance criteria feed directly into test scenarios:
# Product defines AC
wicked-garden-product acceptance phases/design/
# Generate test scenarios from AC
wicked-garden-qe planFlow:
- Product: Write acceptance criteria
- QE: Review and generate test scenarios
- Engineering: Implement to meet criteria
- QE: Verify against criteria
Quality Checklist
Good acceptance criteria:
- Use Given/When/Then format
- Specific and unambiguous
- Testable with clear pass/fail
- Cover happy path, errors, edges
- Include non-functional requirements
- Prioritized by criticality
- Reviewed by QE for testability
Output Format
## Acceptance Criteria
### User Story: {Story Title}
**Happy Path**:
- AC1: Given {context}, When {action}, Then {outcome} [P0]
**Error Conditions**:
- AC2: Given {error}, When {action}, Then {handling} [P0]
**Edge Cases**:
- AC3: Given {edge}, When {action}, Then {behavior} [P1]
**Non-Functional**:
- AC4: Given {load}, When {action}, Then {performance} [P1]
**Test Data Requirements**:
- {Data needed for testing}
**QE Handoff Notes**:
- {Special testing considerations}Progressive Disclosure
- SKILL.md (this file): Quick reference
- refs/ac-examples.md: More examples by domain
- refs/ac-anti-patterns.md: Common mistakes to avoid