From a user story
A user story in. Test cases you can read. A run you can check.
Give it a Jira user story or an uploaded requirements document, and it produces the test cases that story implies, against your own application, in a real browser. No model decides what a test does — so the same story produces the same suite, and a pass means the same thing every time.
It refuses instead of guessing.
An acceptance criterion the grammar cannot place is returned to you marked unparsed, with the reason. A page element it cannot match confidently is not clicked. That is the difference between a tool you can hand a story to and one you have to check afterwards.
01
Read the story
Paste a Jira key, search for one, or upload a requirements document. The acceptance criteria are parsed by a grammar, not a model.
- —Rules are recognised by type: a numeric bound, an age bound, a not-in-the-future date, a required field, a declared format, a fixed set of options.
- —Anything the reader cannot classify comes back marked unparsed, with the reason it could not be read.
- —Nothing is inferred from prose. A criterion it cannot place is shown to you unread rather than guessed at.
- —A BRD, a Word document, a spreadsheet or plain text reads the same way as a story — the text is the input, and the tracker is only where it came from.
02
See the cases before they run
The rules expand into test cases against your own recorded flow. You review them as cases, not as a diff.
- —Each case says which rule and which acceptance criterion it came from.
- —Accepting and rejecting rows are generated together, so a bound is tested on both sides of its edge.
- —Dates are stored as expressions, not literals — a row that is on a boundary today is still on it next month.
- —The suite has a content hash, so you can tell a change in the tests from a change in the verdict.
03
Run it in a real browser
One button. A real Chromium session against your application, with the evidence kept.
- —Every step is resolved against the Knowledge Base your exploration built, with the confidence score that chose it visible.
- —A weak match is refused rather than clicked, so a green run means the steps it says it ran.
- —Screenshots, a video recording, per-step results and captured values, exported as a Word report.
What it needs from you
Stated plainly, because the honest version of this is shorter than the pitch. It reads a story against an application it has already explored — so there is a first step, and it is yours.
- —One exploration of the application, once, so the Knowledge Base has something to resolve against.
- —A story whose acceptance criteria name a field and a rule. "The form should work" is not a rule and will come back unparsed.
- —A Jira Cloud API token — or no tracker at all, if you upload the document instead.
Connects to Jira Cloud today; Rally and other trackers on request. An uploaded requirements document needs no tracker at all.
More on the mechanics in How it works, and what is guaranteed in Guarantees.