Skip to main content
AtwalLabs

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.

See it on one of your own stories

Bring a story and the application it is about. Access is by request while it is onboarded per team.

Or write to us from the contact page.

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.