Evaluating acceptance criteria for testability

What Makes Acceptance Criteria Testable — Precision, Observability, Completeness?

Acceptance criteria (AC) are the formal statements of what a feature must do in order to be considered complete. They sit at the intersection of product requirements and quality verification. When AC are well-written, they become the direct basis for test design. When they're poorly written — which is the majority of the time — they create ambiguity that QA engineers absorb silently, filling gaps with assumptions that may or may not match what development built.

The problem compounds in agile: there's pressure to move fast, stories get written quickly, and AC review is often an afterthought. By the time QA starts testing, the AC have been baked into development decisions that are expensive to change.

Evaluating AC for testability early — before development begins — is one of the highest-leverage quality activities a QA engineer can perform. AI makes this practical at scale.

The Three Pillars of Testable Acceptance Criteria

1. Precision

Testable criteria are specific enough that there is no ambiguity about what "pass" or "fail" looks like. Imprecise criteria leave room for interpretation — and different people will interpret them differently.

Examples of imprecise vs. precise AC:

2. Observability

Testable criteria describe behavior that can be observed — either through the UI, an API response, a database state, a log entry, or a measurable system metric. If a criterion describes an internal implementation detail that has no observable external effect, it cannot be tested in a meaningful way.

Unobservable: "The system uses a caching layer to reduce database load."
Observable: "Identical search queries made within 60 seconds must return a response in under 50ms, indicating cache hit behavior."

For API and backend work, observability means: what can I inspect in the API response, what headers are set, what database records are created or modified, what events are emitted?

3. Completeness

Complete AC cover not just the happy path but also the alternative flows, the negative cases, and the boundary conditions. An AC that only describes what happens when things go right is incomplete.

A login story with only "Users can log in with valid credentials" is missing: what happens with invalid credentials, what happens after N failed attempts, what happens with expired sessions, what happens if the account is deactivated, and what happens if the user doesn't exist.

Completeness also means explicit specification of non-functional requirements where they matter: performance thresholds, security requirements, accessibility standards, and cross-platform consistency expectations.

The SMART Criteria Filter for AC

A useful pre-screening filter for AC quality is SMART:

• Specific: Does it name the exact behavior, not a category of behavior?
• Measurable: Does it have a quantitative or observable pass/fail condition?
• Achievable: Is this technically feasible in this sprint with this team?
• Relevant: Does this criterion map to a real user need or business rule?
• Testable: Can I write a concrete test scenario that validates this criterion directly?

If any SMART component fails, the AC needs revision before development starts.

Learning Tip: The testability conversation is most valuable before the sprint starts, not during or after. Bring a short checklist of testability criteria to your sprint planning review. Even five minutes of "is this testable?" review per story can prevent days of rework when you discover mid-sprint that a core AC is so vague that development and QA have different mental models of what "done" looks like.

How to Use AI to Audit Acceptance Criteria for Ambiguity and Missing Edge Cases?

Manually reviewing AC for testability issues requires a specific mindset shift — you have to read requirements not as a person who wants to understand the feature, but as a person trying to find every possible interpretation and every missing case. This is a skill, and it's inconsistently applied under sprint pressure.

AI applies this audit systematically, every time, without the cognitive shortcuts that experienced QA engineers take because they "know" what the AC means.

The AC Testability Audit Prompt

This is the core prompt for evaluating a set of acceptance criteria:

Prompt:

You are a senior QA engineer reviewing acceptance criteria before sprint development begins. Your job is to identify testability issues so they can be fixed before coding starts.

USER STORY:
[Paste the full user story here]

ACCEPTANCE CRITERIA:
[Paste each AC item, numbered]

For each acceptance criterion, evaluate:
1. PRECISION: Is the criterion specific enough to have an unambiguous pass/fail condition? If not, what is ambiguous?
2. OBSERVABILITY: What can a tester actually inspect to verify this criterion? (UI element, API response, database state, log, metric) If the criterion has no observable output, flag it.
3. COMPLETENESS: Does this criterion cover the negative path, error cases, and boundary conditions relevant to it? List what's explicitly missing.
4. ASSUMPTIONS: What implicit assumptions does this criterion make that are not stated? (e.g., "user is logged in", "account has sufficient balance", "feature flag is enabled")
5. TESTABILITY SCORE: Rate each criterion as: Testable / Needs Revision / Not Testable — with one-sentence rationale

