Free CT-GenAI practice test: 30 questions with answers

Hallucination means the model produces fluent but unsupported output, such as a requirement ID it has invented. Overfitting would show up as memorised training text, data drift is a change in live inputs over time, and poisoning needs deliberate tampering, for which the scenario gives no evidence.

The context window is the maximum number of tokens the model can consider in one request, covering prompt and output together. Temperature controls randomness, learning rate applies during training, and embedding size describes the vector representation of a token, so none of them sets the limit on input length.

GenAI is a support tool, and testers remain accountable for what enters the test suite, so AI-generated artefacts need human review. Detailed prompts, benchmark scores and speed do not remove that need, because the output can still be wrong for the specific system under test.

A token is the unit of text, which may be a whole word, part of a word or a punctuation mark, that the model reads and generates. The other options describe a stored test asset, a credential and a run limit, none of which is what a token is.

Treating output as a draft to verify and starting with bounded tasks that have measurable results are core principles for GenAI support in testing. Putting confidential data into prompts, trusting fluent answers and replacing exploratory testing all run against those principles.

An LLM is a neural network trained on very large amounts of text to predict and generate language. A keyword engine, a test case database and a fixed regression script each lack the generative, language-modelling behaviour that defines an LLM.

Stating scope, output format and constraints gives the model what it needs to produce targeted, consistent tests. A higher temperature adds randomness rather than specificity, a large pasted suite can dilute focus or exceed the context window, and a fresh session with the same vague request will usually return the same vague result.

Few-shot prompting places example input-output pairs in the prompt so the model can follow the pattern. Zero-shot gives no examples, fine-tuning changes model weights rather than the prompt, and retrieval augmentation adds documents rather than demonstrations.

Chain-of-thought prompting asks the model to work through intermediate steps before giving its conclusion, which often helps with multi-factor reasoning. Role prompting sets a persona, temperature tuning controls randomness, and output filtering removes responses after generation, so none of them describes this request.

Checking each draft against the requirements and logging rejections gives real evidence of quality. Counting cases, checking formatting and a single passing run do not show that the cases are correct or cover the requirements.

Versioning prompts and comparing their outputs against a fixed reference set makes improvement measurable and repeatable. Discarding prompts, rewriting from scratch and assuming longer prompts are always better each skip that measurement.

The valid range and boundary values tell the model exactly what to test, and a defined output format keeps the cases consistent and easy to review. Dataset names, skipped expected results and a full defect history are either unnecessary for the task or harmful to it.

The output consistently reflects one narrow set of assumptions, which is the signature of bias inherited from training data or prompts. Energy use, privacy leakage and regulatory gaps are different risks, and the scenario does not describe them.

Grounding answers in verified sources and checking them against those sources is the most direct way to catch invented figures. A higher temperature increases randomness, removing the requirements leaves the model with less to work from, and a stated confidence level is not evidence of accuracy.

Anonymising personal data before prompting and reviewing how the provider retains and uses submitted data both limit exposure. Pasting production exports, sharing API keys and disabling access logs all raise privacy or security risk, and removing logs also removes the audit trail.

Matching model size to task complexity reduces the compute, and therefore the energy, spent per useful result. Running the largest model on everything, regenerating unchanged suites and disabling caching all increase compute without a matching benefit.

The EU AI Act takes a risk-based approach and groups AI systems into categories that include unacceptable, high, limited and minimal risk. GDPR covers personal data, ISO 9001 covers quality management, and the ISTQB glossary defines testing terms, so none of them sets AI risk tiers.

Prompt injection embeds instructions in content the model processes so that it departs from the intended task, here to report tests as passed falsely. Energy use, automation bias and model drift are real risks, but none of them describes a document that carries hidden instructions.

Retrieval-augmented generation pulls the latest standards into the prompt at query time, so changes take effect without retraining. Annual fine-tuning would lag behind monthly changes, training from scratch is impractical, and built-in knowledge cannot contain the company's newest standards.

Fine-tuning continues training on task-specific examples and updates the model's weights, which changes its behaviour. Supplying documents at query time describes retrieval, increasing the context window is a separate capability, and storing every exchange for exact lookup is not what fine-tuning does.

LLMOps covers versioning, monitoring and evaluating models and prompts across their lifecycle, so that changes can be traced and quality tracked. Freezing a version so it can never be reviewed and deleting interaction logs both remove the control and traceability that LLMOps exists to provide.

Fine-tuning quality depends on having enough representative examples, and those examples must not expose sensitive data. Fine-tuning does not remove the need for review, and training schedules or report branding are not the first things to check.

An agent uses tool calls inside a loop, reading results and deciding the next action. A static template, a single-purpose classifier and a one-off export each lack that decision loop with tool use.

Prompt-only designs send all the needed context inside each request to a hosted model, with no retrieval or tuning. A knowledge graph, a rules engine and pre-training each add a separate component or training step that the scenario does not describe.

A bounded pilot with measured results produces evidence for deciding on wider adoption. A full rollout, replacing a framework before any evaluation, or a volume target all commit resources before anyone knows whether the tool helps.

Explaining how the work will change and involving people in the pilot addresses the concern directly and builds ownership. Hiding the pilot, relying on a single expert, or making adoption mandatory with penalties all undermine trust and learning.

Comparing measured results with an agreed baseline shows whether GenAI use actually improved testing. Prompt counts and stored case totals measure activity rather than value, and an absence of complaints does not show that the results were good.

Mandatory review points and traceable records of model version and prompt keep AI output controlled and auditable. Write access to production databases, skipping review gates and undocumented prompts each remove the control that safe integration depends on.

A staged rollout that starts with the most ready team lets the organisation learn from real use and pass on what works. An identical rollout ignores maturity differences, waiting for equal maturity delays any value, and giving the newest team the hardest work sets it up to struggle.

An acceptable-use policy sets which tools are approved and what kinds of data may be entered into prompts, which directly addresses the data-control concern. A marketing brief, a retrospective template and a speed list do not set rules for tool use or data handling.