In the first context, generative AI supports testers in their work. A Large Language Model (LLM)—that is, a language model for processing and generating text—can, for example, analyze requirements, develop test ideas, formulate test cases, or assist in evaluating results.
A practical example: A test analyst has an LLM examine a user story for ambiguities, missing acceptance criteria, and potential edge cases. The prompt—that is, the instruction used to guide the model—also plays an important role here. Even small changes to the prompt can influence the quality of the response. This prompt testing helps to systematically develop and evaluate suitable inputs.
AI can thus accelerate and expand the testing process. However, the technical evaluation and responsibility remain with humans.
In the second approach, the GenAI system itself is the test subject. In LLM testing or generative AI testing, the system is evaluated to determine whether its responses are correct, relevant, robust, secure, and suitable for the specific use case.
Generative AI testing thus differs from traditional software testing, where expected results can often be clearly defined. Generative models, on the other hand, operate probabilistically and can produce different—yet still acceptable—responses to similar inputs.
Using GenAI in the Testing Process – An Overview of Application Areas
Anyone who wants to use GenAI testing can effectively leverage generative AI at many stages of the testing process. Large language models can analyze, formulate, generate variants, and condense information. However, they do not replace testers’ technical judgment. A convincingly worded response does not constitute a reliable test result—GenAI provides suggestions that must be reviewed, scrutinized, and contextualized.
1. Analyzing Requirements
During test analysis with LLMs, GenAI can scan requirements, user stories, or acceptance criteria for ambiguities, contradictions, and missing information.
Example: For a feature that changes bank account information, the model recognizes that while the “happy path” is described, it remains unclear what happens if the new IBAN is already assigned to another customer account or if the verification process fails.
This can accelerate a requirements review with AI. However, humans must assess whether the indication is technically relevant and which requirement is actually missing.
2. Develop Test Ideas
GenAI works well as a sparring partner for identifying different test scenarios and edge cases.
Example: For online check-in for a flight, the model suggests—in addition to the standard process—tests for expired travel documents, last-minute seat changes, multiple travelers in a single booking, or a connection failure immediately after boarding passes are generated.
This is precisely where GenAI can broaden one’s perspective. However, it does not guarantee completeness. Risk analysis, prioritization, and selection remain the responsibilities of the test team.
3. Formulating Test Cases
GenAI can also save time when it comes to test case generation with AI. Structured test cases—including preconditions, steps, and expected results—can be designed based on requirements and existing test ideas.
Example: For a new refund logic in an online store, the model formulates test cases for full and partial returns, gift cards, mixed payments involving credit cards and store credit, as well as partial refunds that have already been issued.
The results should be considered drafts. The team must verify whether the test cases are technically correct, reasonable, and actually covered by the requirements.
4. Generating Ideas for Test Data
GenAI can suggest possible value classes, boundary values, and unusual data combinations.
Example: For a European customer portal, the model generates test data ideas for names with umlauts or apostrophes, very long company names, different phone number formats, and addresses from countries with varying postal code and house number conventions.
This is particularly helpful for generating ideas. However, production or personally identifiable data should not be transferred to external models without proper oversight, and synthetically generated test data must be checked for business plausibility.
5. Supporting test automation
In test automation with GenAI, LLMs can draft code, explain existing scripts, or assist with refactoring.
Example: An existing Selenium test checks whether the correct contract confirmation appears after a rate plan change. An LLM uses this to generate an initial Playwright draft, extracts reusable selectors, and suggests variations for different rate plan combinations.
The generated code is not a guarantee of quality. Automated tests must still be reviewed, executed, and checked for maintainability and correct assertions.
6. Accelerating Reporting and Documentation
GenAI can summarize large volumes of test results and assist with test documentation.
Example: After a regression test involving several hundred test cases and numerous defects, the model generates an initial management report: Which features were particularly affected, which clusters of defects occurred, and where do known risks still exist prior to release?
This saves on paperwork but carries a particular risk: A model can infer connections that aren’t actually present in the source data. Numbers, statements, and conclusions must therefore be verified against the original data.
Prompt Engineering Becomes a Testing Competency
How useful these applications are depends heavily on prompt engineering. Good prompts specify the context, task, relevant data, desired output format, and boundaries as clearly as possible. Instead of “Create test cases,” for example, a prompt that describes the role, requirement, key risks, and expected structure is more helpful.
Prompting is therefore not a one-time task of formulating a prompt, but an iterative process: review the results, identify weaknesses, improve the prompt, and re-evaluate. This very skill is also a component of the ISTQB® Certified Tester – Testing with Generative AI (CT-GenAI).
You can find more concrete examples of how AI can support testers in their day-to-day work in our article Artificial Intelligence in the Day-to-Day Work of Software Testers.
Testing GenAI Systems—What Traditional Testing Doesn’t Cover
In traditional software testing, the logic is often straightforward: For a given input, there is an expected result that is compared to the actual result. With LLM testing, this “theoretical vs. actual” comparison isn’t enough. Generative AI works probabilistically—the same model can generate different responses to the same or very similar prompts, several of which may be technically acceptable.
Consequently, the testing logic shifts: Instead of merely checking individual expected results, testers must consider distributions, repetitions, and quality metrics across many outputs. What matters is not just whether a response was correct once, but how reliably the system behaves across different inputs and repeated test runs. Statistical methods thus become a central component of quality assurance for GenAI systems.
1. Functional Correctness
GenAI applications also have functional requirements. For example, a support chatbot should correctly state a return deadline or trigger specific actions. Where unambiguous reference responses exist, outputs can be compared to a gold standard—that is, a domain-expert-verified reference set.
For structured outputs, automatic output validation is also useful. If a model returns JSON, for example, it is possible to verify whether the response conforms to a defined schema, contains all required fields, and uses valid values.
2. Hallucinations
An LLM can generate statements that sound convincing but are not supported by facts or provided sources. Anyone who wants to test for hallucinations therefore needs test cases with verifiable facts, missing information, and deliberately misleading questions.
In a RAG system (Retrieval-Augmented Generation), a language model is connected to external knowledge sources, such as internal documentation. Here, for example, you can check whether a chatbot refuses to provide an answer when the knowledge base does not contain relevant information—rather than inventing a plausible answer.
3. Bias and Fairness
Bias testing examines whether responses change systematically when characteristics that are actually irrelevant are varied. Closely related to this is fairness: Are comparable individuals, groups, or situations treated comparably?
In a recruiting scenario, for example, name, age, or gender can be varied while qualifications and experience remain identical. Instead of evaluating individual responses in isolation, the results should be statistically compared across many repetitions. Only then do systematic biases become apparent.
4. Robustness
How does the model behave in the face of typos, contradictory information, unusual phrasing, or intentionally difficult prompts?
In adversarial testing, such inputs are deliberately constructed. For example, a system can be confronted with contradictory instructions, unusual formatting, or manipulated contextual information. The goal is not only to check whether the “correct” answer is produced, but also to assess how stable the behavior remains under challenging conditions.
5. Drift and Reproducibility
A GenAI system that tests successfully today may not react identically tomorrow. Model updates, changes to system prompts, retrieval data, or user behavior can alter its results.
To detect drift, therefore, stable benchmark datasets, recurring evaluations, and defined quality metrics are required. When it comes to the reproducibility of AI, the goal is not to reproduce every word identically. What matters is whether relevant quality characteristics—such as correctness, hallucination rate, or safety—remain stable within defined limits.
6. Security, Prompt Injection, and Red Teaming
In a prompt injection, an input attempts to circumvent the intended rules of a GenAI system. For example, an attacker might try to trick an assistant into ignoring system instructions, disclosing confidential information, or performing unauthorized actions.
Red teaming goes beyond individual, pre-prepared security tests. A red team systematically attempts to steer the system away from its intended use and provoke vulnerabilities. This includes direct and indirect prompt injections, multi-stage attacks, manipulated documents within a RAG system, or attempts to bypass security mechanisms through rephrasing and context changes.
Variation is also important here: an attack that is repelled in one form may succeed in a slightly modified form. Red teaming therefore considers not only individual test cases but also attack classes, repetitions, and patterns in system behavior.
How can quality be reliably assessed?
Not every output can be checked manually. In addition to gold standards, rules, and statistical methods, LLM-as-Judge is therefore increasingly being used: Another language model evaluates responses based on defined criteria.
However, such a “judge” is itself a probabilistic system. Therefore, its evaluation must also be calibrated. To do this, the LLM judge’s evaluations are compared with the judgments of human experts. It is important that human reviewers also judge consistently among themselves and apply the same criteria. Only when human and automated evaluations are transparently aligned can an LLM-as-Judge be meaningfully deployed for larger test sets.
This fundamentally changes generative AI QA: Quality does not result from a single “pass” or “fail,” but from data series, distributions, thresholds, and repeatable evaluations.
You can find more about fundamental testing strategies in Successful AI Testing – Best Practices for Every Project. The ISTQB® Certified Tester AI Testing (CT-AI v2) also offers a systematic learning path for testing AI-based systems.
