Asking a model to "generate test cases for this story" always returns the same thing: a long, even list with repeated cases and two or three rules nobody defined. It isn't a model capability problem. The request doesn't say which rules to work against, which technique to use or when to stop.

This guide replaces that request with a three-step flow that mirrors how a good analyst works: ask first, then design with technique and finally declare what was left out. The result isn't a longer list but a shorter, defensible one, where each case has a reason and you know which gaps remain.

How it fits together

Show the diagram as text

QA  ──▶ LLM   rules + user story
QA  ◀── LLM   ambiguities and questions
QA  ──▶ LLM   answers
QA  ◀── LLM   cases by technique (table)
QA  ◀── LLM   what was NOT covered
QA            review: duplicates · invented rules · missing negatives

Requirements

• The qa-ai-lab repo from day 4.
• A user story with acceptance criteria.
• Business rules in writing, even five lines.

Setup

Role: senior QA engineer. Source of truth: the BUSINESS RULES below. Do not invent rules.

BUSINESS RULES:
{{rules}}

USER STORY:
{{story}}

Step 1: list ambiguities and questions for the PO. Stop and wait.
Step 2 (after answers): design test cases using equivalence partitioning,
boundary values, decision table and error states.
Output a table: ID | Technique | Precondition | Steps | Expected | Risk (H/M/L).
Step 3: list what you did NOT cover and why.

Step by step

1. Business rules as the source of truth

Write the business rules first. They are the source of truth; without them the model invents some.

Before opening the chat, write the rules governing the feature, even if it's five lines: limits, possible states, who can do what. If they don't exist in writing, that's your first finding and it's worth more than any case. In the prompt, say explicitly that those rules are the only source of truth and that it must not invent others. Without that sentence the model fills gaps with what's common in other systems, not yours.

2. The template in the repo

Save the template in prompts/test-design.md.

Save the prompt as a file with variables for the rules and the story. Having it versioned lets you improve it gradually: every time the result fails in a new way, you add an instruction and the whole team gets it. It also makes work comparable across people, because everyone starts from the same request. It works the same in Spanish; what matters is that the three stages are separate and the first one ends with an order to wait.

3. Step one: questions

Step 1: ask only for ambiguities and questions. You or the PO answer them before moving on.

This stage delivers the most value and almost everyone skips it. Ask for ambiguities, contradictions between criteria and missing data, and nothing else. Take the real questions to the product owner before continuing. Every ambiguity resolved here is a defect that never gets written. If the model finds no questions in a story you know is incomplete, that signals missing context, and the cases it generates afterwards will be shallow.

4. Step two: cases by technique

Step 2: ask for cases by technique (partitions, boundaries, decision table, error states) in a table with risk.

With answers in hand, ask for cases naming the techniques: equivalence partitioning, boundary values, decision table and error states. Require a table with the technique for each case. That lets you see at a glance whether one is missing: a table with no boundaries or no error states is incomplete. It also reduces duplicates, because two cases from the same partition stand out when labeled.

5. Step three: what it didn't cover

Step 3: ask for the not-covered list. It's the most useful part for your review.

Ask for a list of what was left out and why. Concurrency, accessibility, performance, permissions and migration of existing data usually show up. That isn't a flaw in the result: it's information for deciding. Some things you'll cover with another kind of test and others you'll accept as risk, but the decision becomes explicit. This list is also the best input for the team conversation about what gets tested and what doesn't.

6. The three-question review

Review with three questions: any duplicates? any invented rule? any missing negatives? Whatever survives goes to your test management tool.

Review the table looking for three things. Duplicates: cases exercising the same partition with another value. Invented rules: any expected result you can't trace to a written rule. Missing negatives: invalid inputs, insufficient permissions, impossible states. Discarding a third is normal. Priority is yours to set as well, because the model tends to mark everything as high risk. What survives goes into your test management tool under your name.

Illustrative example

The story says: "as a customer I want to transfer money to another account". There are four written rules: minimum amount, daily cap, active destination account and sufficient balance. In step one the model asks what happens if the daily cap is reached in the middle of a scheduled transfer and whether the cap is per customer or per account; nobody had defined it. In step two it returns twenty-two labeled cases. In review, five duplicates from the "valid amount" partition and two assuming a nonexistent fee are discarded. Fifteen remain. Step three declares it didn't cover concurrency between two sessions, and the team decides to test that separately.

Common mistakes

• Asking for cases without passing the business rules.
• Merging the three steps into one request and losing the questions stage.
• Loading cases into the tool without checking duplicates or invented rules.
• Accepting the priority the model assigns.

Checklist: how to know it is done

• The template is versioned under prompts/.
• At least one real ambiguity reached the product owner.
• Each final case has a technique and traces to a written rule.
• There is a discard list with the reason for each.

Where AI fell short

It assigns high risk to almost everything. Prioritizing is a business decision, not a writing task.

Frequently asked questions

Does this replace the test analyst?

No. It replaces the part of drafting the first version. The right questions to the product owner, prioritization and the decision about what to discard remain the work of a person who knows the business. Without that review, the result is a long list nobody owns.

Does it work with badly written stories?

It works especially there, but only step one. With a poor story the model returns many questions, and that is exactly what you need to bring to refinement. Don't move to step two until you have answers: generating cases on top of assumptions multiplies the error.

How do I avoid pasting sensitive information into the prompt?

Describe the rules without real customer data and use a provider approved by your company or a local model. Business rules can usually be shared within approved tools; people's data cannot. If in doubt, ask your security team before the first prompt, not after, and write the answer down next to the template so the whole team follows the same rule.

Day 5 of 31 of the 31 days of QA + AI series. Commands and versions reviewed in November 2026: rerun them before relying on them, AI tooling changes fast.

← Previous: Your AI QA lab: full setup in 30 minutes

Next: Synthetic test data with LLMs: realistic, valid and PII-free →