CT-GenAI ISTQB Certified Tester Testing with Generative AI (CT-GenAI) v1.0 Questions and Answers

This scenario describes a failure in the model's ability to apply logical weight to specific domain concepts, specifically in the context of Risk-Based Testing (RBT). When an LLM ranks a low-impact UI element (a tooltip) higher than a critical functional failure (payment processing), it demonstrates a "Reasoning error in risk calculation logic." While LLMs can follow formulas like $Risk = Likelihood \times Impact$, they may lack the deep semantic understanding of "Impact" within a specific business domain unless explicitly guided. This is not necessarily a hallucination (Option C), as the model isn't necessarily inventing facts, but rather misapplying the logic of prioritization. It is also distinct from dataset bias (Option D), which would involve a systematic skewing across all outputs. In professional testing, this type of error highlights the necessity of "human-in-the-loop" verification. Testers must review AI-generated prioritizations to ensure that the logical deductions align with the actual business risk and technical criticality of the features being tested.

In the context of structured Generative AI capability building, a prompt pattern is a formalized method of interaction that ensures repeatability and reliability. Much like software design patterns, prompt patterns provide a reusable and structured template designed to guide Large Language Models (LLMs) toward producing specific, high-quality, and consistent outputs. Without these patterns, testers often rely on "zero-shot" or ad hoc prompting, which frequently leads to non-deterministic results that are difficult to validate in a professional testing lifecycle. By adopting prompt patterns, organizations can standardize how requirements are translated into test cases or how code is analyzed for defects. This standardization is critical for scaling GenAI across a team, as it allows for the creation of a "prompt library" where successful structures—such as Persona-based, Few-shot, or Chain-of-Thought patterns—are documented and reused. This approach moves the use of GenAI from a trial-and-error activity to a disciplined engineering practice, ensuring that the model understands the specific context, constraints, and expected output formats required for rigorous software testing tasks.

A successful Generative AI strategy for testing is heavily dependent on the quality of the data used for grounding (RAG) and prompting. The principle of "Garbage In, Garbage Out" is magnified with LLMs; therefore, a key strategic pillar is the prioritization of accurate, relevant, and high-quality input data. This involves establishing defined quality procedures to ensure that the requirements, codebases, and historical defect logs fed into the model are "clean" and representative of the current system state. Strategy must avoid the "unfiltered" approach (Option C), as including contradictory or obsolete data can lead to hallucinations or irrelevant test cases. While synthetic data (Option D) is a powerful tool for privacy, it cannot entirely replace the nuanced reality found in secured enterprise data. Furthermore, legacy data (Option A) often contains valuable insights for regression testing. Consequently, the strategy should focus on building a robust data pipeline that ensures only verified, contextually appropriate information is utilized, thereby increasing the reliability of AI-generated testware and ensuring it aligns with the organization's quality standards.

In the context of LLM inference,Temperatureis a hyperparameter that controls the randomness or "creativity" of the model's output. When the temperature is set high, the model's probability distribution is "flattened," meaning it is more likely to select less-probable tokens, leading to more diverse and sometimes unpredictable text. For software testing, where precision and repeatability are paramount,lowering the temperature(Option C) is the standard practice. A temperature of 0.0 makes the model "deterministic," meaning it will consistently choose the token with the highest probability. This narrows the sampling distribution and significantly reduces variability between runs. While a larger context window (Option D) allows the model to process more information, it does not directly control the randomness of token selection. Similarly, the "learning rate" (Option B) is a parameter used during thetrainingorfine-tuningphase, not during inference. For generating test cases or scripts that must follow strict logic, a lower temperature ensures that the model remains focused and produces consistent results.

