Prompt Engineering for Effective Software Testing practice questions

Constraints outline restrictions or special considerations the LLM must respect, and they specify how the instruction is applied to the input data.

The line forbids a kind of test data and narrows the scope to one flow. Both are restrictions on how the task is performed, which the syllabus calls constraints. It is not the instruction, because it does not name the task; it is not context, because it gives no background on the system; and it is not output format, because it does not describe the response's structure.

1. Identify what the line does: it limits what the model may produce.
2. Restrictions and special considerations map to the constraints component.
3. Rule out instruction (the task), context (background) and output format (structure).

Exam tip: Limits on scope, data or behaviour = constraints.

The output format component denotes the expected format, structure or characteristics of the response.

Each option is one of the six components. Only the table line describes how the answer must be structured, so it is the output format. The scope limit is a constraint, the derive-from-criteria line is the instruction, and the specialist persona is the role. Testers often confuse output format with constraints because both shape the response; the difference is that output format concerns layout and structure, while constraints concern what is allowed.

1. Classify each line by its job: persona, task, restriction or response structure.
2. Pick the line that describes the shape of the answer (table, columns).
3. Separate it from the scope restriction, which is a constraint.

Exam tip: How the answer looks (table, JSON, Gherkin, columns) = output format.

Input data includes any information needed to perform the task: user stories, acceptance criteria, screenshots, code, existing test cases or output examples.

The pasted user story and acceptance criteria are the material the model must process, which the syllabus defines as input data. The product description is the most tempting distractor: it is also information, but it is general background about the test object, which is context. The Gherkin request is output format and the positive-only rule is a constraint.

1. Ask whether the item is the material the task operates on, or information around the task.
2. Test basis artefacts (user stories, acceptance criteria, screenshots, code) are input data.
3. General background about the system is context, not input data.

Exam tip: Context = background about the test object; input data = the artefacts the task works on.

Detailed, structured input data (user stories, acceptance criteria) helps the LLM produce accurate, context-aware results; missing input data leads to generic output.

The prompt has a role, an instruction and an output format, but no input data: the model has never seen the rules it is ignoring, so it falls back on generic knowledge of password resets. The fix is to supply the test basis that contains those rules. Adding context is the tempting near-miss: it is useful background, but describing the shop's customers and stack does not contain the expiry or retry rules. A sharper role or a size constraint changes how the model answers, not what it knows.

1. List the components already in the prompt: role, instruction, output format.
2. Identify what the output lacks: specific rules from the requirements.
3. Ask which missing component would carry those rules: the test basis as input data.
4. Reject changes that alter persona, background or size without adding the rules.

Exam tip: If the output ignores specific requirements, the model probably never received them: supply the test basis as input data.

Instructions are the directives that state the task to perform; they should be clear, imperative and concise, with a task description and relevant requirements.

Each distractor is the definition of another component: background is context, persona and tone is role, restrictions on applying the task are constraints. Only the instruction is defined as the imperative statement of the task itself.

1. Recall the job of the instruction: say what task to do.
2. Match the remaining descriptions to context, role and constraints.
3. Choose the description that is about stating the task.

Exam tip: Instruction = the task, stated clearly, imperatively and concisely.

Context provides background about the test object, the functionality to be tested and other relevant information.

Describing what the system is and what the release changes is background for the model, which the syllabus calls context. Input data would be the actual test basis, for example the SMS reminder user story. No persona or task is stated, so role and instruction do not fit.

1. Note that the sentence describes the system and the change in this release.
2. Background about the test object and its functionality is context.
3. Check that no artefact, persona or task is supplied.

Exam tip: Context answers "what are we testing and why does it matter?"