How do I write testable acceptance criteria with my AI assistant?

Testable acceptance criteria describe one observable outcome each: something a tester, a colleague, or an automated check could look at and answer yes or no. When you draft with an assistant, the risk is not that it writes too few criteria. It writes plenty, quickly, and several of them will be wishes dressed as checks.

This guide is the assistant-side version of a question the Jira and Azure DevOps guides answer for their fields. Here the field is a chat window, the author is a person and a model together, and the check happens before the tracker ever sees the story.

Why do assistant-drafted criteria fail?

Because the assistant is completing a pattern, and the pattern for acceptance criteria in most of its training data is a list of reassuring sentences. Ask for criteria on a delayed-delivery email and you will get “the email is sent reliably,” “the content is clear and accurate,” “errors are handled gracefully.” Each is plausible. None tells a tester what to do, and a coding agent handed those criteria will write tests that pass against its own interpretation of “reliably.”

The failure is invisible in the chat because the list looks complete. It becomes visible in the sprint, when the developer asks what “accurate” means and the product owner is in a different meeting.

What does a testable criterion look like?

One outcome, one condition, one way to check. The pattern that works in a chat draft:

• Name the state or trigger.“When a delivery’s ETA slips by more than 15 minutes…”
• Name the observable result.“…the customer receives one email containing the order number and the new delivery window…”
• Name the bound, if there is one.“…within 10 minutes of the delay being detected.”

Then the states everyone forgets, each as its own line: no email when the delivery is on time; no email when the customer has opted out; one email per delay event, not one per ETA recalculation. Those negative and edge cases are where the defects live, and they are the lines an assistant will not write unless asked.

How do I steer the assistant while drafting?

Give it the constraint before the request: “Write acceptance criteria as a list. Each line is one observable outcome with the condition that triggers it. No adjectives.” The last three words do most of the work; “fast,” “intuitive,” and “robust” are exactly the words the Testable dimension flags.

Then ask for the missing states explicitly: “Add the negative cases and the edge cases.” Read what comes back as a tester would. For each line, ask yourself what you would do to check it. If the answer is “read the code,” the criterion is not testable yet.

How does Vindex check the criteria?

Run the score-storycommand, or ask the assistant to score the story with Vindex, and read the Testable dimension. Its reasoning names what Vindex saw in the criteria as written; its suggestions name what is missing. On the Northwind sample story NW-105, whose three criteria looked complete, Testable came back 60 with the reasoning that the criteria lack specifics on what constitutes a delay, timing expectations, and edge cases such as a missing email or a cancelled order, and a suggestion to define opt-out behaviour precisely. That is the tester’s reading, delivered before a tester was involved.

Vindex judges the criteria; it does not write them. Take the suggestions back to the assistant, make the edits, and score again. The re-check is free.

When are the criteria good enough?

When every line could be turned into a test case by someone who was not in the conversation, and when a coding agent handed the story would derive its acceptance checks from your lines rather than its guesses. Testable at 80 or better is the threshold many teams write into their agent instructions for that reason. Then paste the story into the tracker, and it arrives with criteria the team can plan against on day one.