Interactive tool
The Test Case Builder.
A test case is a set of conditions a stranger could follow to decide pass or fail. Write it that way, because one day a stranger will. Fill in the fields and this scores your case against the six characteristics of a good test case, then hands you a clean copy as a Markdown table and as Gherkin. Your draft saves in your browser, and nothing you type leaves it.
1 · Identify
Valid input, the happy path: the app does what it should.
2 · Set the stage
3 · The case
Scored against the six characteristics
Live preview
Draft the rest with AI
You wrote one. Let AI draft the variations, then you judge them.
AI is fast at the obvious cases: the negative paths, the boundaries and the equivalence sets you would otherwise grind out by hand. It is not the one who owns the risk call. This prompt is built from the case you have on the left, so it asks for the right thing. Paste it into Claude, ChatGPT or Cursor, then drop what comes back into this builder to score, prune and own it.
Field guide
The six characteristics of a case worth keeping
The score on the right is not arbitrary. It checks your case against these six. Hit all six and a stranger can run your case and get the result you intended.
Accurate
It tests exactly what it claims to. A specific title and an unambiguous expected result, so two people reading it reach the same verdict.
Economical
No wasted steps. Get from the known starting state to the check in as few steps as the case honestly needs, and not one more.
Traceable
It carries an id and links back to the requirement or acceptance criterion it proves, so you can show coverage when someone asks.
Repeatable
It starts from a known state with clear steps, so it gives the same result on the first run and the fiftieth, on your machine and a stranger’s.
Reusable
It names its test data and platform, so the same case travels to another data set, another environment, or a teammate without a rewrite.
Atomic
It tests one thing. One behaviour, one expected result. The moment a case checks two things, one of them gets skipped or quietly forgotten.
Positive and negative, and why you need both
A positive case uses valid input and proves the app does what it should: the happy path. A negative case feeds it invalid input or an illogical step and proves it fails gracefully, with a clear message and no broken state. Most real defects hide in the negative cases, so write them on purpose, not as an afterthought.
Why Gherkin, and how this maps
Given sets the context, When is the action, Then is the expected outcome. It reads like plain English, so a product owner can confirm it and an automation engineer can wire it up from the same lines. This tool maps the fields you fill in straight onto the three keywords, so you can hand off either format.