ISTQB CT-GenAI: Practical AI-Assisted Testing

An assistant can draft test cases, explain unfamiliar code or summarize a defect report in seconds. That convenience creates a new risk: a fluent response can sound authoritative while overlooking the exact condition that matters. ISTQB's Certified Tester Testing with Generative AI (CT-GenAI) treats these systems as powerful but fallible aids to the software testing process. The tester remains accountable for correctness, confidentiality and whether the suggested work actually reveals a product risk.

The official CT-GenAI qualification requires an ISTQB Foundation Level certificate and uses a published specialist syllabus. Version 1.1 is a minor clarification update rather than a new domain structure. Confirm the version and examination details with the relevant board before scheduling. Its central subject differs from CT-AI, which studies how to test AI-based systems: CT-GenAI examines how generative tools change the way testers plan, design, execute, analyze and communicate testing. Studying it well means scrutinizing both productivity gains and the failure modes introduced by probabilistic text and code generation.

Recognize the strengths and limitations of generative models

A large language model predicts plausible sequences based on learned patterns and the supplied context. It may help organize ambiguous requirements or produce candidate inputs, but its confidence and fluency are not reliable measures of factual correctness. It can invent API functions, misunderstand domain terms, omit negative scenarios or create code that looks valid while violating test intent. Responses may vary across runs and model versions. Testers need a working understanding of prompts, context windows, model limitations and output validation to keep a tool-assisted workflow accountable.

Consider asking a model to test a payment refund feature. It may generate a neat list of happy-path cases while ignoring duplicate requests, partial refunds, reconciliation timing, currency precision and concurrent account adjustments. The missing cases are often more valuable than the polished ones. The tester should provide an explicit domain model, ask for competing risks and independently review suggestions against requirements and implementation behavior. A useful AI output is a hypothesis or draft, not an oracle. Its value depends on the verification work that follows.

Decide when AI assistance is suitable for a task

Not every testing activity benefits equally from generative assistance. It can be effective for brainstorming equivalence classes, proposing exploratory charters, explaining unfamiliar logs or rewriting dense notes into clearer stakeholder language. It is less reliable when a task needs complete coverage guarantees, authoritative compliance interpretation or deterministic calculation without external checks. Selection should account for risk, data sensitivity, repeatability, cost, tool access and whether the result can be verified independently. Automating an unsuitable task may simply produce incorrect artifacts more quickly.

Take a system migration with thousands of field mappings. A model can propose checks for missing values, boundary lengths and transformation errors. It should not be trusted to assert that every mapping has been inspected unless evidence exists. The team can instead use deterministic reconciliation to compare record counts and values, while using generative assistance to interpret anomalies and draft investigation paths. Human review remains necessary where errors carry financial or safety consequences. Record where AI contributed, which outputs were adopted, and which checks established their validity.

Write prompts that preserve testing context

Useful prompting begins with the testing objective, constraints and source evidence. State the feature's intended behavior, audience, relevant states, data types, known risks and desired form of output. Ask for assumptions and uncertain areas to be identified explicitly. Separate quoted requirements from instructions to the assistant and avoid asking it to invent missing business rules. Iterative prompting can expose gaps, but an elaborate prompt is not a substitute for understanding the system. A reviewer must evaluate the result as carefully as one prepared by another human tester.

Suppose a scheduling system calculates eligibility by age and residency. Instead of saying “give me edge cases,” supply the exact thresholds and time-zone rule, then ask for cases that cross those boundaries. Insist that the model distinguish requirements from inferred behaviors, and verify each expectation against the approved specification. Where the specification is silent, turn uncertainty into a clarification for the product owner. Track prompts and model versions for significant generated artifacts so they can be reproduced or challenged. Uncontrolled conversation history can contaminate later outputs with outdated assumptions.

Generate better tests without losing coverage discipline

AI can suggest test cases from requirements, user journeys or source code, but coverage must be evaluated with established testing techniques. Apply equivalence partitioning, boundary value analysis, decision tables, state transitions and risk-based prioritization as appropriate. A long generated list is not proof of high coverage: the cases may cluster around easy examples while missing difficult combinations. Use the ISTQB Foundation Level as a reference framework for assessing whether suggested cases exercise meaningful conditions and produce observable outcomes.

