AI for QA: Turning Requirements Into Test Cases

A requirement lands in the backlog on Tuesday. By Thursday, someone has to turn it into test cases a person can execute, an automation engineer can script, and a product manager can argue with. That translation step is where AI test case generation earns its keep: a model reads the acceptance criteria, produces a structured draft covering the obvious paths and a pile of non-obvious ones, and hands a QA engineer something to edit instead of something to invent from a blank page.

The draft is not the deliverable. The edit is. This article covers the part of QA that is mechanical translation, the part that is not, and where the line sits between them. AI is genuinely strong at the first. It is unreliable at the second, and confusing the two is how teams end up with 400 test cases and no idea which ones matter.

What AI test case generation actually does

Strip away the marketing and the job is a transformation: unstructured prose into structured enumeration. A requirement says "users can invite teammates by email." A test suite says what happens with a valid email, an invalid email, an email already on the team, an email at a blocked domain, an empty field, 200 emails pasted at once, an invite sent by someone without permission to invite, and an invite accepted after the inviting user has been deactivated.

That expansion is exactly what language models are built for. They have absorbed an enormous amount of software documentation, bug reports, and test code, which means they carry a working memory of the standard failure taxonomies: boundary conditions, null and empty states, permission variants, race conditions, encoding problems, timezone arithmetic. Ask for test cases and you get that taxonomy applied to your feature. It is recall at speed, not insight.

Three kinds of input work well:

• Requirement text. User stories, acceptance criteria, PRD sections, API specs, a Slack thread where the behavior was actually decided.
• Existing system artifacts. An OpenAPI schema, a database table definition, a list of user roles, past bug reports for the same module. These constrain the model to real fields and real values instead of plausible-looking invented ones.
• Screenshots and designs. Useful, with limits covered further down.

The output can be plain numbered steps, a table with preconditions and expected results, Gherkin scenarios in Given/When/Then, or a decision table. The format matters less than the fact that you specify one. Unconstrained, models default to prose paragraphs that nobody can paste into a test management tool.

The mechanics: from a requirement to a test suite

The gap between a mediocre result and a genuinely useful one is almost entirely in how you frame the request.

Give it the real requirement, not your summary of it

The single most common mistake is pasting a two-line paraphrase. If you summarize the requirement first, you have already done the interpretation, and the model can only test your interpretation. Paste the whole acceptance criteria block, including the parts that seem irrelevant. The awkward clause about what happens on the enterprise plan is exactly the one that produces the case nobody thought of.

Add the surrounding context the requirement assumes: the list of user roles, the states an object can be in, the fields on the relevant table, the third-party service involved. A model that knows your subscription table has status values of trialing, active, past_due, and canceled will generate cases per status. A model that does not will generate cases for "an active subscription" and "an inactive subscription," which is not your system.

Name the test design technique you want

Generic requests get generic output. Specific requests get structure. The classical test design techniques are well documented and models know them by name, so use them:

• Equivalence partitioning for grouping inputs that should behave identically.
• Boundary value analysis for the values at the edges of each partition, plus one on either side.
• Decision tables for features with several interacting conditions, such as plan tier crossed with role crossed with feature flag.
• State transition testing for anything with a lifecycle: orders, tickets, subscriptions, documents in review.
• Pairwise (all-pairs) coverage when the combination space explodes and you need a defensible subset rather than every permutation.

Asking for "a decision table covering plan tier, user role, and whether the workspace has SSO enabled" produces a grid you can review in a minute. Asking for "test cases" produces a list you have to read line by line to find the holes.

Constrain the output shape and the volume

Say how many cases you want and in what columns. A useful default: ID, precondition, steps, test data, expected result, and a suggested priority the human will overwrite. Cap the count. Left alone, models pad, and padding is the fastest way to destroy trust in generated suites.

Make it flag ambiguity instead of resolving it

This is the highest-value instruction and the one most people skip. Requirements are ambiguous constantly, and the natural behavior of a model is to pick a reasonable reading and move on. Tell it not to. Ask for a separate list of every place where the criteria do not determine the expected behavior. That list is often more valuable than the test cases, because it gets resolved before the code is written rather than during regression.

Here is the kind of sentence that does all four things at once, typed into Skopx chat:

Read the acceptance criteria on PROJ-412 in Jira and the invitations table schema in our Postgres database, then draft test cases in a table with preconditions, steps, test data, and expected result. Cover happy path, boundary values on the email field, all four user roles, and the five most likely error states. Cap it at 30 cases. Separately, list every place the criteria are ambiguous about expected behavior.

What comes back is a table you can paste into your test management tool, grounded in the actual column names and constraints from the schema rather than guessed field names, with citations pointing at the ticket and the table it read. The ambiguity list at the bottom is the one you forward to the product manager before the sprint starts.

Coverage gaps AI test case generation is genuinely good at finding

Human testers under time pressure converge on the flows they can picture. Models do not get tired and do not have a mental model to be biased by, so they reliably surface categories that experienced teams still miss. In rough order of how often the output is actually useful:

