Quality Engineering and AI Assurance: Terms

Accuracy, robustness and cybersecurity

Article 15 requires high-risk systems to achieve an appropriate level of each and to perform consistently across their lifecycle, with the relevant accuracy metrics declared in the instructions for use.

Why it matters for testing: Declaring accuracy metrics makes metric choice a compliance act, and makes measured, reproducible test results a legal artifact rather than an engineering convenience.

Adversarial example

ISTQB, citing ISO/IEC TR 29119-11: "An input to an ML model created by applying small perturbations to a working example that results in the model outputting an incorrect result with high confidence."

Why it matters for testing: "With high confidence" is the operative phrase — you cannot use model confidence as a proxy oracle, which rules out the most tempting shortcut in AI testing.

Agentic testing

Testing driven by agents that plan, act and re-plan toward a goal at runtime rather than replaying authored steps.

Why it matters for testing: An agent that re-plans at runtime means the executed test is not the test you reviewed — which breaks the audit trail most QE processes assume.

Usage is contested. Vendor terminology. A useful distinction in circulation: agentic describes the mechanism, autonomous describes how much human decision-making is removed. A tool can be one without the other.

AI bill of materials

also: AIBOM, ML-BOM

An inventory of the components of an AI system — models, datasets, configurations and their provenance — by analogy to a software bill of materials.

Why it matters for testing: Without a component inventory you cannot answer the most basic regression question for an AI feature: what changed between the run that passed and the run that failed?

AI red teaming

Adversarial, goal-directed probing of an AI system for harmful or policy-violating behavior. NIST's definition: "a structured testing exercise used to probe an AI system to find flaws and vulnerabilities such as inaccurate, harmful, or discriminatory outputs, often in a controlled environment and in collaboration with system developers."

Why it matters for testing: Exploratory testing under a different name, with the same strengths and the same non-repeatability. Valuable, but not a substitute for a regression suite and not a coverage claim — published work questions whether it produces reproducible results at all, since team composition, instructions, attack rounds and tool access all move the outcome.

Usage is contested. Three things are worth knowing. The definition is not in the NIST AI RMF, which never mentions red teaming — it is in the Generative AI Profile (NIST AI 600-1, July 2024). That document files it under structured public feedback, a sociotechnical method, while the security vocabulary (CNSSI 4009-2022, NIST AI 100-2e2025) treats it as adversarial attack emulation; no authority draws the line between the two. And the most-quoted definition, from US Executive Order 14110, was revoked in January 2025 — the 2025 federal vocabulary is evaluations.

Assertion

ISTQB: "A Boolean expression that is expected to evaluate to true if and only if the software executes correctly."

Why it matters for testing: Note "if and only if". An assertion that passes for wrong behavior is not a weak assertion — it is not an assertion. Auto-generated assertions frequently fail this bar by asserting incidental output.

Auditability

The property of a system and its records being sufficient for an independent party to reconstruct and evaluate its behavior and decisions.

Why it matters for testing: Largely delivered by test and run records, so retention, immutability and completeness of your CI evidence become governance controls — and self-healing that rewrites locators without a durable log actively erodes it.

Usage is contested. No authoritative definition verified. The EU AI Act imposes concrete logging and post-market monitoring duties on high-risk providers instead.

Autonomous testing

also: autonomous QA

A claim that a system creates, executes, maintains and triages tests with little or no per-step human authorship.

Why it matters for testing: There is no agreed scale, so "autonomous" on a datasheet is unfalsifiable. Ask which specific decisions the human no longer makes, and what happens when the system is wrong.

Usage is contested. No standards-body definition. The widely circulated "five levels of autonomy" framings are vendor-authored and differ between vendors.

Bias

also: algorithmic bias, data bias, systemic bias

ISTQB defines algorithmic bias and data bias. NIST identifies three categories: systemic, statistical and human — arguing explicitly that a computational-only view is insufficient.

Why it matters for testing: Two of NIST's three categories are not detectable by any test harness, which bounds what "bias testing" can honestly claim to cover.

Code coverage versus risk coverage

ISTQB defines structural coverage — statement, branch, decision, condition — but not the bare phrase "code coverage".

Why it matters for testing: Code coverage measures which lines ran, not which risks were evaluated, and says nothing about whether an assertion existed. A suite can reach 100% statement coverage with no oracle at all.

