ISTQB CTAL-ATT key terms

A collaborative practice in which business, development, and testing stakeholders define acceptance criteria and acceptance tests before implementation begins, so shared examples drive what gets built and how it will be verified.

A refinement of test-first collaboration that expresses expected behavior in structured natural language using Given/When/Then patterns, making examples readable to business stakeholders and executable as automated acceptance tests.

An approach where a team captures requirements as concrete, realistic examples agreed with business stakeholders, then uses those examples as the basis for tests, documentation, and a shared understanding of expected system behavior.

Documentation generated from or kept synchronized with executable tests and examples, so it stays accurate as the product evolves and reflects the system's actual current behavior rather than historical intent.

A plain-language, keyword-based syntax (Feature, Scenario, Given, When, Then, And) used to write executable acceptance criteria that both non-technical stakeholders and automation tools can read and process.

The automation code that binds a Gherkin step's text to executable actions, connecting a human-readable scenario line to the underlying test automation logic and assertions.

A short, informal description of a feature written from the user's perspective, typically stating role, goal, and benefit, intended to trigger conversation and be refined into concrete acceptance criteria before development.

The conditions a user story or feature must satisfy to be accepted by stakeholders, expressed as testable statements that guide development and form the basis for acceptance tests.

A checklist for evaluating user story quality: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Stories failing these qualities are usually hard to plan and hard to verify.

A team-agreed checklist describing what a backlog item must contain, such as clear acceptance criteria and resolved dependencies, before it can be pulled into a sprint or iteration for development.

A shared checklist of conditions that must hold for any increment to be considered complete, typically covering testing, review, documentation, and integration, applied uniformly across all work items.

The ongoing activity of reviewing, clarifying, splitting, and re-estimating backlog items so they meet the team's readiness criteria and can be scheduled into upcoming iterations.

A recurring team meeting at the end of an iteration where members inspect how they worked together and identify concrete improvements to process, tooling, and collaboration for the next iteration.

A way of working in which testing responsibility is shared across all roles, including developers, testers, and business representatives, rather than isolated in a separate quality-assurance group.

A team containing the diverse skills needed to deliver an increment end to end, such as analysis, design, development, testing, and deployment capability, reducing handoffs and external dependencies.

A model for distributing automated tests across levels, with many fast unit tests at the base, fewer service or integration tests in the middle, and few slow end-to-end UI tests at the top.

The combined architecture of guidelines, coding standards, libraries, test data handling, and reporting tooling that supports creating, running, and maintaining automated tests consistently across a project.

A design technique that models each user interface screen or component as a class encapsulating its elements and interactions, separating test logic from UI locators to reduce duplication and maintenance effort.

A generic term for stand-in objects used in automated tests, such as stubs, mocks, fakes, and spies, that replace real dependencies so tests can run in isolation and under controlled conditions.

A technique for simulating the behavior of unavailable or costly external systems and interfaces, letting automated tests exercise integration points without depending on real third-party services or environments.

The practice of planning, generating, provisioning, and cleaning up data used by automated tests, ensuring tests are repeatable, independent, and free of privacy or regulatory risk.

The discipline of provisioning, configuring, reserving, and maintaining the hardware, software, and network conditions that automated tests require, so test runs are reliable and reproducible.

The ease with which automated test assets can be understood, updated, and extended over time, strongly influenced by design patterns, naming conventions, abstraction levels, and coupling to the product under test.

The accumulated cost of shortcuts and suboptimal design decisions, such as fragile scripts or missing tests, which slows future change and must be deliberately managed and repaid.

A practice where developers frequently merge code into a shared mainline, with each merge triggering automated build and test runs to detect integration problems quickly.

A practice that keeps software in a deployable state at all times, with automated build, test, and release processes, so any validated version can be released to production on demand.

An extension of continuous delivery in which every change passing automated quality gates is released to production automatically, without a separate manual release decision.

The automated sequence of stages, such as compile, unit test, integration test, and deploy, that a change passes through, providing fast feedback and gating promotion to later environments.

A defined step within a build pipeline with its own entry criteria, automated activities, and exit criteria, controlling when an artifact advances toward production.

A set of predefined criteria, such as test pass rates, coverage thresholds, or defect limits, that a build must satisfy before it is allowed to progress to the next stage or release.

A configuration mechanism that enables or disables functionality at runtime without redeploying, supporting trunk-based development, gradual rollout, and safe testing of incomplete features.

A deployment strategy that exposes a new version to a small subset of users or traffic before full rollout, allowing observation of behavior and fast rollback if problems appear.

A release technique using two identical production environments, switching traffic from the live one to the newly deployed one, enabling near-instant rollback by switching back.

The process of reverting a deployment or release to a previous known-good state, ideally automated and rehearsed so recovery is fast and does not depend on manual reconstruction.

A branching practice where developers commit small, frequent changes to a single shared mainline, avoiding long-lived branches and the integration risk they create.

A collaborative culture and set of practices uniting development and operations to shorten delivery cycles, automate infrastructure and deployment, and improve reliability through shared ownership.

Managing servers, networks, and environments through version-controlled configuration files and automation rather than manual setup, making environments reproducible, reviewable, and consistent.

A simultaneous learning, test design, and execution approach where the tester designs and runs tests interactively, guided by models, charters, and observations rather than pre-scripted steps.

A way to structure and measure exploratory testing by dividing it into time-boxed sessions with charters, notes, and debriefs, making unscripted testing visible, accountable, and reportable.

A short statement defining the mission and focus of an exploratory testing session, guiding what area to investigate and what risks or behaviors to probe without prescribing exact steps.

An approach that allocates testing effort according to the likelihood and impact of potential failures, focusing automation and manual effort where product risk is greatest.