Writing acceptance criteria a machine can test

Most acceptance criteria are written for humans who already share context. That is why they cannot be turned into tests without a conversation.

The failure mode

The user can reset their password.

This is not testable. It does not say what happens to an unknown email, whether the reset link expires, whether an old link works after a second request, or whether the response differs for a registered and unregistered address — which is an account-enumeration decision, not a UX one.

A developer reads it and picks answers. A tester reads it and picks different answers. The bug report is written months later.

The shape that works

Given/When/Then is not ceremony. It forces three things into the open: the starting state, the trigger, and the observable result.

Scenario: reset link expires after one hour
  Given a password reset was requested 61 minutes ago
  When the user opens the reset link
  Then the page explains the link has expired
  And offers to send a new one

Every ambiguity above is now a decision somebody made on purpose.

Four questions that turn a vague criterion into a testable one

1. What is true before? Not 'the user is on the page' — what state is the data in?
2. What exactly triggers it? A click, a timeout, a webhook, a cron?
3. What can an outsider observe? If the only effect is internal, the test has nothing to assert.
4. What is the nearest failure? Every scenario should have a sibling that fails.

That fourth one catches the most. Teams write the happy path and stop, because the happy path is what the ticket described.

Then generate

Once criteria are in this shape, generating the suite is mechanical — which is the point. GoQA takes criteria in exactly this form and returns BDD cases you can export to Gherkin, Playwright, or Cypress. But the value is upstream: criteria specific enough to generate from are criteria specific enough to build from.

If you take one thing: write the sibling that fails.