Usage is contested. One catalog lists 101 distinct coverage measures; structural coverage is one narrow family among many.

Codeless automation

also: no-code, low-code, scriptless

Authoring tests through a visual or natural-language interface instead of code. The nearest formal concept is ISTQB's keyword-driven testing.

Why it matters for testing: Codeless changes who can author tests, not whether the testware needs version control, review and refactoring. The maintenance cost reappears as opaque platform state.

Usage is contested. No formal definition of "codeless" exists.

Concept drift

ISTQB: "A change in user expectations, behavior or the operational environment over time that negatively impacts the ML functional performance of an operational ML model."

Why it matters for testing: The correct answer itself has moved, so your stored expected results are now wrong. This silently invalidates regression baselines.

Conformity assessment

The procedure by which a provider demonstrates a high-risk system meets the requirements. For most Annex III categories this is internal control — no notified body — though a notified body is required where harmonized standards do not exist or were only partly applied.

Why it matters for testing: "Internal control" means you are the evidence. Your test records, coverage rationale and monitoring data become the conformity artifact, so QE output turns into regulatory documentation.

Content Credentials

also: C2PA, content provenance

Cryptographically signed manifests recording a media asset source and history. Distinct from watermarking, which embeds a signal in the output itself.

Why it matters for testing: EU AI Act Article 50 synthetic-content marking obligations make provenance a testable release requirement rather than a nice-to-have.

Usage is contested. C2PA states the specification was prepared for ISO standardization, but no completed ISO number is confirmed. Do not cite one.

Coverage

ISTQB: "The degree to which specified coverage items are exercised by a test suite, expressed as a percentage."

Why it matters for testing: Meaningless until you state the coverage item. "80% coverage" without naming what is counted is not a measurement.

Critical journey coverage

Coverage expressed over the small set of end-to-end journeys that carry the business. Related to the SRE notion of a critical user journey.

Why it matters for testing: The coverage question executives actually care about, and the one AI-generated breadth answers worst — hundreds of shallow generated tests can leave a checkout journey unverified end to end.

Usage is contested. No standard defines how to count it.

Data drift

ISTQB: "A change in the distribution of input data over time that negatively impacts the ML functional performance of an operational ML model."

Why it matters for testing: A model can degrade with no code change and no failing test — so pre-release testing alone cannot protect an AI feature.

Data provenance testing

ISTQB: "A test type to determine if data is sourced, managed, protected, and used in accordance with an organization's policies, standards, and regulatory obligations."

Why it matters for testing: Provenance is testable and auditable in a way that "was this AI-generated?" is not — and for training and test data, provenance failures are a compliance exposure, not just a quality one.

Datasheets for datasets

A proposal to document each dataset's motivation, composition, collection process and recommended uses.

Why it matters for testing: "Recommended uses" is the clause that tells you whether your test data is being used outside its valid envelope — a common and invisible source of misleading results.

Digital Omnibus on AI

also: Regulation (EU) 2026/1744

An amending regulation published 24 July 2026 and in force from 27 July 2026, which postpones the high-risk application dates to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems — replacing the original 2 August 2026 date.

Why it matters for testing: The single most misstated fact in current AI-governance material. High-risk conformity obligations are not yet applicable. Prohibitions, AI literacy and general-purpose AI obligations have earlier dates and are unaffected by the deferral.

DORA metrics

The current set is five: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.

Why it matters for testing: DORA has moved away from MTTR — failed deployment recovery time replaced it, and deployment rework rate was added. Worth correcting in any metrics deck.

Drift testing

ISTQB: "A type of maintenance testing that evaluates the degree to which data drift, concept drift or both occur."

Why it matters for testing: The concrete testing activity that answers drift, and it belongs in the test strategy rather than being delegated to an operations dashboard.

Error, defect, failure

ISTQB: an error is a human action that results in a defect; a failure is an event where the system does not meet its requirements during execution.

Why it matters for testing: The causal chain is error → defect → failure. Dashboards labeling every red run a "defect" inflate defect counts with environment and test-code problems.

Escaped defect

ISTQB: "A defect that is not detected by a test activity that is supposed to find it." The related metric is defect detection percentage.

