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

Posted on Oct 14 • Originally published at cloudqa.io • AI-assisted

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.

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

If you only fix one thing, fix the context.

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. Enter fullscreen mode Exit fullscreen mode 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):

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.

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). Enter fullscreen mode Exit fullscreen mode Ask for categories (input validation, session behavior, rate limiting, accessibility). Unstructured lists drift toward the obvious cases.

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. Enter fullscreen mode Exit fullscreen mode Treat the output as a starting checklist, not a security assessment. It doesn't replace a proper review or dedicated security tooling.

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. Enter fullscreen mode Exit fullscreen mode 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 Enter fullscreen mode Exit fullscreen mode 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? Enter fullscreen mode Exit fullscreen mode Question 3 is the important one. It surfaces cases where the model invented behavior, which is the most common failure in AI-generated tests.

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

Before any AI-generated test case enters your suite:

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

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. Enter fullscreen mode Exit fullscreen mode 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.

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.