We shipped the Acceptance Criteria Writer a while back, and it’s done what it was built to do — turn a rough feature idea into a proper user story with Given/When/Then criteria, the non-functional requirements people forget, and the edge cases that usually surface as production incidents instead of planning conversations.
But acceptance criteria answer one question: what should happen. They don’t answer a different, equally important one: how do you actually verify it happened. That’s a separate job, and it’s the one QA does — writing concrete test cases that cover not just the happy path, but performance, security, data integrity, and accessibility. A feature can have airtight acceptance criteria and still ship with untested edge cases in every one of those dimensions, because nobody translated “what should happen” into “here’s exactly how we’re going to check.”
So we built a second tool: the Test Case Writer.
What it does
You paste in the story and acceptance criteria you already have — from the AC Writer, or written yourself — and it generates concrete test cases grouped into five categories: Functional, Performance, Security, Data, and Accessibility. Each one comes with real steps and an expected result, not a vague “test that it works.” Each is also tagged Manual or Automated — a starting suggestion for how you’d actually execute it, not a QA strategy decision made on your behalf.
The categories beyond Functional only show up when something in the story genuinely implicates them. A simple internal toggle doesn’t get a manufactured “security test case” just to fill out the section. If there’s nothing real to say about a dimension, that section is just empty — same discipline we built into the AC Writer’s suggested-additions feature, where we’d rather show nothing than show filler.
What it doesn’t do — stated plainly, not buried
This is a language model reading requirements text. It has no way to execute code, no way to verify that anything actually works, and no way to guarantee full coverage. It predicts what ought to be tested, based on what you gave it. It does not test anything itself. That distinction matters, and we’re not going to let the name “Test Case Writer” imply otherwise.
Where this actually is right now
We just shipped this. It’s live, it’s built the way the AC Writer was — same discipline about honest limits, same anti-filler rule, same “suggestion, not decision” framing on manual versus automated. What we haven’t done yet is the thing that’s made every other feature here trustworthy: run it against a real story, with a real practitioner, and see where it holds up and where it doesn’t. That’s next. We’d rather tell you it’s freshly shipped and still being tested than round up to “proven” before it actually is.
Try it, and if something looks thin or wrong, that’s useful to know — that’s exactly what this stage is for.
Free, no signup: clarushorizon.com/test-case-writer
Leave a Comment