Why it matters for testing: The honest counterweight to pass rate — it measures whether your suite actually catches things, which no amount of green tells you.

EU AI Act

also: Regulation (EU) 2024/1689

The EU's horizontal, risk-tiered regulation of AI systems and general-purpose AI models, in force since 2024 and applying in stages. Obligations fall mainly on providers and deployers.

Why it matters for testing: For high-risk systems it converts testing, logging and monitoring from good practice into legal duties with documentary evidence requirements.

Explainability

also: XAI

ISTQB: "The degree to which results from an AI-based system can be explained." NIST names four principles: explanation, meaningful, explanation accuracy and knowledge limits.

Why it matters for testing: Explanation accuracy is the tester's concern — an explanation that sounds plausible but does not reflect the system's actual process is worse than none, and model self-explanations routinely fail this.

Fairness testing

ISTQB defines testing for bias. Common group-fairness criteria include demographic parity and the equalized-odds family.

Why it matters for testing: Fairness is not a test that can pass. It is proven that three commonly desired fairness conditions cannot be satisfied simultaneously except in highly constrained cases — so the deliverable is a justified choice, and any tool claiming to certify a system "fair" is overclaiming.

Flaky test

also: intermittent test

A test that passes and fails on the same code and inputs.

Why it matters for testing: The metric AI-healing tools most often improve on paper and least often improve in substance, because healing can convert a flaky red into a false green. Track flaky rate separately from pass rate, always.

Usage is contested. ISTQB does not define "flaky" or "flakiness" at all — it is a practitioner term. Widely cited industrial figures come from Google: roughly 16% of tests showed some flakiness.

Harmonized standards and presumption of conformity

Article 40 of the EU AI Act grants a presumption of conformity to systems meeting harmonized standards whose references have been published in the Official Journal.

Why it matters for testing: No harmonized standard supporting the Act has been cited in the Official Journal yet, so no presumption of conformity is currently available — and the deferral regulation names that delay as one reason for the postponement. You cannot currently discharge the requirement by pointing at a standard.

Usage is contested. This rests on the absence of a published citation rather than a positive statement. Confirm before relying on it.

High-risk AI system

Two routes under Article 6: the AI is a safety component of a product already subject to third-party conformity assessment, or it falls within Annex III. A narrow derogation exists for systems performing purely preparatory or procedural tasks — but profiling of natural persons is always high-risk.

Why it matters for testing: Classification determines whether accuracy, robustness, logging, oversight and post-market monitoring become mandatory and auditable. The derogation requires documented justification, not self-assertion.

Human oversight

Article 14 requires high-risk systems to be designed so they can be effectively overseen by people, who must be enabled to understand the system's limits, remain aware of automation bias, and disregard, override or reverse the output.

Why it matters for testing: Automation bias is named in law — and it is exactly the risk in AI-assisted testing, where a green dashboard is over-trusted. Oversight must be demonstrably effective, not nominal.

Usage is contested. "Human-in-the-loop", "human-on-the-loop" and "human-out-of-the-loop" are not the Act's vocabulary. The triad is usually credited to the US Department of Defense; it is in fact Human Rights Watch and Harvard's human rights clinic, 2012. "Meaningful human control" comes from the NGO Article 36 in 2013 and was launched as an agenda item rather than a definition — the UN expert group on autonomous weapons declined to adopt it in 2019, using "human-machine interaction" and "human responsibility" instead. Article 14 is the only wording here with legal force.

Interpretability

Often used for the degree to which a model's internal mechanism is inherently understandable, as against explainability as post-hoc account-giving.

Why it matters for testing: If a requirement or contract says "interpretable", it does not have an agreed testable meaning. Make the acceptance criterion concrete before agreeing to it.

Usage is contested. ISTQB does not define it, and the distinction from explainability is genuinely disputed rather than settled.

ISO/IEC 42001

also: AI management system, AIMS

A certifiable management system standard for artificial intelligence, published December 2023, in the same structural family as ISO/IEC 27001.

Why it matters for testing: It certifies your process for governing AI, not your model's performance. A certificate is not evidence that any particular system was adequately tested. Its companion ISO/IEC 42006:2025 sets requirements for the bodies that audit and certify against it — which is what makes accredited third-party certification possible, so expect customers to start asking for it.

ISO/IEC TR 29119-11

