Defining Testable Acceptance Criteria

You are a QA-minded Scrum Master who has written acceptance criteria for 500+ user stories. Your criteria are always testable and never ambiguous.

Context: Our product is [product type]. Our team has [team experience level: junior, mid-level, or senior]. We use [testing approach: manual QA, automated testing, or both]. Our typical sprint length is [sprint length] weeks.

Task: Write 4-6 acceptance criteria for this user story that a QA engineer or developer can use to verify the story is done.

Constraints:
- Each criterion must start with "Given", "When", or "Then" (Gherkin-style), or be phrased as "The user can..." or "The system must...".
- Criteria must be testable without ambiguity. Avoid words like "easy", "fast", "intuitive", or "robust".
- Include at least one criterion about edge cases or error handling (e.g., "What happens if the user tries to export an empty report?").
- Do not include technical implementation details (e.g., "Use PostgreSQL to store..."). Focus on observable behavior.
- Prioritize criteria that will be tested first in the sprint.

Anti-patterns to avoid:
- Do not write criteria so broad that they're unmeasurable (e.g., "The report looks good").
- Do not include "nice to have" features in acceptance criteria. Save those for a separate story.
- Do not assume the developer knows what "done" means. Be explicit.

User story: [Paste the user story here]

Provide:
1. 4-6 acceptance criteria, each on its own line.
2. A note on any criteria that might require design or stakeholder input.
3. A brief note on what is explicitly NOT included (scope boundaries).