CT-GenAI: Prompt Structure, Prompting Techniques and System vs User Prompts

A structured prompt is a prompt built from six named components (role, context, instruction, input data, constraints and output format) so that the model receives everything it needs to do a test task, stated clearly and in the right place. The CT-GenAI syllabus treats this structure as the basis of effective prompt development: each component adds clarity and precision, and together they communicate the tester's requirements and expectations to the LLM.

Structure alone is not the whole method. The syllabus says the six-component structure should be combined with prompting techniques (prompt chaining, few-shot prompting and meta prompting), chosen according to the task and the LLM in use. In a chatbot or assistant, the components can also be split between a system prompt that stays fixed and the user prompt that changes with each request. This lesson covers all three parts of syllabus section 2.1.

The payoff is practical. When an LLM returns generic, off-target or badly shaped output, the cause is usually a missing or weak component. Knowing what each component does lets you diagnose the problem and add the right thing, instead of rewriting the whole prompt at random.

Each of the six components answers a different question the model would otherwise have to guess. The table summarises them with a test-design example of each.

Not every prompt needs a long line for each component, but a prompt that leaves one out leaves that decision to the model. The sections below show how to tell the near-twin components apart, because that is where most mistakes happen.

The role tells the model whose perspective to take; the context tells it what situation it is working in. They are easy to confuse because both come early in a prompt, but they fix different problems.

• Role examples from the syllabus are a tester, a test manager or a test automation engineer. A role changes what the model pays attention to: its responsibilities, tone and approach. Suppose a team asks for feedback on a set of automated UI test scripts and the answer comments only on the business wording of the steps. The perspective is what needs to change, so the prompt gains a role such as "a test automation engineer who maintains large UI suites", and the feedback turns to maintainability, flaky waits and duplicated locators.
• Context describes the test object and its circumstances: what the product is, who uses it, under which conditions, what this release changes. Suppose generated tests for a museum's ticket kiosk assume a keyboard and a signed-in user, when the kiosk has only a touch screen and serves walk-up visitors. Those are facts about the product and its operating conditions, so they belong in the context. Facts like these reach the model only when the prompt states them.

A quick test: a sentence about who the model should be is role; a sentence about the product, its users or the release is context.

The instruction is the task; input data is what the task is performed on; constraints limit how the task is applied to that data.

Instruction

The syllabus asks for instructions that are clear, imperative and concise and that include the task description and any relevant requirements. A request such as "Have a think about these requirements" names no task, so the model has to guess what to deliver. "List the boundary values of every numeric field in the requirement below, with the expected result at each" states the task and its requirements in one imperative sentence.

Input data

Input data is any information needed to perform the task: user stories, acceptance criteria, screenshots, code, existing test cases or output examples. The syllabus stresses that detailed, structured input data produces more accurate, context-aware results. Specific business rules are a good illustration. If a loyalty scheme caps the points earned per order and lets unused points lapse after a set period, test cases can check those rules only when the model can read them, so the requirement or acceptance criteria that state them go into the prompt as input data.

Context versus input data is the most common confusion. Context describes the product and situation in the prompt writer's own words; input data is the material itself: the attached story, the screenshots, the OpenAPI excerpt, existing test cases.

Constraints

Constraints are restrictions or special considerations: scope limits ("cover the search filters only", "apply boundary value analysis to the quantity field only"), exclusions ("leave the admin pages out"), and rules about which sources to rely on ("base every expected result on the attached requirement"). The distinction from the instruction is that a constraint does not name a new task; it narrows how the stated task is carried out.

Constraints also let you keep useful input data while controlling how it is used. Screenshots from a staging system might show real employee email addresses, yet the team wants them in the prompt so the model sees the exact screen layout. A constraint such as "mask every email address in your output and test the profile-settings screen only" keeps the layout information and sets the rules for how it is used.

The output format component specifies the format, structure or characteristics of the response, so the result can be used without reworking. Typical examples in testing are a table with named columns, a numbered list with one condition per line, Given/When/Then scenarios, or CSV with defined columns for import into a test management tool.

Tell output format apart from its neighbours by asking what the line controls:

• "Write each scenario in Given/When/Then form, one scenario per block" controls the shape of the answer: output format.
• "Design scenarios for the feature that exports Gherkin files" names a task that happens to mention a format: instruction.
• "Leave out scenarios for the administrator role" restricts scope: constraint.

Output format fixes presentation problems. It does not fix a wrong perspective, missing domain knowledge or missing rules; those need role, context or input data.

To identify the components of a prompt, classify each line by the job it does, not by where it sits or which words it uses. The syllabus hands-on objective HO-2.1.1 is exactly this: read a structured prompt and see how each component contributes.

1 You are a tester who specialises in mobile accessibility.
2 The app lets gym members book classes; v3 adds voice control.
3 Identify test conditions for booking a class by voice.
4 <requirement REQ-41 and its acceptance criteria>
5 Ignore the web version of the timetable.
6 Group the conditions under the headings Happy path and Errors.