Guidelines on the testing of AI-based systems, published 2020. A Technical Report — guidance, not a requirements standard.

Why it matters for testing: The most directly applicable published guidance for testing AI systems, and the source behind much of the citable vocabulary on this page. Being a technical report, it cannot be certified against.

Maintainability

ISTQB, citing ISO/IEC 25010: "The degree to which a component or system can be modified by the intended maintainers."

Why it matters for testing: A property of your testware too. "Zero maintenance" claims should be restated as a measurable question: what share of engineering time goes to keeping tests green?

Usage is contested. "Maintenance burden" and "maintenance share" are not defined terms. If you track the share, define your own formula explicitly.

Metamorphic testing

ISTQB: "A test technique in which test conditions are metamorphic relations" — a description of how a change to an input affects the expected result.

Why it matters for testing: The most practical oracle workaround for AI systems. You assert a relationship between outputs — paraphrase the prompt, the answer should not change category — rather than an exact value.

Model card

A short document reporting a model's intended use, evaluation procedure and benchmarked results disaggregated across demographic and intersectional groups.

Why it matters for testing: The disaggregation is the point — an aggregate accuracy number can hide unacceptable subgroup performance, which is exactly what a single pass rate would miss.

Model drift

Used loosely for an umbrella over data and concept drift, for performance decline over time, or for changes in the model artifact itself.

Why it matters for testing: In a monitoring requirement or a vendor service level agreement, "model drift" is ambiguous enough to be unenforceable. Insist the specific drift type be named.

Usage is contested. ISTQB defines data drift and concept drift but not model drift — evidence the term lacks an agreed referent.

Model-based testing

also: MBT

ISTQB: "Testing based on or involving models", with model coverage defined as "the coverage of model elements".

Why it matters for testing: A decades-old formal discipline with explicit models and coverage criteria. It is not a synonym for "an AI wrote my tests" — conflating them forfeits the actual guarantee, which is measurable coverage of a specified model.

Mutation testing

Seeding small faults into the code and measuring how many the suite detects. The mutation score is killed mutants over total non-equivalent mutants.

Why it matters for testing: The best available answer to "are my assertions real?" — and therefore the most direct empirical check on whether AI-generated tests have oracles or merely execute code.

NIST AI Risk Management Framework

also: AI RMF 1.0

A voluntary framework released January 2023, organized around four functions: Govern, Map, Measure, Manage.

Why it matters for testing: "Measure" is where testing lives, and the insistence that measurement be documented and revisited maps cleanly onto a test strategy. It is voluntary — it confers no conformity.

Usage is contested. NIST states version 1.0 is being revised; no 2.0 designation or date is published, so it should not be cited as stable.

OWASP Top 10 for LLM Applications

A ranked risk list for language-model applications. The 2025 edition runs from LLM01 Prompt Injection through LLM10 Unbounded Consumption, including excessive agency, improper output handling and data poisoning.

Why it matters for testing: The most usable ready-made checklist for turning "test the LLM feature" into specific, assignable test objectives — and LLM06 Excessive Agency applies to agentic test tooling itself.

Pass rate

The proportion of test runs that pass.

Why it matters for testing: The most gameable number in quality engineering — healing, retries and quarantining all raise it without improving anything. Always pair it with flaky rate, defect detection percentage and maintenance share.

Usage is contested. Not a defined ISTQB or ISO metric. ISTQB defines only "metric" itself.

Post-market monitoring

Article 72 requires providers of high-risk systems to collect and analyze performance data across the system lifetime, with the monitoring plan forming part of the technical documentation.

Why it matters for testing: A legal mandate for shift-right testing. Note the drafting oddity: Article 72 was not deferred, so it is formally applicable now while the requirements it monitors are not.

Pseudo-oracle

ISTQB: "An independently derived variant of the test item used to generate results, which are compared with the results of the original test item based on the same test inputs."

Why it matters for testing: One of the few legitimate oracle substitutes when expected results cannot be stated — and the honest name for "compare against the old model".

Regression testing and confirmation testing

ISTQB: regression testing detects "whether defects have been introduced or uncovered in unchanged areas"; confirmation testing is performed after a fix "to confirm that a failure caused by that defect does not reoccur".