Empty, one, and many. Zero results, exactly one result, and enough results to paginate. The empty state is skipped in design reviews constantly, and the "exactly one" case breaks list rendering and pluralization more often than it has any right to.

Boundary arithmetic. Character limits at length, length minus one, and length plus one. Quantities at zero and negative. Dates on the last day of the month, on February 29, and across a daylight saving transition. Money at the smallest unit and at values that trigger rounding.

Permission matrices. Every action crossed with every role, including the combinations nobody wrote down: what an admin sees on someone else's private item, what a deactivated user's session can still do, what happens when a user is removed from a team mid-session.

Failure paths of dependencies. The third-party API returns 500, returns 429, times out, returns success with a malformed body, or succeeds after your client already gave up. Requirements almost never specify these, and they are a large share of production incidents.

Idempotency and double submission. The user clicks Submit twice, refreshes during a redirect, or the webhook is delivered twice because the sender retries. Models raise this consistently.

Locale and encoding. Names with apostrophes and non-Latin characters, right-to-left text, thousands separators that are periods, addresses without postal codes, phone numbers without a country code.

Data lifecycle coupling. What happens to the child records when the parent is deleted, archived, or merged. What happens to a scheduled item when the person who scheduled it leaves.

Ambiguity in the requirement itself. Asked directly, a model will point at the sentence that has two readings. That is a specification review, delivered free, at the moment the specification is still cheap to change.

Generating test cases from screenshots and designs

Feeding a model a screenshot or a design frame works, with a clear boundary around what it can and cannot know.

What it can extract reliably: every visible field and control, the validation copy that is shown, the state currently rendered, inconsistencies in labels and button text, missing empty or loading or error states across a set of frames, and a plain inventory you can turn into a UI checklist. Give it three frames of the same flow and ask what states are missing from the design, and it will usually name the loading state, the error state, and the zero-data state, because designers hand off the happy path.

What it cannot know from pixels: which fields are required, what happens on click, what the backend validates, what the rate limits are, which values are legal, or what the flow does after the last frame. A screenshot-only prompt produces confident, plausible, partly fictional test cases.

The practical approach is to pair the image with text. Give it the frames plus the acceptance criteria, and ask it to reconcile the two: which criteria have no corresponding UI, and which UI elements have no corresponding criteria. That reconciliation catches the field that got added in design and never made it into the spec, which is a genuinely useful thing to catch in a design review rather than in QA.

Where AI test case generation falls down

Being specific about the failure modes is what keeps a generated suite from becoming a liability.

Invented fields, endpoints, and rules. Without grounding artifacts, the model fills gaps with things that sound right. A test case referencing a status field your API does not have wastes an hour of someone's day. This is fixable: ground every request in a schema, a spec, or real code.

Domain rules that are plausible and wrong. It will assume standard behavior for refunds, tax, proration, or SLA windows. Your business rules are not standard. Every case that encodes a business rule needs a human to confirm the rule.

Volume without weight. Eighty cases arrive with no ranking, or with a ranking the model guessed. An unranked suite is a scheduling problem wearing a coverage costume.

Regression scope. Asked what else this change might break, a model can only reason from what you showed it. It does not know that the billing module reads the same cache, or that this area has broken twice before in ways nobody documented.

Non-functional testing. It can produce a competent performance or security checklist. It cannot tell you what your latency budget is, what your traffic shape looks like, or what your threat model is.

Why a human still owns risk-based prioritization

Risk is likelihood multiplied by impact, and neither factor lives in the requirement document.

Likelihood comes from history: which modules have broken before, which parts of the codebase are held together by workarounds, which integration silently changes its API, which team shipped this at 6pm on a Friday. Impact comes from the business: which flow carries revenue, which customer represents an outsized share of it, which failure is publicly visible, which one has a regulatory dimension, which one is merely annoying. A model reading a ticket has access to none of this unless you put it there, and even then it is reasoning from a description rather than from having lived through the outage.

So the division of labor is clean. The model produces the candidate set and the coverage argument. The human assigns weight. In practice that means a short pass over the generated table where each case gets P0, P1, or P2 and a one-line reason. The reason is the part that compounds: after a few sprints you have a small corpus of examples showing how your team ranks risk, and you can hand that corpus back to the model as the standard it should propose against. It still proposes. You still own it.

A good acceptance test for any prioritization: would you sign off on the release with only the P0 cases green? If the answer is no, the ranking is wrong, and no amount of generated coverage fixes that.

Wiring it into the tools QA already lives in

Test case generation stops being a novelty when it stops requiring copy and paste. The ticket lives in Jira or Linear, the spec lives in Notion or Confluence, the schema lives in a database, the code lives in GitHub, and the test cases have to land back where the team looks.

This is the part Skopx is built for. It connects to nearly 1,000 business tools and lets you ask questions and take actions across them in chat, with answers that cite where they came from. You can query PostgreSQL, MySQL, and MongoDB directly in the same conversation, which is what makes the difference between generic cases and cases grounded in your actual columns and constraints. Skopx catches what falls between your tools, and the handoff from requirement to test case is exactly that kind of gap. The connector list is at skopx.com/integrations.