For an online order, ask the model to identify states such as authorized, captured, partially refunded, canceled and disputed. Then draw the transition model yourself and verify which moves are allowed, forbidden or conditional. Check that generated tests include both valid transitions and attempts to perform invalid ones. Ensure every test has a verifiable expected result rather than a vague “should work.” Evaluate whether cases overlap so much that executing them adds little new evidence. Generative assistance should improve the quality and reach of the design, not replace traceability to product behavior.

Use AI for debugging while maintaining evidence integrity

A model can summarize logs, suggest suspicious patterns and propose likely causes of a test failure. It may also overfit the first visible clue and ignore timing, environment or dependency failures. Debugging should therefore distinguish observation from inference. Preserve original logs, exact input data, software version and reproducible steps. An AI-generated explanation is useful only when a human or an automated experiment can test it. Avoid pasting secrets, production personal data or proprietary code into tools without approved data-handling arrangements.

Suppose checkout tests intermittently fail after a network change. The assistant may blame an expired token because one error message mentions authentication. Compare trace identifiers and event timing to verify whether the token really expired before failure or whether retries triggered a rate limit. Test competing hypotheses, not just the model's favorite. When generating diagnostic scripts, inspect commands for destructive behavior, unsafe logging or overbroad credentials before execution. A concise, evidence-based defect report should retain observed steps and environment details even if AI helps improve its wording.

Protect data, intellectual property and security boundaries

Generative tools introduce information-handling questions. A prompt may contain customer data, credentials, source code or vulnerability details; the service's retention and access policies may not match the organization's requirements. Understand permitted environments, redaction standards, access controls and vendor-specific agreements before using a tool. Models can also reproduce sensitive fragments, generate insecure code or be steered through malicious instructions embedded in files they process. Treat retrieved documents and repository comments as untrusted context where appropriate.

For a regulated medical application, anonymizing names may not remove all re-identification risk if case descriptions include distinctive details. Use approved synthetic datasets, minimize context and document the authorization to process sensitive information. Evaluate suggested unit-test code for uncontrolled filesystem access and whether generated fixtures accidentally copy real records. Security review is part of the testing workflow, not an optional later scan. If a tool's data-handling properties cannot meet the project's constraints, use an alternative or do the work without the model. Convenience does not override an explicit confidentiality obligation.

Measure benefits against defects and hidden review cost

Teams often measure how fast a model drafts tests but ignore the effort spent correcting them. A better evaluation includes useful defect detection, coverage of important risks, false expectations, time to verify outputs, maintenance costs and reproducibility. Compare assisted and unassisted workflows on representative tasks rather than using one unusually successful demonstration. A prompt that creates thirty cases in a minute may be slower overall if half are duplicates and the rest require careful repair. The same productivity claim may differ by team experience and domain complexity.

Run a controlled trial using several known features. Record preparation time, meaningful defects found, correction effort and any confidential data-handling issues. Examine whether less experienced testers become overly reliant on confident AI suggestions, and whether experienced reviewers can explain rejected cases. Use results to define appropriate guardrails: permitted tasks, review levels, logging, training and escalation. The goal is neither to reject AI assistance nor to declare it inherently superior. The goal is to improve credible testing outcomes with evidence that the process remains under professional control.

Practice accountability from prompt to release decision

Prepare by writing prompts for a stateful application, reviewing generated cases with formal techniques and running them against a small test system. Deliberately include an ambiguous requirement, a confidential datum and an outdated API description; identify the points at which the tester must stop, redact, clarify or verify. Review output for hallucinated function calls and false claims of complete coverage. Repeat the task with changed context to observe variation. Keep a decision log explaining what was accepted, corrected or discarded.

Finally, compare generative AI assistance with testing AI systems. A chatbot can help a tester formulate robustness scenarios, but that does not make its own answers trustworthy test evidence. Equally, a classifier under test requires distinct evaluation techniques for drift, bias and uncertain expected results. CT-GenAI candidates should be able to explain the chosen tool workflow and its safeguards to a colleague who never sees the prompt. A defensible result contains traceable requirements, test observations and explicit review responsibility, with the AI contribution clear but never allowed to masquerade as independent proof.