Software testing is not a synonym for running a checklist after developers finish coding. It is a way of producing useful information about product quality, uncertainty and risk throughout delivery. Testers ask what could fail, which evidence is available, how a defect affects users and whether the team has enough confidence to release a change. The International Software Testing Qualifications Board (ISTQB) structures its qualifications around that discipline, from a common foundation to specialized testing concerns.
The principal starting point is Certified Tester Foundation Level v4.0, known as CTFL. Candidates can then explore technical, agile, management and specialist qualifications according to their roles. Other specialized testing credentials include CT-AI and CT-GenAI. Their names sound similar, but they answer different questions: how do we test AI-based systems, and how do we use generative AI to support testing work?
Foundation-level testing is about reasoning under uncertainty
The CTFL syllabus covers fundamental testing concepts, testing through the development lifecycle, static testing, test-analysis and design techniques, managing testing activity, and the use of tools. It is intended to remain relevant across sequential, agile and continuous delivery approaches. The value lies in the language and reasoning it gives teams, not in requiring every organization to use one project method.
Consider an online banking transfer feature. A developer may check that a valid transfer succeeds. A tester asks about invalid amounts, duplicate submissions, insufficient balance, session expiry, interrupted network connections, timezone boundaries and different user permissions. The objective is not to imagine every possible failure in the universe; it is to prioritize plausible defects using risk, product behavior and knowledge of the system.
Verification and validation help frame the work. Verification investigates whether an artifact conforms to specified requirements or design; validation examines whether the product meets its intended use and stakeholder needs. A product can meet a written requirement yet still be hard to use or unsafe under a common operational condition. The distinction encourages test professionals to challenge incomplete requirements before a release becomes expensive to change.
Risk-based testing is particularly important. A failure in a decorative screen animation is not equivalent to a defect that allows unauthorized access or miscalculates a financial transaction. Severity, exposure, complexity, change history and testability influence the attention a feature deserves. A useful test strategy states which risks are being investigated, what evidence is sufficient and which risks remain untested because of practical constraints.
Test techniques turn vague concerns into useful cases
Equivalence partitioning groups input values expected to behave similarly. If a form accepts a numeric quantity from 1 through 100, a tester might separate valid values, values below the minimum and values above the maximum. Boundary value analysis then examines transitions such as 0, 1, 100 and 101 because defects often occur at edges. These methods help select test cases without simply generating many random numbers.
Decision-table testing becomes valuable when combinations of business rules determine the outcome. A refund process might depend on purchase age, product condition, subscription tier and fraud status. A decision table forces the team to identify combinations that otherwise remain implicit. State-transition testing is more useful when behavior depends on history: a user may move from active to suspended to locked, with different permitted actions in each state. Applying the wrong technique can produce superficial coverage even when the test suite is large.
Test design should also distinguish positive and negative scenarios. A valid login proves little about protection against repeated failed attempts, expired accounts, lost sessions or improperly assigned roles. Testing must consider data, environment and user context. A clean test dataset that contains only standard cases may hide the very problem a production system will encounter. Equally, indiscriminate use of real customer data creates privacy and security risk; test-data selection needs controls.
Static testing complements execution. Reviews of requirements, code, architecture and tests can expose ambiguities or faults before a running application exists. Dynamic testing then exercises behavior and observes results. Neither method makes the other obsolete. A peer review can identify a missing authorization requirement; a runtime test can reveal that a seemingly correct implementation uses the wrong permission in practice.
Working in agile and continuous delivery environments
Test activity should evolve with software delivery, but it should not lose independence of judgment. Developers may write unit tests, engineers may maintain integration and API tests, and exploratory testers may investigate complex user behavior. A single “QA stage” at the end is poorly suited to frequent releases because feedback arrives late. Teams should make quality risks visible while design decisions are still changeable.
Automated tests can reduce repeated manual effort and provide fast feedback, yet automation requires maintenance and disciplined selection. A flaky test that fails unpredictably without product defects is not harmless; it trains teams to ignore failure signals. A valuable suite separates deterministic checks from exploratory investigation, verifies environments and data, and produces failures that can be diagnosed. The proportion of automated tests is not a direct measure of quality.
Regression testing is another matter of prioritization. A new feature may affect modules far away from its visible interface through shared services, libraries, APIs or data formats. Change-impact analysis helps choose relevant regression coverage. Testers should also know when repeated automated checks cannot establish acceptable user experience, accessibility or resilience. A release decision is based on evidence and acknowledged uncertainty, not a green build icon alone.
Defect reports should tell a useful story. An engineer needs the observed behavior, expected behavior, affected version and environment, reproducible steps when feasible, logs or other evidence, and an assessment of impact. A report that only says “not working” creates extra investigation work. Good testers remain careful about causation: an observed timeout might be caused by a dependent service or test infrastructure, not necessarily the component being blamed.
CT-AI: testing systems that learn or generate output
The CT-AI credential focuses on the special characteristics of AI-based systems. ISTQB released CT-AI version 2.0 in 2026. Its scope includes machine-learning data, model evaluation, system-level testing and challenges such as probabilistic behavior and non-deterministic output. The earlier CT-AI v1.0 remains in a retirement transition, with official English and non-English sunset dates extending into 2027. Candidates should identify the syllabus version at the time of exam booking.
AI testing often lacks a simple expected-output oracle. A classifier's behavior may be evaluated using precision, recall and error analysis across relevant segments rather than a single assertion that the output equals one fixed string. Testers must consider data representativeness, labeling quality, leakage between training and evaluation sets, bias, robustness and model performance after deployment. A model that scores highly on a benchmark may still fail the population or operating context for which it is being purchased.
Generative-AI systems add different complications. A large language model can produce plausible but false answers, vary its output between runs or mishandle adversarial instructions. Test design may require behavioral criteria, repeated evaluation, representative scenarios, human review and explicit monitoring. CT-AI teaches how to evaluate systems with such characteristics; it is not only an introduction to prompting a chatbot.
The scope of CT-AI v2.0 intentionally distinguishes testing AI systems from using AI to perform testing tasks. That distinction becomes central when choosing between the two AI credentials. The latest official syllabus and sample examinations should be consulted rather than assuming the 2022 or 2024 material captures the current model-evaluation requirements.
CT-GenAI: using generative AI in the testing process
The CT-GenAI credential addresses the use of generative-AI tools to assist human testers with activities such as analyzing requirements, creating test ideas, generating or refining automation, interpreting results and reporting. The official CT-GenAI syllabus received a version 1.1 update in 2026, with clarifications around prompt techniques, evaluation, risk and related topics. The certification still requires CTFL as a prerequisite.
Consider an assistant asked to produce boundary tests for a complicated pricing rule. The output may look impressive but omit an essential tax or contract condition. Responsible use therefore requires a human to verify the requirements, assess generated cases for coverage and correctness, protect confidential input data, and record what the tool contributed. Productivity claims are meaningless if additional review effort or hidden defects erase the apparent gain.
Prompting is also a software-quality concern. A good testing prompt specifies context, task, output expectations, constraints and relevant examples, while leaving room for uncertainty to be declared. The generated output should be checked against known rules, not treated as authoritative because its format is polished. An LLM can help organize possible tests, but the test oracle and release accountability remain with the people who understand the product.
There are security and privacy limitations. Inserting customer logs, credentials or unreleased source code into an unapproved third-party AI tool may violate contractual or organizational controls. Teams should establish which systems and datasets are permitted, what is retained by the provider and how outputs are verified. CT-GenAI study must recognize these governance questions alongside the practical capability of automation assistants.
Selecting the next credential and preparing properly
CTFL is the normal foundation. From there, an automation-focused tester might choose a technical specialty; someone who coordinates a program might prefer test management; an engineer evaluating machine-learning applications may select CT-AI; and a quality professional applying AI to test activity may select CT-GenAI. Neither AI credential should be described as a general replacement for the other. Both build on foundation-level testing knowledge, but they have different assessed tasks.
The best preparation uses ISTQB's current syllabus, official glossary and available sample examinations, then applies the techniques to a small system. Practice writing equivalence classes, boundary cases, decision tables, state transitions and risk-based priorities. For an AI specialty, design an evaluation that could reveal model failures and describe its limitations. For a GenAI specialty, critique model-generated tests and record where human verification changes the result.
ISTQB certification can support a shared language of software quality. Its strongest result is a tester who can choose a technique for a reason, question inadequate evidence, adapt to unfamiliar technology and explain honestly what a test does—and does not—prove.