At the end, provide:
- A summary of the top 3 most critical testability issues to fix
- A list of edge cases and negative scenarios that are implied by the story but absent from the AC

This prompt works best when the full user story (not just the AC) is included, because the story provides context for what the AC should be covering.

Detecting Ambiguous Language Patterns

Certain words and phrases in AC are consistently signals of ambiguity. AI is good at flagging these patterns, but it's worth knowing them yourself so you can catch them in real-time during refinement meetings.

High-risk ambiguity phrases:
- "should be fast / efficient / quick" (no measurement)
- "users should see relevant / appropriate results" (no definition of relevance)
- "handle errors gracefully" (no specification of which errors or what "graceful" means)
- "the system should allow" (allows under what conditions? For all users?)
- "should work on mobile" (which devices, OS versions, screen sizes?)
- "validation should prevent invalid data" (what counts as invalid? What error message?)

Prompt:

Review these acceptance criteria for ambiguous language patterns that will create testability problems:

ACCEPTANCE CRITERIA:
[Paste AC here]

Flag every instance of:
1. Unmeasured performance claims ("fast", "efficient", "minimal")
2. Undefined qualifiers ("appropriate", "relevant", "valid", "reasonable")
3. Passive voice that hides the subject ("should be displayed" — by what? to whom?)
4. Missing error specification ("handles errors" without specifying which errors)
5. Platform vagueness ("works on all devices" without specification)
6. Missing state specification ("user can do X" without specifying what state the system must be in)

For each flag, provide: the ambiguous phrase, why it's ambiguous, and a suggested rewrite that makes it testable.

Finding Missing Edge Cases in AC

Even well-written AC can have missing coverage for edge cases. The AC might be precise and observable, but still not mention what happens at the boundary of a valid range, or when a user performs an action in an unexpected sequence.

Prompt:

You are a QA engineer looking for edge cases and missing scenarios in acceptance criteria.

USER STORY:
[Full story]

ACCEPTANCE CRITERIA:
[All AC items]

Identify edge cases and scenarios that are implied by this story but NOT currently specified in the acceptance criteria:

1. Boundary conditions: what numeric ranges, string lengths, date ranges, or quantity limits exist, and are their boundaries tested?
2. Sequence-dependent scenarios: what happens if actions are performed in an unusual order? (e.g., adding a discount code before adding items to cart)
3. Simultaneous or concurrent actions: what happens if two users perform conflicting actions at the same time?
4. State dependency gaps: what pre-existing system states affect this feature's behavior that aren't specified?
5. Integration failure scenarios: what happens when each external dependency this feature relies on fails?
6. Role and permission edge cases: does behavior differ by user role? Are all role combinations specified?
7. Data edge cases: very long inputs, empty inputs, special characters, unicode, duplicate data

For each missing scenario, provide: scenario description, why it matters (what bug it would catch), and the AC language needed to cover it.

Learning Tip: When using AI to audit AC, always run the prompt before the sprint starts — not during testing. The output of an AC audit is most valuable as input to a refinement conversation. If you surface an ambiguity after development is complete, it creates conflict. If you surface it during backlog grooming, it becomes a five-minute conversation that prevents a bug.

How to Raise Testability Concerns Early Using AI-Generated Feedback?

Finding testability issues is only half the job. The other half is communicating them effectively so they get fixed before they become bugs. QA engineers often hesitate to push back on AC because the feedback can feel like criticism, slow down the sprint, or create friction with product owners and developers.

AI helps you generate feedback that is specific, constructive, and framed in terms the team will respond to — quality outcomes and risk prevention, not QA gatekeeping.

Structuring AC Feedback for Development Teams

Development teams respond best to feedback that is specific and actionable. "This AC is unclear" creates defensiveness. "This AC doesn't specify what error message should appear, which means development and QA will implement and test different things" creates alignment.

Prompt:

