Design drops a frame. Product pastes a story. Engineering starts coding.
QA is somehow expected to “be ready” with cases before the build exists — and also not invent requirements that weren’t approved.
That tension is normal. Pretending you need a 12-page PRD before you can think about tests is how releases slip.
What a mockup actually gives you
A decent screen (even a messy one) answers questions a story often skips:
- What’s mandatory vs optional on this form?
- Are there empty, loading, and error states drawn?
- Is there a secondary action nobody wrote AC for?
- Do mobile and desktop even match?
You still need the story for rules (“discount can’t stack with gift cards”). The mockup is for interaction surface area.
A practical loop we use
- Story first — generate functional cases from the written requirement
- Mockup second (Pro on TestCaseMate) — feed the screen so steps talk about real fields, not “enter valid data”
- Diff them — cases that only appear from the mockup often catch UI-only risks; cases only from the story often catch business rules
- Cull — if two cases test the same thing with different wording, keep one
You’re not looking for volume. You’re looking for angles you would have missed at 6pm on a Thursday.
Example (short)
Story says: “User can reset password via email link.”
Mockup shows: password rules tooltip, “resend in 60s,” and a “back to login” that isn’t in AC.
Without the image, you might ship cases that never touch cooldown or the back path. With it, those show up in the draft — and you decide what belongs in this release vs a follow-up.
Tooling note (honest)
In TestCaseMate you can generate from stories on Free. Mockup upload sits on Pro because image analysis costs more to run. If you’re evaluating, start with stories; upgrade when design-heavy work is your bottleneck.
Either way: treat output like a junior’s draft. Praise the useful bits. Rewrite the rest. Own the suite that goes to the run.
See story + mockup generation in TestCaseMate.
Try TestCaseMate →
