A software tester asks a language model to derive boundary cases from a requirements document. Within seconds, the model produces a plausible suite and suggests automation code. Some cases are useful; others are redundant, misunderstand the business rule, or contain invented validation criteria. The apparent speed advantage is real only if the team can recognize the mistakes, protect information supplied to the tool, and turn the result into maintainable test assets. The ISTQB Certified Tester Testing with Generative AI (CT-GenAI) qualification focuses on precisely this challenge: applying generative AI effectively and responsibly across software testing activities.

ISTQB's CT-GenAI syllabus version 1.1 is current as of October 2026. The update refines terminology, hands-on objectives, evaluation descriptions, and risk-related explanations without changing the overall certification structure or learning objectives. The official examination information lists 40 questions, 46 possible points, a passing score of 30 points, and 60 minutes as the standard duration, subject to examination-provider policies and applicable extra-time rules. An ISTQB Certified Tester Foundation Level qualification is a prerequisite. Most importantly, CT-GenAI is about using generative AI to support the testing process; CT-AI instead concentrates on testing systems that themselves use AI and machine learning.

Understand what an LLM contributes to testing work

Large language models generate text from learned statistical patterns and contextual instructions. They can summarize a requirement, suggest edge cases, translate between test notation and programming languages, or explain code. None of these abilities guarantees that a produced test is correct. A model may infer plausible behavior that the system does not specify, omit an important exception, or present a familiar answer when the real requirement is unusual. Test professionals therefore need to distinguish assistance with drafting from independent validation of correctness.

The testing value of a generated artifact depends on what evidence it adds. A list of test cases that repeats the happy path in ten phrasings does not improve coverage. A smaller set that reveals contradictory requirements, role-specific authorization rules, and failed dependency behavior may have much greater value. The appropriate quality measures include defect detection, meaningful coverage, review effort, maintenance cost, and reproducibility, not simply the number of generated cases or tokens processed. A test team should resist measuring productivity in output volume alone.

Traditional testing concepts still govern. Equivalence partitioning groups inputs expected to behave similarly; boundary-value analysis explores limits; decision tables cover combinations of business conditions; state transitions capture permitted sequences; and exploratory testing draws on skilled observation. GenAI can help propose examples of each technique, but the tester must ensure that the model has identified the right rule and not invented one. Experience with ISTQB Certified Tester Foundation Level establishes the underlying vocabulary and judgment on which useful prompting depends.

Use the model for tasks it can support safely. A tester might ask it to transform a written requirement into a candidate decision table, summarize failure logs for investigation, or suggest missing negative tests from a sanitized interface specification. Less appropriate uses include accepting a generated expected result without evidence or asking an unapproved third-party service to process confidential customer records. The same feature that makes an LLM convenient—its ability to generate a convincing answer from incomplete context—also makes independent review essential.

Engineer prompts around evidence and task boundaries

Effective prompting begins with a clear task, relevant context, acceptable output structure, and constraints. Rather than asking, “Write tests for checkout,” specify the order states, tax and currency rules, known exclusions, required user roles, and the test-design technique to apply. Tell the model to separate explicit requirements from assumptions and to flag missing rules instead of making them up. A structured output such as a decision table or named test case with setup, action, expected observation, and traceable requirement often makes reviewing easier than a free-form narrative.

Examples improve prompts when they clarify the intended pattern, but examples also risk anchoring the model too narrowly. A carefully selected example should show the desired format and reasoning granularity without dictating all substantive conclusions. Ask for alternative scenarios and contradictions where appropriate. For a payment API, the model should consider rejected authorization, retry behavior, duplicate requests, idempotency keys, and timeouts only when these are applicable to the actual system. When such requirements are unknown, an explicit question or assumption register is better than confidently invented coverage.

Prompt iteration should be empirical. Save the initial instructions, a representative set of tasks, model configuration, and evaluation criteria. Compare new prompts on the same examples and review how outputs change. A prompt that works on one polished user story may fail on a poorly specified legacy change request. Likewise, a model change can invalidate assumptions about output formatting. Teams should treat important prompts as managed testing assets, with versioning and a rationale for modifications, rather than rely on a practitioner's private collection of unreviewed shortcuts.

The boundary between instructions and task data matters. A bug report, retrieved specification, or repository comment is not necessarily trustworthy simply because the model is reading it. An attacker might place an instruction in a test input that attempts to redirect the assistant, disclose secrets, or alter the generated test expectations. Where an LLM can use tools or execute code, isolate privileges and require confirmation for consequential actions. The discussion of prompt injection and LLM application security provides a useful security context for responsible prompt design.

Apply GenAI to requirements, test design, and exploratory work

Requirements analysis is a strong candidate for assisted work because testers frequently receive ambiguous, lengthy, or contradictory material. An LLM can extract apparent business rules, identify undefined terms, and produce clarification questions. It should not silently decide which interpretation is correct. For example, the phrase “customers may change an order until shipment” leaves open whether a label being printed counts as shipment, how concurrent updates behave, and whether special-order items are excluded. A generated checklist can help reveal these gaps before automation makes the ambiguity harder to fix.

When deriving test cases, insist on traceability. Each case should link to an actual requirement, risk, acceptance criterion, or consciously justified exploratory question. The model may propose cases that sound sensible but belong to a different product. Reviewing the source-to-test relationship prevents a polished output from being mistaken for genuine coverage. For complex permissions, compare the proposed matrix with role definitions and exception rules. For numeric calculations, independently compute expected values using an authoritative reference or business-owned example.

Exploratory testing benefits when generative AI acts as a hypothesis partner rather than a remote test oracle. A tester investigating a search service can ask for failure modes involving synonyms, multilingual queries, stale indexes, and access restrictions. The human then selects hypotheses based on architecture and observed system behavior. The model's suggestions are useful only insofar as they stimulate evidence-seeking experiments. It cannot observe the product's real environment unless intentionally supplied trustworthy observations, and even then it may misinterpret them.

