Imagine that you ask a language model to review a requirement and suggest tests. Its answer looks reasonable—but it assumes a rule your team never agreed on.
You try again. This time, you include an example showing the response pattern you want when a rule is missing. That example may make the expected pattern clearer to the model.
This is the practical idea behind one-shot and few-shot prompting: you include one or more examples of the kind of response you want.
But when should you give no example, one example or several? And how can QA professionals use each approach?
First, what is a “shot”?
In this article, a shot means a demonstration included in the prompt. For the QA tasks below, each demonstration contains:
- a sample input; and
- a sample response that demonstrates the pattern you want.
The three approaches are simple:
- Zero-shot: No worked example.
- One-shot: One worked example.
- Few-shot: Multiple worked examples.
The model can use these examples as in-context guidance when it responds to a new input. Results vary by model, task, instructions and examples; a demonstration does not guarantee a particular response.
The number of shots refers to the examples you provide, not the number of test cases you ask the AI to create.
For example, “Generate ten test cases” is still a zero-shot prompt if you do not provide a sample input and output. One-shot also does not mean sending only one chat message. A single message can contain several examples.
You can still include a requirement, context and detailed instructions in a zero-shot prompt. “Zero” only means that the prompt contains no worked examples.
In ordinary in-context prompting, adding examples does not update the model's trained parameters. The examples are part of the input used to produce that response. This differs from fine-tuning or other training methods that update model parameters.
| Approach | Worked examples | Useful QA starting point | Limitation |
|---|---|---|---|
| Zero-shot | None | The requirement is clear and the task is straightforward. | The answer may miss team-specific conventions. |
| One-shot | One | You want to show an approved format or decision. | One example may not cover other types of requirements. |
| Few-shot | Multiple | You want to show different situations, such as a clear rule, a missing rule and a boundary. | Unrepresentative or incorrect examples may lead to unwanted responses. More examples also make the prompt longer. |
This table is a practical starting point, not a rule that applies to every model or task. There is no universal number of examples at which “few-shot” begins or ends.
Let us see how this works with a simple requirement.
A requirement may need both tests and clarification questions. To compare the three approaches, we will build three prompts for the same login requirement.
Every prompt begins with the shared instruction below. After it, add the block shown in the zero-shot, one-shot or few-shot section. The task and the new login requirement remain the same. Only the number of worked examples changes.
Shared instruction: Review the new requirement. Suggest tests for the rules it clearly states. Ask clarification questions for missing rules instead of assuming the answers. Return both tests and questions when needed.
Zero-shot: start with clear instructions
To create the complete zero-shot prompt, start with the shared instruction and add only the new requirement below:
New requirement: “After five failed login attempts, lock the account for 15 minutes.”
The model has the requirement and a clear task. A response grounded in the stated requirement could suggest tests to verify that:
- the account is locked after the fifth failed attempt; and
- the lock lasts for 15 minutes.
A response could also ask about a detail the requirement does not define: does a successful login reset the failed-attempt count? This question identifies an omission; it does not assert that such a reset exists.
If clear instructions already produce a response that meets your evaluated needs, an example may be unnecessary.
For that reason, zero-shot can be a sensible starting point for a straightforward QA task when the source information is clear and no team-specific response pattern needs to be demonstrated.
A practical workflow is to start with the requirement and a precise task. If the result passes your evaluation, you can stop there. Adding an example always makes the prompt longer, but it does not necessarily improve the answer.
However, zero-shot does not mean writing a vague sentence and hoping for a good answer. The prompt still needs a clear task, and the requirement must contain the facts needed for the expected tests. Better wording cannot supply a business rule that the source never defined.
One-shot: show one good answer
Suppose the AI creates a test but does not identify a missing detail in the requirement.
To create the complete one-shot prompt, start with the shared instruction. Then add the block below, which contains one worked example followed by the new login requirement:
Example requirement: “A customer can retry a failed payment up to the configured limit.”
Example response: Test: Fail a payment and verify that a retry is offered. Question: What is the configured retry limit?
New requirement: “After five failed login attempts, lock the account for 15 minutes.”
This example demonstrates a response pattern: one part of a requirement may be clear enough to test, while another part still needs clarification.
The login requirement remains the new item to review. This is one-shot prompting because the prompt contains one worked example. The number of other instructions does not change that.
One-shot prompting may help when zero-shot trials repeatedly miss a pattern your team expects. Here, the example demonstrates that a response can contain both a test based on stated information and a clarification question about missing information.
One example provides limited coverage. The example above does not demonstrate how to handle:
- a requirement with no missing information; or
- a requirement with an important boundary.
Additional examples may help demonstrate those situations, but their effect should be tested.
Few-shot: demonstrate different situations
To create the complete few-shot prompt, start with the shared instruction. Then add the block below, which contains three worked examples followed by the same new login requirement:
Example 1 Requirement: “The reset link expires after 15 minutes.” Response: Test: Open the link after 15 minutes and verify that it is rejected.
Example 2 Requirement: “A customer can retry a failed payment up to the configured limit.” Response: Test: Fail a payment and verify that a retry is offered. Question: What is the configured retry limit?
Example 3 Requirement: “An order over ₹5,000 requires approval.” Response: Test: Submit an order of exactly ₹5,000 and verify that this threshold alone does not trigger approval.
New requirement: “After five failed login attempts, lock the account for 15 minutes.”
These examples demonstrate three different situations:
- a direct test based on a clear rule;
- a test combined with a clarification question; and
- a boundary test.
They also use consistent labels and distinguish between a stated rule and a missing rule. They are intended to encourage the model to apply the same response pattern to the new login requirement; they do not guarantee that it will do so correctly.
The content of the examples can affect the response. If an example contains the wrong expected result, the model may reproduce or extend that mistake.
Few-shot prompting is worth evaluating here because the task contains several kinds of decisions. Choose examples that resemble the real work and cover meaningful differences. Three almost identical happy-path examples would not demonstrate how you want missing rules or boundaries handled.
The same idea works beyond requirements
Imagine that your team rewrites defect reports using three fields: Steps, Observed and Expected.
- A zero-shot prompt names the three fields and explains the task.
- A one-shot prompt also includes one approved defect report to show the expected detail.
- A few-shot prompt includes different examples, such as a UI defect, an API failure and a defect where the expected behaviour is unknown.
For a defect whose expected behaviour is not documented, the prompt can require a clarification question instead of an invented expected result.
Examples guide behaviour; they do not supply missing truth
For the workflow in this article, the approved requirement remains the source of product truth. In one-shot and few-shot prompting, examples can guide the response pattern, but an example from another case is not evidence that the same product rule applies to the new requirement.
An example cannot make an incorrect or incomplete requirement correct.
The login requirement says nothing about whether an administrator can unlock the account. An administrator-unlock example might lead the model to suggest that feature, but the example would not prove that the product supports it. An authoritative product source or decision-maker would need to confirm the rule.
Keep clear instructions alongside your examples. Tell the AI:
- what task to perform;
- which information is authoritative; and
- what to do when information is missing.
The examples should demonstrate those instructions. Model behaviour is not guaranteed, but unclear guidance and unsuitable examples can increase the risk of an unintended response pattern, wrong assumption or irrelevant detail.
More examples are not automatically better. They make the prompt longer. For APIs that charge by input token, the additional input tokens can also increase cost, subject to the provider's pricing and any caching discounts.
A set of very similar examples does not demonstrate how to handle other situations. Research on particular language models and benchmark tasks has found that the choice and order of few-shot examples can affect results. The size of that effect is not established for every model and task.
Treat your examples as an important part of the prompt. Review them carefully instead of continuing to add more.
How should a QA team choose?
The following is a practical workflow to evaluate, not a universal rule:
- Start with zero-shot. Provide a real requirement and a clear task.
- Add one example when needed. Use an approved example if the AI repeatedly misses a required format or decision.
- Add a few varied examples for different situations. Include cases such as a stated rule, a missing rule and a boundary.
- Separate examples from the new input. Make it clear which content is demonstration and which item the AI must process.
- Test the prompt on separate requirements. Do not evaluate it only with the demonstrations used to create it.
Your evaluation set should include:
- a straightforward rule;
- an ambiguous rule;
- a boundary; and
- a case where asking a question is the correct response.
Compare each AI response with the actual requirement. Ask:
- Did it follow the expected format?
- Did it miss a risk?
- Did it invent an expected result?
- Did the examples improve the answer on new cases?
Keep additional examples only when they improve the result on these held-out cases according to your chosen criteria.
In the examples in this article, zero-shot gives instructions without a demonstration, one-shot adds one demonstration, and few-shot adds several.
For QA, the goal is not to create the longest prompt or include the most examples. The goal is to get an answer that follows the requirement, exposes uncertainty and helps the team make a sound testing decision.