Few-Shot Prompting for Test Cases: Teach AI Your Team’s Format
Every QA team writes test cases in its own style. AI does not know yours until you show it. Few-shot prompting for test cases solves this by giving the AI a couple of good examples first. In this lesson you will learn how to pick those examples and when they are worth the effort.
📖 What You’ll Learn
- What zero-shot, one-shot and few-shot prompting mean
- How examples make AI output more consistent
- How to choose good examples
- The mistakes that can make examples backfire
💡 What Is Few-Shot Prompting?
Explain Like I’m 5: Few-Shot Prompting
Imagine: A teacher draws two neat letter As on the board. Then the class copies the same style.
What it really means: You show the AI a few finished examples. It then follows that pattern.
In testing: Show two test cases in your team’s format, then ask for more.
A “shot” simply means an example. The name tells you how many examples are in the prompt.
| Name | Examples given | Good for |
|---|---|---|
| Zero-shot | None | Simple questions and quick ideas |
| One-shot | One | Showing a basic layout |
| Few-shot | Two or more | Matching a team format or a tricky pattern |
🔍 Why Examples Help Testers
Explain Like I’m 5: Why Examples Work
Imagine: You can describe a zebra with many words. Or you can just show a picture. The picture is quicker.
What it really means: An example shows details that are hard to explain in words.
In testing: One example can show your ID style, tone and level of detail.
Examples are especially useful for showing:
- Your test case ID pattern, such as
LOGIN-001 - How short or detailed steps should be
- How expected results are worded
- How you label priority and test type
🧩 How to Choose Good Examples
Explain Like I’m 5: Choosing Examples
Imagine: If you teach someone to draw by showing a messy picture, they will copy the mess.
What it really means: The AI copies the weaknesses in your examples as well as the strengths.
In testing: Only use test cases that you would approve in a review.
Follow these four rules:
- Use your best work. Pick examples that have already passed review.
- Show variety. Include one positive and one negative case.
- Keep them short. Two or three examples are often enough for a format.
- Remove real data. Replace names, accounts and internal URLs first.
Keep examples separate from the task
Label them clearly as examples. Otherwise, the AI may treat their details as rules for the new feature.
🌍 Real-Life Example: A Product Search Filter
A team uses the format below. Here is how a tester teaches it to the AI.
You are a QA engineer. Write test cases in exactly the format shown
in the examples. The examples are about a different feature. Use them
for format only.
EXAMPLE 1
ID: LOGIN-001
Title: Login succeeds with valid details
Priority: High
Type: Positive
Steps:
1. Open the login page
2. Enter a valid email and password
3. Select Log in
Expected: The dashboard opens and shows the user's name
EXAMPLE 2
ID: LOGIN-002
Title: Login is blocked with a wrong password
Priority: High
Type: Negative
Steps:
1. Open the login page
2. Enter a valid email and a wrong password
3. Select Log in
Expected: An error message appears and the user stays on the login page
NEW FEATURE
A shopper can filter products by a price range. Minimum and maximum
are both optional. The minimum cannot be greater than the maximum.
TASK
Write 6 test cases. Use the ID prefix FILTER. Use only the rules
above, and list any unclear rules as questions at the end.
The AI now knows the layout, ID style and level of detail. You can review the answer much faster, because every test case looks the same.
📌 When Few-Shot Prompting Is Not Needed
Examples take effort and use up space in the context window. Skip them for simple questions or quick brainstorming. Examples can also narrow the AI’s thinking, so it may copy their subject too closely. If you want fresh ideas, try without examples first.
Change one thing at a time
To learn whether your examples help, run the same task with and without them. Compare the results using the same review rules.
🧪 Try It Yourself
- Take two good test cases from your own practice work. Remove any private details.
- Choose a feature from the Dummy E-commerce Website.
- Run the task once with no examples.
- Open a new chat and run the prompt below with your examples.
- Count how many edits each answer needs before you would accept it.
📋 Ready-to-Copy Prompt
You are a QA engineer. Write test cases in exactly the format shown
in the examples below. The examples are about a different feature.
Copy their format only, not their content.
EXAMPLE 1
[paste a reviewed positive test case]
EXAMPLE 2
[paste a reviewed negative test case]
NEW FEATURE
[describe the feature and its business rules]
TASK
Write [number] test cases using the ID prefix [PREFIX].
Rules:
- Use only the information under NEW FEATURE.
- Do not invent fields, screens or rules.
- After the test cases, list anything unclear as questions.
⚠️ Common Mistakes
- Using unreviewed or weak test cases as examples
- Pasting examples that contain real customer data
- Giving ten long examples when two short ones are enough
- Showing only positive examples, then getting only positive output
- Letting details from the examples leak into the new test cases
🎯 Key Takeaways
- A “shot” is an example, and few-shot prompting uses two or more.
- Examples are a quick way to teach your team’s test case format.
- The AI copies weaknesses too, so use only reviewed examples.
- Skip examples for simple tasks or open brainstorming.
🎤 Interview Questions
1. What is few-shot prompting?
Model answer: It means including a small number of worked examples in the prompt so the model can follow the pattern. In QA, I would show two reviewed test cases and then ask for more in the same format.
2. What is the difference between zero-shot and few-shot prompting?
Model answer: Zero-shot gives only the instruction, with no examples. Few-shot adds examples of the desired output. I use zero-shot for simple questions and few-shot when format or a particular pattern is important.
3. How do you choose examples for a few-shot prompt?
Model answer: I choose short, reviewed test cases that show a mix of scenarios, such as one positive and one negative. I remove real data and label them clearly so that the model treats them as a format guide.
4. What can go wrong with few-shot prompting?
Model answer: The model can copy mistakes in the examples, or carry their details into the new output. Too many examples also use up context and can limit variety. I review the result and compare it with a run that has no examples.
5. When would you avoid few-shot prompting?
Model answer: I would avoid it for simple questions and early brainstorming, where I want a wide range of ideas. If the model already gives acceptable results, adding examples is extra work with little benefit.
📝 Assignment
Create a few-shot template for your team’s test case format, with two reviewed and fully anonymised examples. Test it on two different features from the Automation Practice Page. Note any place where details from your examples leaked into the output.
❓ FAQ
How many examples should I give?
Two or three is a good starting point for matching a format. Add more only if testing shows that they improve the result.
Can I use examples from an earlier AI answer?
Yes, but only after you have reviewed and corrected them. Human-approved examples are the safest choice.
🚀 Next Steps
Well done on finishing this lesson. Complete the assignment, then continue with Prompt Chaining for Test Cases: From Requirement to Test Suite.