Yes, large language models can generate test cases from user stories, acceptance criteria, and Figma designs, and this is one of the more mature applications of AI in QA because it maps naturally onto how models process structured and visual input. Given a user story with acceptance criteria written in Gherkin or plain language, a model can enumerate the happy path, edge cases, and negative scenarios a human tester would typically write, then format them as structured test cases or directly as executable test code stubs. For Figma designs, a multimodal model can read screen layouts, component states, and design metadata such as button labels and screen names through an exported image or API export, and infer navigation flows and validation rules like required fields or character limits. Output quality depends heavily on how complete the input is; vague user stories or design files without documented interaction states produce generic test cases that still need a QA engineer's domain knowledge to refine, particularly around business logic that is not visually obvious. This approach is best used to accelerate initial test case drafting rather than as a fully automated, unreviewed pipeline. Nanobase AI's Mobile Test Lab includes AI agents that can turn user stories and design references into executable Espresso and XCUITest cases as part of the test generation workflow.
What separates a usable output from a generic one
The quality gap in LLM-generated test cases almost always traces back to input completeness, not model capability. A user story with explicit acceptance criteria and a Figma file with labeled component states produces specific, useful test cases; a vague ticket and an unannotated screenshot produce generic ones that still need a QA engineer's domain knowledge to make useful. Input quality, more than prompt engineering, determines whether generated test cases are a starting draft or a finished list.
A worked example
Given a user story: "As a user, I want to reset my password via email so I can regain access to my account," with acceptance criteria specifying a 15-minute link expiry and a rate limit of three requests per hour, a model can reliably enumerate:
- Happy path: valid email submitted, reset link received, password successfully changed.
- Edge case: email submitted for a non-existent account (verify no account enumeration in the response).
- Edge case: reset link used after the 15-minute expiry window.
- Edge case: fourth reset request within an hour, verify rate limit triggers.
- Negative case: reset link reused after already being consumed once.
Without the specific expiry and rate-limit numbers in the acceptance criteria, the model would still generate a happy path and a generic "link expires" case, but not the specific boundary conditions, which is exactly the detail that turns a generated list into genuinely useful coverage. Generated test case quality is a direct function of how specific the acceptance criteria fed into it were.
What Figma input adds versus a user story alone
A multimodal model reading a Figma export can infer navigation flow, identify form fields and their apparent validation state (required field indicators, character counters), and read button labels and screen titles directly from the design. It cannot reliably infer business logic that isn't visually represented, such as the rate-limit rule above, or backend validation rules not shown as an error state in the design file, which is why design input works best combined with a written user story rather than as a sole input. Figma tells the model what the screen looks like; only the user story tells it what the screen is supposed to enforce.
A review checklist before treating generated cases as final
| Check | What to verify |
|---|---|
| Boundary values | Are specific numeric limits from acceptance criteria reflected accurately? |
| Negative/security cases | Does it include cases like account enumeration, injection, or reuse attempts? |
| Business logic coverage | Are backend rules not visible in the UI or story correctly represented? |
| Redundancy | Has the model generated near-duplicate cases that add no coverage? |
| Executability | Are cases specific enough to convert directly into Espresso/XCUITest code? |
Run every generated batch through this five-point check before it enters the backlog as accepted coverage.
Frequently asked questions
Can generated test cases be converted directly into executable test code?
Often as a next automated step, yes, especially for well-specified happy-path and boundary cases; cases involving backend state or complex setup usually need a human pass to fill in test data and environment setup details first.
Does this replace writing acceptance criteria carefully?
No, if anything it raises the value of writing precise acceptance criteria, since generation quality scales directly with how specific and complete the input is; vague stories produce vague test cases regardless of the model used.
How do we handle Figma files with interactive prototypes versus static screens?
Static exports give reliable layout and label information; prototype interaction flows (like conditional navigation) are harder for a model to infer purely from an image export and usually need the flow described in accompanying text.
Should QA engineers still write test cases manually at all?
Yes, particularly for business-logic-heavy and security-sensitive cases that aren't fully visible in a story or design, and for reviewing generated output for accuracy; the goal is accelerating the drafting step, not removing QA judgment from the process.
How Nanobase AI helps
Nanobase AI's Mobile Test Lab includes AI agents that turn user stories and design references into executable Espresso and XCUITest cases as part of the test generation workflow, with review checkpoints built in rather than treating output as final. For turning these cases into agentic exploration, see our AI agent testing guide or explore our solutions.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.