Testing documentation and reporting also offer opportunities. GenAI can condense a long defect chronology, draft a reproduction description from sanitized notes, or group recurring failure symptoms. The output must distinguish observed facts from interpretations. A report claiming that a root cause is confirmed when logs merely suggest it can lead an engineering team in the wrong direction. Preserve raw evidence and original references so reviewers can reconstruct what happened. Summaries are especially dangerous when omitted details affect severity, reproducibility, or regulatory reporting obligations.

Use automation support without surrendering maintainability

Generated test automation can accelerate the creation of repetitive fixtures, assertions, or examples for known libraries. But code generation needs the same controls as human-authored code: review, formatting, dependency checks, credential hygiene, static analysis where appropriate, and execution against a controlled environment. An LLM might reference a nonexistent API, use an outdated library pattern, introduce brittle selectors, or write assertions that always pass. A syntactically valid script is not proof that the right behavior is being tested.

Ask the model to explain intended assertions and distinguish setup from verification. If a generated browser test checks only that a page loads, it does not establish that a refund workflow preserves monetary totals. If the expected value is constructed using the same flawed function as the system under test, a common defect may escape detection. Maintain independent oracles, known-good fixtures, and review of boundary conditions. In UI automation, prefer stable semantic locators over incidental layout details where the test framework supports them.

Large test suites also require design judgment. Generating hundreds of closely related scripts may increase runtime and maintenance cost without increasing meaningful coverage. Review flakiness, fixture coupling, environment assumptions, shared state, and how failures will be diagnosed. When a model suggests repairing a failing test by weakening its assertion, investigate the underlying failure first. Automation is a source of executable evidence, not a mechanism for making dashboards green by hiding disagreements between expected and observed behavior.

Integrate assistants into delivery pipelines cautiously. A system that drafts test code for human approval presents a different risk than an autonomous agent that edits repositories, accesses production-like data, and deploys changes. Evaluate permission scope, audit logging, human gates, rollback capability, and cost before granting tool access. Testing an AI-powered assistant as a product requires additional methods, as explained in CT-AI, but applying GenAI inside a testing organization always creates its own security and governance obligations.

Evaluate results, risk, and organizational impact

CT-GenAI places emphasis on evaluating model output and refining prompts. Begin with a representative task set rather than a spectacular demonstration. Include clear requirements, ambiguous requirements, legacy code, security-sensitive workflows, and tasks where the correct answer is that information is missing. Review generated artifacts for correctness, relevance, traceability, omissions, hallucinations, maintainability, and effort to fix. An assistant that saves two minutes of drafting but adds twenty minutes of verification is not an efficiency improvement for that task.

Human evaluation should be consistent enough to compare trials. Define review rubrics, train reviewers on what constitutes an error, and inspect disagreement among reviewers. Some measures are quantitative—valid syntax, execution success, coverage of explicitly enumerated decision-table rules—while others depend on professional judgment. Avoid scoring a candidate test solely by how confident or articulate the model sounds. If a model judges another model's output, calibrate the judge on a smaller set of well-reviewed examples and track where it is unreliable. The approved resource on evaluating AI agents before production illustrates why attractive demonstrations are not sufficient acceptance evidence.

Risk assessment includes hallucination, biased suggestions, intellectual-property concerns, data privacy, prompt injection, weak auditability, and the environmental costs associated with model use. Map risks to the concrete workflow. Passing an anonymized schema to an approved internal tool is not equivalent to sending a customer's medical history to an unknown public service. Define which data may leave organizational boundaries, what retention applies, whether supplied code might contain secrets, and which outputs require independent approval. Policies should be simple enough that practitioners can follow them during real testing work.

Organizations also need a sustainable operating model. Determine tool ownership, approved models, prompt and artifact repositories, cost controls, training, metrics, incident reporting, and a change process for upgrades. Investigate the risk that testers over-rely on generated outputs and lose fluency with basic test-design techniques. Teams should build skills in evaluating evidence, asking sharp questions, and debugging model suggestions rather than merely learning a few popular prompt formulas. Adoption succeeds when it improves the quality of decisions and reduces avoidable work without weakening accountability.

Apply CT-GenAI thinking to a release decision

Imagine a billing platform preparing to support partial refunds. A tester asks an approved assistant to generate a decision table from the user story and test code for a REST API. The model proposes cases for full refunds, single partial refunds, and duplicate refund attempts, but omits concurrent refund requests. It also assumes the platform returns a specific status code not stated in the contract. A competent CT-GenAI practitioner flags the unsupported status-code assumption, adds concurrency questions, verifies refund ceilings against the authoritative policy, and uses generated code only after technical review.

The team then evaluates whether GenAI actually helped. It records time spent drafting, reviewing, and correcting the generated cases; detects whether important coverage was added; and checks for new maintenance burden. The prompt and model version are kept with the artifact so the experiment can be reproduced. When a later model upgrade generates a different set, testers can compare the outputs against the same requirements and human-approved expectations. This is more credible than claiming success because a model produced thirty test cases in ten seconds.

For exam preparation, read the official version 1.1 syllabus closely and practice writing task-specific prompts, reviewing weak outputs, and selecting proportionate mitigations. Know the distinction among hallucination, biased output, privacy risk, and security exploitation; understand where LLM-powered assistants, retrieval, fine-tuning, and LLMOps fit at a conceptual level. Be prepared to explain why a human verification gate is necessary and what its reviewers must inspect. The certification does not replace the principles of software testing or promise that a particular AI tool will remain effective. It develops the professional judgment to use changing tools while keeping test evidence, product quality, and organizational responsibility in view.