Prompt Chaining for Test Cases: From Requirement to Test Suite

One giant prompt often gives one giant, messy answer. Good testers do not jump straight from a requirement to final test cases. They read, question, plan and then write. Prompt chaining for test cases follows the same natural order, one small step at a time.

📖 What You’ll Learn

What a prompt chain is
Why small steps beat one huge prompt
A four-step chain from requirement to test cases
Where a human must stop and check the work

💡 What Is Prompt Chaining?

Explain Like I’m 5: Prompt Chaining

Imagine: You do not build a sandcastle in one move. First you fill the bucket. Then you flip it. Then you add the towers.

What it really means: You split a big job into small prompts. Each answer feeds the next prompt.

In testing: Find the gaps first, then plan scenarios, then write test cases.

A prompt chain is a series of prompts where the output of one step becomes the input of the next. You can review and correct the work between steps.

🔍 Why Small Steps Work Better

Explain Like I’m 5: Checking Each Step

Imagine: While baking, you taste the batter first. If it is too salty, you fix it before it goes in the oven.

What it really means: You can catch a mistake early, before later steps build on it.

In testing: Fix a wrong assumption before it spreads to 30 test cases.

One big prompt	A prompt chain
Hard to see where it went wrong	Each step can be checked
A wrong assumption spreads everywhere	Mistakes are caught early
May skip clarifying questions	Questions become a planned step
One long answer to review	Small answers to review

🧩 The Four-Step QA Prompt Chain

Explain Like I’m 5: Four-Step Chain

Imagine: To plan a picnic, you ask who is coming, list what to bring, choose the food, and then pack the basket.

What it really means: Each step has one job, and they happen in a sensible order.

In testing: Understand, question, plan, write.

Step	Goal	Human check
1. Understand	Turn the requirement into a clear list of rules	Is every rule correct?
2. Question	Find gaps, conflicts and assumptions	Get real answers from the team
3. Plan	List scenarios and their risk	Is anything important missing?
4. Write	Create detailed test cases	Review the final test cases

Step 2 is where the value is

Take the questions to your product owner or developer. Do not ask the AI to answer them. It does not know what your business decided.

🌍 Real-Life Example: Hotel Booking Cancellation

Here is the requirement used in this chain:

Guests can cancel a booking for free up to 48 hours before check-in. After that, one night’s charge applies. Non-refundable bookings cannot be cancelled online.

Step 1: Understand

You are a senior QA engineer. Read the requirement below.
List each business rule as a separate numbered item with the ID R1,
R2 and so on. Do not add any rules of your own.

Requirement:
[paste requirement]

Step 2: Question

Here are the approved rules:
[paste the rules you checked in Step 1]

List anything that is unclear, missing or in conflict. Write each one
as a question for the product owner. Do not answer the questions.

For this requirement, good questions could be: Which time zone applies? Does exactly 48 hours count as free? How much is one night’s charge when room prices vary by night?

Step 3: Plan

Here are the approved rules and the answers from the product owner:
[paste rules and answers]

Create a test scenario list. For each scenario, give an ID, a one-line
description, the rule ID it covers, its type (Positive, Negative or
Boundary) and its risk (High, Medium or Low).
Use only the information above.

Step 4: Write

Here are the approved scenarios:
[paste the scenarios you reviewed]

Write full test cases for the High risk scenarios only.
For each one, give ID, Rule ID, Preconditions, Steps, Test Data and
Expected Result. If an expected result is not supported by the rules,
write "NEEDS CONFIRMATION" and do not guess.

Because every test case carries a rule ID, you can see which rule it covers. This link between a rule and its tests is called traceability.

📌 Keeping a Chain on Track

Paste only the reviewed output into the next step.
Start a fresh chat if a conversation becomes very long, as you learned in How LLMs Work.
Keep each step’s prompt saved, so you can reuse the whole chain.
Stop when a step needs a business decision. Get the answer first.

🔑 When a Chain Is Too Much

A chain takes more time than a single prompt. Use one for important or complex features, such as payments. A small text change usually needs just one prompt built with the 5-part QA prompt formula.

🧪 Try It Yourself

Choose the cancellation or search feature on the Dummy Booking Website.
Write 3 made-up business rules for it.
Run Step 1 and correct any wrong rule yourself.
Run Step 2, and answer the questions yourself as if you were the product owner.
Run Steps 3 and 4. Check that every test case links to a rule.

📋 Ready-to-Copy Prompt

Use this as a starter prompt to plan a chain for any feature.

You are a senior QA engineer. I want to design tests for the feature
below, one step at a time.

Feature description:
[paste feature description]

Do Step 1 only:
- List each business rule as R1, R2 and so on.
- Do not add any rules that are not in the description.
- Then stop and wait for me to review the list.
Do not write any test cases yet.

⚠️ Common Mistakes

Sending the next step before reviewing the previous answer
Letting the AI answer its own business questions
Using a long chain for a very small change
Passing unreviewed output forward, so errors grow
Losing the link between rules and test cases

🎯 Key Takeaways

A prompt chain splits a large job into small, checkable steps.
The four steps are understand, question, plan and write.
People must answer the business questions, not the AI.
Rule IDs give you traceability from requirements to test cases.

🎤 Interview Questions

1. What is prompt chaining?

Model answer: Prompt chaining breaks a large task into a sequence of prompts, where each output feeds the next one. In testing, I use it to go from a requirement to rules, questions, scenarios and then detailed test cases.

2. Why use a prompt chain instead of a single prompt?

Model answer: It lets me check the work at each stage and catch wrong assumptions early. A single large prompt can hide mistakes, and those mistakes can spread through the entire test set.

3. How would you use AI to design tests from a requirement?

Model answer: I would extract the rules first and verify them. Next, I would ask for gaps and take those questions to the product owner. Then I would generate a scenario list with risk levels, review it and finally create detailed test cases.

4. What is requirement traceability, and how can a prompt chain support it?

Model answer: Traceability links each test back to the requirement it covers. In a chain, I give every rule an ID and ask the model to include that ID in each scenario and test case. I can then spot rules with no coverage.

5. Where should a human be involved in a prompt chain?

Model answer: A human should review every step and answer all business questions. The model can identify a gap, but it cannot know what the business decided. A person should also approve the final test cases.

📝 Assignment

Run the full four-step chain on a feature of your choice, using made-up rules. Create a small table showing each rule ID and the test cases that cover it. Highlight any rule with no test case. Also record one mistake you caught between steps.

❓ FAQ

Should I run all the steps in one chat?

You can, as long as the conversation stays focused. For long work, start a new chat and paste in only the reviewed output.

Can this be automated later?

Yes. A workflow that runs steps in order is the basic idea behind the AI agents you will build in Level 6. Human review points stay important there too.

🚀 Next Steps

Well done on finishing this lesson. Complete the assignment, then continue with Gherkin Test Cases with AI: Get Tables, JSON and CSV Output.