SELF-GUIDED BA PRACTICE Selected editions available · Access after confirmed paymentCheck editions ↗

Free BA tool

Acceptance criteria checker

Paste your acceptance criteria and get a quick, rule-based review of the wording problems that most often make criteria hard to test.

Acceptance criteria are the conditions a story must meet to be accepted. Good criteria are specific enough that a developer, a tester and the business would all reach the same pass or fail result. Many are written in Gherkin's Given/When/Then form: Given a starting state, When an action happens, Then an observable result follows.

This checker looks for common wording problems: vague words such as "fast" or "user-friendly", scenarios missing a Given, When or Then, several behaviours bundled into one criterion, and statements nobody can test, such as "the system handles errors". Each flag explains why it matters and shows a better example.

A heuristic aid, not a judgement. The checker matches words and patterns; it does not understand your product. It will miss some problems and flag some wording that is fine in context. Your own judgement and a conversation with your team decide what is good enough.

How to use it

  1. Paste your criteria into the box. Put each one on its own line or bullet, or separate full scenarios with a blank line.
  2. Press Check criteria. Each criterion is listed with its flags; a criterion with no warnings is marked as clear.
  3. Read why each flag matters and compare your wording with the better example.
  4. Rewrite the criterion in your own document, then paste it again to re-check.

Acceptance criteria checker

Private by design. What you type stays in your browser. Nothing is sent to BA Mentorship. Nothing is saved either: copy or download your work before you close the tab.

Put each criterion on its own line or bullet, or separate Given/When/Then scenarios with a blank line.

Results appear here. Nothing is checked until you press Check criteria.

Questions and explanations

Which words count as vague?

Words that different readers would measure differently: speed words (fast, quick), ease words (easy, intuitive, user-friendly), comparisons with no baseline (better, improved), feelings (seamless, smooth), open lists (etc., and/or) and unquantified amounts (some, many, large). The fix is nearly always a number, an exact message or a named condition.

Do all criteria need Given/When/Then?

No. Simple rules such as "The export file is named orders-YYYY-MM-DD.csv" are clear without it, so the checker only notes them as information. Given/When/Then helps most when the result depends on a starting condition or an action. When you do use it, all three parts should be present.

Why is "more than one behaviour" a problem?

If one criterion checks two things and only one works, the criterion is neither passed nor failed, and the conversation about what to fix gets harder. One behaviour per criterion keeps test results clear and makes it easier to trace each one back to a requirement.

What does "untestable" mean here?

A statement is untestable when no finite test could prove it: absolutes such as "always" and "never", outcomes nobody can observe, such as "the user understands", or topics with no result, such as "supports bulk upload". Rewrite them as an observable result under stated conditions.

Does the checker send my criteria anywhere?

No. The checks are simple rules that run in your browser, so your text never leaves your device and is not stored. That also means there is no AI involved: the same text always gets the same result.

These tools are free practice aids from BA Mentorship. They use simple, transparent rules, not AI, and they do not assess or certify your work. BA Mentorship is not affiliated with IIBA, PMI or IREB.

CHECK BEFORE CONTINUING

Keep your work safe