You are a QA engineer preparing feedback on acceptance criteria to share with the development team at sprint planning.

TESTABILITY AUDIT RESULTS:
[Paste the output of your testability audit]

Transform these audit findings into constructive feedback for the development team:
1. For each testability issue, reframe it as: "Without this specification, [specific risk to sprint quality]"
2. Group issues by: "Must fix before development starts" / "Should fix before QA begins" / "Nice to have for future stories"
3. For each "Must fix" issue, provide a suggested revised AC wording
4. Frame the overall message as: "These questions will need answers before testing can proceed — let's resolve them now so we don't block QA later"

Output as a Jira comment or Slack message format that can be posted directly to the story thread.

Requesting AC Clarification Without Blocking the Sprint

Sometimes you can't wait for a full AC rewrite before development starts — the story needs to move. In these cases, the goal is to document the ambiguities and ensure they get resolved before QA begins, not before coding starts.

Prompt:

USER STORY AND AC:
[Paste story and AC]

TESTABILITY ISSUES IDENTIFIED:
[Paste audit issues]

I need to keep this story moving in the sprint but document the open questions that must be answered before QA begins. Generate:

1. A set of clarifying questions to ask the product owner or business analyst — specific, not generic
2. A list of assumptions I'm making in the absence of clarification, so development can proceed
3. A "testing blocked until" note that specifies exactly what needs to be decided before QA can start
4. A proposed definition of done addition: "AC clarified and reviewed by QA before testing begins"

Format this as a comment I can add to the story in our project tracker.

Building a Testability Quality Gate

For teams willing to invest in a formal process, a testability quality gate can be integrated into the definition of ready: stories cannot be pulled into a sprint unless their AC passes a minimum testability standard.

Prompt:

Help me build a testability quality gate checklist for our team's Definition of Ready.

TEAM CONTEXT:
- Domain: [Your product domain]
- Tech stack: [Frontend/backend/mobile/API — brief description]
- Typical story types: [CRUD features, workflow features, integration stories, etc.]

Create a Definition of Ready testability checklist that:
1. Can be reviewed in under 5 minutes per story
2. Covers precision, observability, completeness, and non-functional requirements
3. Has clear pass/fail criteria for each item (not "is this good?" but "does this criterion include a measurable pass/fail condition?")
4. Distinguishes must-have items (story cannot start without) from should-have items (story can start with these outstanding)

Format as a checklist that can be added to our story template.

Escalating Critical Testability Failures

Occasionally, AC are so vague or incomplete that no amount of testing can verify the feature is working correctly. This is a rare but serious situation — and it requires escalating beyond the story level.

Prompt:

I've identified a critical testability problem with this story: [describe the specific issue — e.g., "the core AC has no observable output because the feature is entirely backend and there's no API contract defined"].

Generate an escalation message to the engineering manager and product owner that:
1. Describes the testability problem clearly and specifically
2. Explains the risk: if this proceeds without clarification, we ship a feature we cannot verify
3. Proposes three options with tradeoffs: (a) delay story until AC is fixed, (b) proceed with documented assumptions that QA will verify by examining code/logs instead of UI/API, (c) add a spike story to define the observable contract first
4. Recommends option X because Y

Keep the tone collaborative and solution-oriented — this is a quality partnership conversation, not a blocker complaint.

Learning Tip: The most effective testability feedback is given as a question, not a judgment. "How will we know this is working?" is a question the whole team needs to answer. "This AC is not testable" is a verdict that creates resistance. When raising testability concerns, lead with the question, then provide the specific issue and suggested fix as supporting context. Teams that start asking "how will we know?" during refinement develop a fundamentally different quality culture than teams that leave that question to QA.

How to Turn Weak Acceptance Criteria into Structured, Testable Conditions?

Identifying that AC are weak is the diagnostic step. The productive step is rewriting them into testable conditions. This is where QA engineering skill is most valuable — and where AI is a useful drafting partner.

The AC Rewrite Framework

A well-structured testable criterion follows this pattern:

Given [system state / precondition]
When [user action or system event]
Then [observable outcome] within [performance threshold, if applicable]