Two capabilities do most of the work for QA:

Chat with grounding. Point it at the ticket, the schema, and the spec page, and ask for the suite. Because it reads the real artifacts and cites them, you can check whether a case came from the acceptance criteria or from the model's imagination. The same grounding idea underpins company knowledge search, which is how you get answers about how the system is supposed to behave rather than a list of documents to read. For the test plan document itself, complete with sources, the mechanics in AI document generation apply directly.

Workflows you describe in chat. There is no drag-and-drop builder. You write what you want and it becomes a runnable automation with inspectable steps. A realistic QA one: when a ticket moves to Ready for QA, pull the description and acceptance criteria, draft the case table, and post it as a comment on the ticket for the assigned tester to edit. Triggers are manual, scheduled with a 15 minute minimum, or webhook, so a Jira webhook or a 15 minute poll both work. The limits are real and worth knowing before you design around them: workflows are acyclic, capped at 20 steps, have no human-approval step, and no custom code step. AI steps run on your own provider key. Details are at skopx.com/workflows.

Two honest exclusions. Skopx is not a test runner and does not execute your Playwright or Cypress suite. It is also not a test management system and does not replace the tool where your suites, runs, and results live. It generates, grounds, routes, and alerts. The execution layer stays where it is.

A workflow you can run this sprint

1. Pick one recurring ticket type. Not everything. One template of work your team sees weekly.
2. Assemble the grounding set. The schema for the affected tables, the role list, the API spec, and the last three bug reports for that module.
3. Write one prompt and save it. Requirement plus grounding, named techniques, fixed output columns, a case cap, and a mandatory ambiguity list.
4. Run it on a ticket you have already tested. Compare what it generated to what you actually ran. The cases it found that you missed tell you what it is worth. The cases it invented tell you what grounding is missing.
5. Add the human pass. Priority plus a one-line reason on every case. Delete aggressively. A 25-case ranked suite beats an 80-case flat one.
6. Automate the delivery, not the judgment. Let a workflow post the draft to the ticket. Keep the ranking with a person.
7. Route the ambiguity list to product before code starts. This is where most of the value ends up.

For the daily view of which tickets moved into Ready for QA and which are slipping toward the release date, a scheduled summary handles it. The pattern is the same one described in AI morning briefings.

Frequently asked questions

Does AI test case generation replace QA engineers?

No, and the framing misunderstands the job. Writing the cases is the visible part of QA, not the hard part. The hard part is knowing what is risky, what to skip, when the requirement is wrong, and when to hold a release. Generation removes the typing and the blank page. It does not remove the judgment, and a team that treats the output as final ships an unranked pile of cases with worse coverage of the things that actually break.

Should I ask for Gherkin or plain steps?

Ask for whatever your team already uses. Gherkin is worth requesting when the scenarios feed a BDD framework or when product people need to read them, because Given/When/Then forces one behavior per scenario. Plain tabular steps are better for manual execution and for pasting into a test management tool. What matters is that you specify a format at all, and that the columns match the fields your tool expects.

Can it generate automated test code, not just cases?

It can draft Playwright, Cypress, or pytest code, and the draft is usually structurally correct. The hard parts survive: selectors that match your actual DOM, fixtures and test data setup, authentication, and teardown. Expect to rewrite the selectors and the setup. Generated code is a starting scaffold, not a working suite, and it needs to run in CI before anyone counts it as coverage.

How do I stop it inventing fields and endpoints that do not exist?

Ground every request in a real artifact: an OpenAPI spec, a database schema, a type definition, or the source file. In Skopx that means querying the database or reading the repository in the same conversation, so the cases are built from real column names and real constraints, with citations you can check. Anything asserting a business rule you did not supply should be treated as a question for the team, not as a test case.

What does this cost, and where do the AI costs land?

Skopx is paid from the first day of every plan. Solo is $5 per month, Team is $16 per seat per month with no seat cap, and Enterprise and White Label are $5,000 per month. Current details are on the pricing page. AI usage runs on your own provider key from Anthropic, OpenAI, Google, or others, and Skopx applies no markup on it, so model spend is billed by your provider directly to you. The reasoning behind that arrangement is covered in bring your own key AI.

How many test cases should one requirement produce?

There is no correct number, but an unbounded request is the wrong shape. For a typical user story, asking for 20 to 30 candidates and then cutting to the 10 to 15 that carry real risk produces a suite people actually execute. Volume is the easiest thing for a model to produce and the least useful thing to measure.

Where to start

Do not roll this out as a process change. Take one ticket, one grounding set, and one saved prompt, and compare the generated suite against the one your team wrote by hand. The delta in both directions is the whole answer: what it caught that you missed is the value, and what it invented is the grounding you still owe it. Keep the ranking with a person, keep the ambiguity list going to product, and let the automation handle the part that was only ever transcription.