How to Prompt an LLM for Test Cases You Can Actually Use

Originally published on the CloudQA blog.

Ask an LLM to "write test cases for a login page" and you'll get something that looks impressive and tests almost nothing. The output is fluent, well formatted, and generic: valid login, invalid password, empty fields. Any junior tester could have listed those in two minutes.

The model isn't the problem. The prompt is. An LLM can only work with what you give it, and "write test cases for login" gives it nothing about your product, your rules, or what counts as a failure.

This guide covers a simple prompt structure, five prompts you can adapt today, and the review habits that keep AI-generated tests from becoming a liability.

The four parts of a useful test-generation prompt

Whichever model you use, prompts that produce usable test cases tend to contain the same four things:

1. A role. "Act as a senior QA engineer" sets the level and vocabulary of the response. It's a small lever, but it works.
2. Real context. Paste the actual user story, acceptance criteria, API spec, or a code snippet. This matters more than anything else on the list. A model reading your real requirements can find real gaps. A model reading "a login form" can only guess.
3. A specific task. Use direct verbs: "Generate," "List," "Identify." Avoid "think about" or "consider."
4. An output format. Ask for a table with named columns, Gherkin, or JSON. If you want to paste the result into a test management tool, say so.

If you only fix one thing, fix the context.

Prompt 1: Functional test cases from a user story

The most common use case. You have a story and acceptance criteria and need a first pass at coverage.

Act as a senior QA engineer. Based on the user story and acceptance
criteria below, generate functional test cases as a table with the
columns: Test Case ID, Scenario, Preconditions, Steps, Expected Result.

Include positive, negative, and boundary cases. If any acceptance
criterion is ambiguous, list your assumption in a separate "Assumptions"
section instead of silently choosing an interpretation.

User story:
As a registered user, I want to add a product to my cart from the
product details page so that I can purchase it later.

Acceptance criteria:
1. The product details page displays an "Add to Cart" button.
2. Clicking it adds the selected item to the cart.
3. A confirmation message appears: "Product added to cart successfully."
4. The cart icon in the header updates to show the new item count.
5. If the item is already in the cart, the button stays clickable and
   the cart quantity increases.

The "Assumptions" instruction is the most valuable line in that prompt. It makes the model show its reasoning about gaps in your requirements instead of papering over them, and those gaps are often the real bugs.

Here's what good output looks like (an illustrative example, written by hand):

ID	Scenario	Steps	Expected Result
TC-01	Add a new item	Open product page, click Add to Cart	Item appears in cart, confirmation shown, header count +1
TC-02	Add an item already in cart	Add the same product twice	Quantity becomes 2, header count updates correctly
TC-03	Add while out of stock	Open an out-of-stock product	Button disabled or clear error shown, cart unchanged
TC-04	Rapid repeated clicks	Click Add to Cart five times quickly	Quantity is consistent, no duplicate line items

TC-03 and TC-04 aren't in the acceptance criteria. Cases like these are where the model earns its keep, and where you should look first when reviewing.

Prompt 2: Edge cases and negative scenarios

Models are good at brainstorming the unusual inputs people forget.

Act as a meticulous QA tester. For the login form described below,
list negative scenarios and edge cases. Focus on invalid input,
boundary conditions, and unusual user behavior. Group them by
category and, for each one, state what you expect the system to do.

Functionality:
A login form with "Email" (must be a valid email format) and
"Password" (minimum 8 characters).

Ask for categories (input validation, session behavior, rate limiting, accessibility). Unstructured lists drift toward the obvious cases.

Prompt 3: Security-focused test ideas

For testing your own applications, a model can quickly generate a checklist of common vulnerability checks. Only run these against systems you own or are explicitly authorized to test.

Act as an application security tester. For a registration form that
accepts username, email, and password, generate test cases to check
for common input-handling vulnerabilities such as SQL injection and
cross-site scripting. For each case, give the input, the field it
targets, and the secure behavior you'd expect.

Treat the output as a starting checklist, not a security assessment. It doesn't replace a proper review or dedicated security tooling.

Prompt 4: BDD scenarios in Gherkin

If your team writes behavior-driven specs, you can generate a first draft of the feature file.

Act as a BDD specialist. Write a Gherkin feature file for the feature
below, with multiple Scenario blocks covering positive and negative
paths. Use Scenario Outline with Examples where inputs vary.

Feature: Product search
As a user, I want to search for products by name so that I can find
what I'm looking for.

A trimmed example of the kind of output to expect:

Scenario: Search with a matching product name
  Given I am on the home page
  When I search for "wireless mouse"
  Then I should see products whose names contain "wireless mouse"

Scenario: Search with no matches
  Given I am on the home page
  When I search for "zzzzqqq"
  Then I should see a "no results found" message

Prompt 5: Ask the model to critique its own work

This one is underused. After generating a suite, run a second prompt against it:

Review the test cases below against the requirements I provided.
1. Which requirements have no test coverage?
2. Which test cases are duplicates or near-duplicates?
3. Which test cases assume behavior that isn't stated in the
   requirements?
4. What are the five highest-risk scenarios that are missing?

Question 3 is the important one. It surfaces cases where the model invented behavior, which is the most common failure in AI-generated tests.

Where AI-generated tests go wrong

LLMs are good first-draft engines. They are not oracles.

• They don't know your business. A model doesn't know that refunds over a certain amount need manager approval, or that one customer tier gets special pricing. It only knows what's in your prompt.
• They invent plausible behavior. If the requirements are silent, the model may fill in an answer that sounds right and is wrong for your product. Tests built on invented behavior fail for the wrong reasons, or worse, pass for the wrong reasons.
• They produce volume, not priority. Thirty test cases isn't better than ten if you can't tell which five matter.
• Generated automation code is a draft. If you ask for Playwright or WebdriverIO scripts, check every selector and wait strategy against your real application. Generated selectors are often guesses.
• Data privacy is your responsibility. Don't paste proprietary code, customer data, or confidential requirements into a public model interface. Use an enterprise offering with the data guarantees your organization requires.

A short review checklist

Before any AI-generated test case enters your suite:

1. Does it trace back to a real requirement?
2. Are the expected results stated explicitly, or just implied?
3. Is any behavior assumed that you haven't confirmed?
4. Is it a duplicate of something you already have?
5. Would you know why it failed if it failed?
6. Is it worth automating, or is it better as an exploratory check?

If a test case can't pass that list, rewrite it or drop it.

From prompt to automation

The usual workflow is: generate cases, review them, pick the ones worth automating, then turn those into scripts. You can ask a model for framework-specific code:

Convert test case TC-02 into a Playwright test in TypeScript. Use
role-based locators where possible, avoid fixed timeouts, and add a
comment above any selector you're unsure about.

That last instruction, flagging uncertain selectors, gives you a built-in list of things to verify by hand.

If you'd rather not hand-write prompts at all, CloudQA's AI test case generator produces test cases from a feature description in the browser.

The takeaway

Better prompts come from better inputs: real requirements, an explicit format, and a request for the model to state its assumptions. The model drafts quickly. Your job is to judge what's worth keeping.

---

CloudQA builds codeless test automation for web applications. If you're working on test case generation or reducing test maintenance, we'd be glad to hear what you're working on.