Line 1 is the role; line 2 is context (background on the product and the release, in the writer's words); line 3 the instruction; line 4 input data; line 5 a constraint (it limits how the instruction uses the input); line 6 the output format.

Two habits help:

• Check for what is missing. Run through all six components and ask which one has no line. If the prompt above stopped after line 5, it would have no output format, and the model would choose the layout itself. Spotting the absent component is as important as labelling the present ones.
• Treat a worked example as input data. A line such as Input: quantity=0 → Expected: "Enter at least 1" shows the expected result for an input. The syllabus lists output examples under input data, and a prompt with exactly one such example is one-shot prompting. A line that tells the model how to lay out all of its answers, such as "Follow this pattern for each case", is the output format.

Prompt chaining breaks a task into a series of intermediate steps, each its own prompt, and checks and refines the result of each step (manually or automatically) before moving to the next. Because each checked response feeds the next prompt, errors are caught where they arise instead of flowing silently into the final output, which gives greater accuracy.

The syllabus says chaining is particularly useful when test tasks are complicated and need decomposition into subtasks with systematic checking of intermediate outputs, and that it allows dynamic interaction in test processes. A chain for risk-based testing of a new feature might look like this:

1. Ask for the product risks the release notes suggest; review the list and remove any that do not apply.
2. Ask the model to rate the remaining risks by likelihood and impact; adjust the ratings.
3. Ask for test cases that cover the highest-rated risks.

The checkpoints are the point of the technique. Each one gives the tester a small, reviewable result, so a mistake is corrected at the step where it appeared, and the final output rests on intermediate results that someone has already approved. A single prompt that asks for the whole job at once has no such checkpoints, which is why large or multi-stage test tasks are where chaining pays off.

Chaining fits multi-step work; for keeping output in a particular style, examples are the tool (next section).

Few-shot prompting means putting examples of the expected result in the prompt. The syllabus defines the three levels by the number of examples:

Examples give the model a clear reference, which makes results consistent and in line with expectations. Few-shot prompting is most effective where examples can illustrate the required behaviour better than a description can, so the model generalises from them. A team's defect report style is a good case: a summary line built a particular way, numbered reproduction steps and a fixed set of fields are easier to show than to describe, so a few completed reports in that style show the model exactly what to produce.

Two cautions follow from how examples work:

• Vary the examples. This is good practice rather than syllabus text: a model tends to copy whatever its examples have in common. If every example booking in a prompt is for a single traveller paying in euros, generated bookings may all look the same. Examples that span the valid range of each field (group bookings, other currencies) keep the format guidance and widen the output.
• Count carefully. One example plus a new input to process is one-shot, not few-shot. Two or more is few-shot.

Meta prompting uses the LLM's ability to generate or refine prompts. In an iterative cycle, the LLM generates a prompt, the tester evaluates and refines it, and the improved prompt is then used for the actual test task. It takes advantage of the model's knowledge of what makes prompts effective.

The syllabus names two benefits:

• Efficiency and prompt optimisation. Meta prompting is especially useful when efficiency and prompt optimisation are critical, because it reduces the manual effort required to design effective prompts. A team that needs well-built prompts quickly can have the LLM draft them and spend its own time reviewing them.
• Help when you are unsure. A tester who does not know how to craft an effective prompt can co-create it with the LLM. The syllabus calls this a form of pairing with the GenAI tool: the tester and the AI work together interactively towards a shared goal. The syllabus adds that this way of collaborating with AI tools enhances productivity and learning in prompt engineering, and also in pair programming and pair testing.

The human stays in charge: the LLM drafts, the tester evaluates and decides. The syllabus's summary table describes meta prompting as suited to flexible, dynamic tasks and to crafting prompts for new tasks.

The three techniques solve different problems, and the fastest way to identify one in an example is to ask what each round produces.

Chaining and meta prompting both run over several rounds with a tester checking in between. Look at what the tester is reviewing: in chaining it is part of the testing work (risks, conditions, test cases); in meta prompting it is the wording of a prompt that will be used later.

The syllabus says the techniques can be used in combination, and the hands-on objective HO-2.1.2b asks you to identify every technique in a given example. For example, a tester might have the LLM draft a prompt for writing Gherkin scenarios and polish it (meta prompting), add three finished scenarios from an earlier project to that prompt (few-shot), and then run it one user story at a time, reviewing each set of scenarios before moving to the next story (chaining). Read each part of the scenario separately and name the technique for each; then check the example count to choose between one-shot and few-shot. Choosing techniques for specific test tasks such as test design or regression automation is covered in the next lesson of this chapter.

A system prompt is a predefined set of instructions, typically written by the developer or tester who sets up the assistant, that defines the LLM's behaviour, personality and operational parameters for the whole conversation. A user prompt is the chatbot user's actual input or question, and it changes with each interaction.

Operational parameters determine how the model responds: a formal tone, concise answers, respecting domain-specific rules, avoiding certain behaviour. The syllabus example is a system prompt telling the model it is a professional software testing assistant that answers clearly and formally, follows ISTQB-aligned practices, avoids speculation and cites testing principles. "List the key differences between black-box and white-box testing" is a user prompt: a one-off task.

When splitting content, put what must apply to every request in the system prompt (the role, the organisation's naming convention for test cases, a rule to flag every assumption, a concise style) and what changes per request in the user prompt (this sprint's requirement, the specific task, an attached screenshot). Content placed in the system prompt applies to every later request, so it should hold only what is meant to apply everywhere; standing rules kept there are stated once and stay consistent.

How the model uses both prompts together

For every response, the LLM considers the unchanging system prompt together with the current user prompt. The system prompt sets the rules for the entire conversation, so it applies to the first request and to every later one; the user prompt is the part that changes from turn to turn.

That has two practical consequences:

• A good system prompt does not excuse a vague user prompt. The syllabus requires user prompts to be focused and well structured, with explicit instructions plus relevant context and output format instructions. A system prompt can set the role and the general rules, but only the user prompt can say what this request is about. For a search feature, a focused user prompt names the task (for example, test conditions for the filter combinations), includes the relevant requirement and says how the result should be laid out.
• Per-request needs go in the user prompt. The chatbot's user usually cannot see or edit the system prompt, and should not try to change it for a one-off need. When a single request needs something different from the usual output, for example a numbered checklist where the assistant normally writes prose, the user prompt is the place to say so, explicitly, for that request.