Turn a user story into test cases
Import a story or write one here, and Axon expands its acceptance criteria into happy-path, negative, and edge cases, each traceable to the criterion it verifies.
A user story tells you what a user should be able to do and why it matters. It does not tell you how to prove the feature works, which cases to write, or where it might break. Bridging that gap is skilled work, and it is also repetitive, which is exactly the kind of work worth handing to Axon, your AI assistant, while you keep the judgment for yourself.
As a customer, I can sign in so that I can access my account.
Start from the story, imported or written here
You can bring the story in from Jira or Azure DevOps, acceptance criteria and all, or write it directly in AxonQA when it lives only in someone's head. Either way, the acceptance criteria are the raw material. Axon reads them as the definition of done and expands each one into concrete test cases, rather than restating the criterion as a single step and calling it covered.
Happy path, negative, and edge, not just the sunny day
Good coverage is mostly about the cases nobody enjoys writing. From one criterion, Axon proposes the straight-through success path and then the ways it can fail: the rejected input, the expired token, the duplicate request, the value just past a limit. A password-reset criterion becomes a passing reset plus an unregistered email, an expired link, a second request before the first is used, and a new password that fails the policy. The negative and edge cases are where production incidents actually live, so they are generated by default, not left as an exercise.
- A happy path that proves the criterion is met when everything is valid.
- Negative cases for invalid input, wrong state, and denied permissions.
- Edge cases at the boundaries: limits, empty values, duplicates, and timing.
- Side effects the story implies, like a confirmation email or a stock change.
Every case traces back to the criterion it verifies
Each generated case points back to the acceptance criterion it came from, so coverage is legible rather than assumed. At release time you can show which criteria are covered and which are not, and when a story changes later, you can see immediately which cases are now suspect. Traceability is what turns a pile of cases into evidence, and it is kept automatically here instead of reconstructed by hand.
You review, prune, and add what only you know
Generation handles the mechanical breadth: structured cases, consistent format, the negative paths that are easy to forget. What it cannot supply is the domain knowledge a tool has no way to infer, like which edge case burned your team last quarter. So treat the output as a strong first draft. Review each case the way you would a colleague's, delete the duplicates, and add the one or two cases that only your history teaches. Axon writes the cases you would have written anyway, faster, and you spend your attention on the ones it could not have known to write.
The workflow is the same whether a story arrives from Jira, from Azure DevOps, or from your own keyboard: challenge each criterion instead of echoing it, cover the failures as well as the success, and keep every case tied to the requirement it proves. Do that, and a two-line story becomes a set of tests the whole team can run and trust.
See these practices inside AxonQA
Generate structured test cases from your stories, then validate them with real runs on your own app.