The environmental impact and sustainability of AI are increasingly important considerations in software engineering. The overall energy consumption of an LLM during inference (when the model is actually being used by a tester) is most directly influenced by thenumber of tokens processed. Every token generated or analyzed requires a massive amount of floating-point operations within the GPU clusters of a data center. Therefore, the "length" of the input prompt and the "length" of the AI’s response are the primary drivers of the power draw and, consequently, the carbon intensity of the query. This is a crucial concept for "Green AI" initiatives in testing; more efficient prompting—such as avoiding unnecessarily verbose context or limiting output lengths—can lead to more sustainable testing practices. While data center location (Option B) affects thetypeof energy used (renewable vs. fossil fuel), it does not determine the model's accuracy. Similarly, while cloud platforms (Option D) and session durations (Option C) play roles in operational logistics, the mathematical workload tied to token count remains the fundamental unit of energy expenditure in Generative AI.

This scenario describes a specialized form ofData Exfiltration(specifically targeting the model's internal "weights" or training memory). While data exfiltration usually refers to stealing data from a database, in the context of LLMs, it can also refer to techniques that force the model to "reveal" sensitive information it was trained on or data that exists within its current context window. By using long, repetitive, or specifically "crafted" prompts to overwhelm the model's normal attention mechanisms or safety filters, an attacker may cause the model to output verbatim snippets of proprietary information, PII, or internal documentation that should have remained confidential. This is different fromRequest Manipulation(Option D), which aims to change the model's behavior, orData Poisoning(Option A), which happens during training. In testing, this risk is high when models are fine-tuned on private company repositories. Testers must be aware that if a model is accessible to unauthorized users, those users might use adversarial prompting techniques to extract sensitive code or business logic through these types of data leakage attacks.

Few-shot promptingis the technique of providing a few examples (exemplars) within the prompt to demonstrate the desired task and output format to the LLM. In this scenario, providing 10 existing, high-quality test cases acts as a "pattern" for the model to follow. This is significantly more effective than "Zero-shot prompting" (Option D), where the model is given a task without examples and may deviate from the specific organizational format required (e.g., specific JSON structures or assertion styles). While "Prompt chaining" (Option A) is useful for breaking down complex tasks into sub-tasks, the primary need here is pattern recognition and replication, which is the core strength of Few-shot learning. "Meta prompting" (Option C) involves having the AI write the prompt itself, which is unnecessary when the team already has clear examples. By using Few-shot prompting, the tester "conditions" the model's latent space to prioritize the provided format, ensuring that all 500 generated test cases maintain consistency with the HTTP methods, headers, and assertion logic defined in the exemplars.

Tokenizationis the foundational process by which an LLM breaks down raw text into smaller, manageable units called "tokens." These tokens can represent individual words, parts of words (sub-words), or even punctuation marks. This is a critical step because LLMs do not "read" words like humans do; they process numerical representations of these tokens. The way text is tokenized directly impacts the model's efficiency and its ability to understand complex technical terminology used in software testing. For example, a rare technical term might be broken into several sub-word tokens. This process is closely linked to theContext Window(Option C), which is the maximum number of tokens a model can "remember" or process at one time. WhileEmbeddings(Option B) are the numerical vectors that represent the meaning of these tokens, and theTransformer(Option A) is the underlying architecture that processes them, tokenization is the specific mechanism for initial text decomposition. Understanding tokenization is vital for testers when managing long requirement documents to ensure they do not exceed the model's limits.

In a structured prompt, "Input Data" (or Reference Data) provides the specific subject matter that the model must process or analyze. The statement provided consists of factual identifiers and specific entities related to the System Under Test (SUT), such as the version number, the specific module name, reference IDs for existing tests, and a specific defect record. These elements serve as the raw material for the LLM's task. This differs from "Instructions" (Option C), which would be the command (e.g., "Analyze the following..."), or "Constraints" (Option B), which would define the boundaries of the task (e.g., "Do not include T-115"). "Output Format" (Option D) would define how the result should look (e.g., "Provide a JSON list"). By clearly labeling this section as Input Data, the tester helps the model distinguish between the "what" (the data) and the "how" (the instructions), which is a key principle of structured prompt engineering aimed at improving the accuracy of AI-generated analysis.