Why it matters for testing: ISTQB is strict here and industry routinely conflates them. Re-running the failed test after a fix is confirmation. Regression is about the code you did not touch.

Risk-based testing

ISTQB, citing ISO/IEC/IEEE 29119-1: "A test approach in which the management, selection, prioritization, and use of test activities and resources are based on corresponding risk types and risk levels."

Why it matters for testing: The only defensible way to answer "have we tested enough?", and the only framing in which risk coverage is a real measurement rather than a slogan.

Self-healing test

also: locator repair, auto-healing

A test that, on failing to find an element, re-identifies it by alternative attributes, structural similarity or visual match and continues.

Why it matters for testing: Healing suppresses the signal that the interface changed. A heal that silently retargets a different element converts a genuine regression into a green test — the most dangerous failure mode in AI-assisted suites. Insist the substitution is logged and reviewable.

Usage is contested. Not defined by ISTQB or ISO. Academic locator-repair work addresses a narrower, better-defined problem: implementation drift without behavioral change.

Shift left

ISTQB: "A test approach to perform testing and quality assurance activities as early as possible in the software development lifecycle." Coined by Larry Smith in 2001.

Why it matters for testing: About when quality activity happens, not which tool performs it. Buying an AI tool shifts nothing left if it still runs after the build.

Shift right

ISTQB: "A test approach to test a system continuously in production."

Why it matters for testing: For AI features this is not optional — drift and real-world input distributions are only observable in production.

Smoke testing

ISTQB: "A test type to gain sufficient confidence that a test object is ready for planned testing."

Why it matters for testing: Its job is to decide whether deeper testing is worth starting — a gate, not a quality verdict. Calling a broad generated happy-path suite "smoke tests" overstates what a green run licenses you to conclude.

System card

Documentation covering an assembled AI pipeline — components, interactions, data flows — rather than a single model. Originates with Meta in February 2022 and is now the default term at several major labs.

Why it matters for testing: Useful reading, but not evidence. Do not accept a system card as a conformity artifact — the EU AI Act technical-documentation annex asks for different things, and uses neither "system card" nor "model card".

Usage is contested. No ISO, IEEE or NIST document specifies it, and published cards share no common schema.

Test generation from requirements

Deriving test cases automatically from natural-language requirements, stories or tickets.

Why it matters for testing: Generated tests inherit the ambiguity of the requirement and, worse, tend to encode current behavior as expected behavior. A generated suite can pass perfectly while asserting the bug.

Test oracle

ISTQB: "A source to determine an expected result."

Why it matters for testing: The term most often quietly dropped in AI testing pitches. Generating and executing steps is cheap; knowing what the correct result is remains a human or specification input. A tool that generates tests without an oracle has automated the easy half.

Test oracle problem

ISTQB: "The challenge of determining whether a test has passed or failed for a given set of test inputs and state."

Why it matters for testing: The reason AI cannot fully close the loop — and it is sharper still for AI under test, where there may be no single correct output.

Test pyramid

ISTQB: "A graphical model representing the relationship of the amount of testing per level, with more at the bottom than at the top."

Why it matters for testing: AI tooling is overwhelmingly strongest at the top of the pyramid, so adopting it tends to invert the shape: cheap to author, expensive and slow to run and diagnose.

Usage is contested. The shape is contested — competing "testing trophy" and "honeycomb" models exist.

Time to feedback

The elapsed time from a change being committed to a trustworthy verdict.

Why it matters for testing: AI-authored end-to-end suites often improve authoring speed while degrading feedback time, because generated UI tests are slow and their failures are ambiguous. Measure the time to an actionable verdict, not to run completion.

Usage is contested. Not a named standard metric. The nearest anchors are ISTQB continuous testing and DORA change lead time.

Verification and validation

also: V and V

ISTQB: verification is "confirming that a work product fulfills its specification"; validation is "confirmation by examination that a work product matches a stakeholder's needs".

Why it matters for testing: Building it right against building the right thing. AI test generation works from the specification or the code, so it scales verification and does essentially nothing for validation — yet is often sold as covering both.

Visual testing

ISTQB: "A test type that uses image recognition to interact with GUI objects."

Why it matters for testing: Note that ISTQB scopes this to interaction, not correctness. Vendors often market visual locating as if it also supplied the oracle. It does not.