This Given-When-Then (GWT) format, borrowed from BDD, forces precision. Every "Given" clause requires you to specify the precondition. Every "Then" clause requires a measurable, observable result.

Prompt:

You are a QA engineer rewriting vague acceptance criteria into testable Given-When-Then conditions.

ORIGINAL ACCEPTANCE CRITERIA:
[Paste the weak/vague AC items]

FEATURE CONTEXT:
[User story + brief description of the feature's technical implementation]

For each AC item:
1. Identify the ambiguity or missing information
2. Rewrite it in Given-When-Then format with:
   - Given: specific system state and preconditions
   - When: specific user action or system trigger (not vague like "when the user submits")
   - Then: observable, measurable outcome (what can be seen in the UI, API response, or database)
3. Add separate Given-When-Then statements for negative paths if the original AC only covers the happy path
4. Flag any assumptions you made that need product owner confirmation

After rewriting, highlight any information gaps that prevented you from making the criteria fully testable (things that need clarification before the rewrite is final).

Splitting Multi-Intent AC into Atomic Conditions

A common AC antipattern is the compound criterion: one AC item that contains multiple independent behaviors. "The user can reset their password and will receive a confirmation email" is two behaviors in one criterion. If the password reset works but the email fails, which criterion status is it?

Prompt:

ACCEPTANCE CRITERIA:
[Paste AC items]

Identify any compound acceptance criteria — items that contain more than one independent behavior or outcome — and split them into atomic criteria.

For each split:
1. Show the original compound criterion
2. Show the split atomic criteria
3. Explain why each is a separate, independently-testable condition

Also check for: AC items that implicitly contain multiple test cases (e.g., "system validates all form fields" — each field is a separate criterion), and recommend splitting them to the appropriate level of granularity.

Adding Non-Functional AC Where They're Missing

Features affecting performance, security, accessibility, or reliability almost always need explicit non-functional AC that product teams rarely include. QA engineers are often the only people thinking about this.

Prompt:

USER STORY:
[Paste the story]

EXISTING ACCEPTANCE CRITERIA:
[Paste current AC]

SYSTEM CONTEXT:
[Brief description of the system: user volume, regulatory environment, accessibility requirements, SLAs if known]

Identify where non-functional acceptance criteria are missing and draft additions for:
1. Performance: if this feature involves data retrieval, form submission, or page load — specify response time expectations
2. Security: if this feature involves authentication, user data, or financial operations — specify the security requirements (input sanitization, authorization checks, sensitive data masking)
3. Accessibility: if this feature has a UI component — specify WCAG level and key requirements (keyboard nav, screen reader labels, color contrast)
4. Error handling and resilience: if this feature depends on external services — specify behavior when dependencies fail
5. Cross-platform consistency: if this feature serves users on web, mobile, or multiple browsers — specify consistency requirements

For each addition, write it as a testable Given-When-Then criterion that can be added directly to the story.

Validating Rewritten AC Against the Original Intent

After rewriting AC, there's a risk that the rewrite changes the scope or intent of what was originally specified. Before finalizing rewritten AC, validate them against the product owner's intent.

Prompt:

ORIGINAL ACCEPTANCE CRITERIA:
[Paste original AC]

REWRITTEN TESTABLE CRITERIA:
[Paste rewritten AC in Given-When-Then format]

Review the rewritten criteria for:
1. Scope drift: do the rewrites add requirements that weren't in the original intent?
2. Missing intent: does the rewrite omit anything that was in the original criteria?
3. Over-specification: do the rewrites specify implementation details that should be left to the developer's judgment?
4. Stakeholder alignment: what questions should I bring to the product owner to confirm the rewrites are correct?

Produce: a comparison table (Original | Rewritten | Change Summary) and a list of open questions for the product owner.

Learning Tip: Rewriting AC is not QA's job in isolation — it's a collaboration. When you produce a rewritten set of testable criteria, frame it as "a draft for review" rather than a replacement. The product owner or BA owns the requirements; you own the testability perspective. A good working relationship means they welcome your "how will we test this?" lens as a quality improvement, not a QA bottleneck. Build this trust by delivering concrete, ready-to-use rewritten criteria instead of just raising problems.