ISTQB CTAL-TAE key terms

The overall structural design of an automation solution, describing its layers, components, interfaces, and how test scripts, tools, and the system under test interact. It guides how maintainable, reusable automation is built and evolved over time.

A set of reusable components, conventions, and supporting code that provides structure for creating and running automated tests. It handles concerns such as test data, reporting, logging, and object interaction so individual tests stay focused on verification.

A documented plan describing what to automate, why, at which levels, with which tools, and how automation will be introduced and maintained. It aligns automation goals with business and quality objectives and sets measurable success criteria.

The responsibility set covering design, development, maintenance, and improvement of automated test solutions, plus tool selection and integration with CI. It includes collaborating with testers and developers and reporting on automation value, risks, and technical debt.

The product, application, or component being tested by the automation. Automation must interact with it through defined interfaces, and understanding its architecture, protocols, and testability strongly influences automation design choices.

The degree to which a system supports testing, including observability of state, controllability of inputs, clear interfaces, and minimal hidden dependencies. Low testability drives up automation cost and often requires design changes or test doubles.

A deliberate, minimal seam built into the product to allow automation to control or observe behavior, such as a reset endpoint or a status probe. Hooks improve testability but must not alter production behavior.

A stand-in object used in place of a real dependency during testing, such as a stub, mock, fake, or spy. Doubles isolate the SUT from slow or unavailable components and make specific behaviors easier to trigger and verify.

A test double that records interactions and lets the test verify that specific calls occurred with expected arguments. Mocks focus on behavior verification rather than returning realistic data, and overuse can couple tests to implementation details.

A simplified test double that returns predefined responses to calls, without verifying how it was used. Stubs supply controlled inputs so the SUT can be exercised along specific paths during automated tests.

A checking approach where the test inspects the resulting state or output of the SUT after execution, rather than the interactions it made. It tends to be less brittle than interaction checking when internal collaborations change.

A checking approach where the test confirms that the SUT invoked particular collaborators with particular arguments. It is powerful for interaction protocols but can make tests fragile when implementation details are refactored.

A design that separates automation into layers, typically test cases, business-facing actions, and technical drivers or page objects. Clear layering reduces duplication, isolates change, and improves readability and reuse across the suite.

A design pattern where each UI screen or component is represented by a class exposing services and element access, hiding locators from tests. It centralizes UI change impact and makes test scripts more readable and maintainable.

A design approach that models tests as actors performing tasks composed of interactions with the system. It emphasizes reusable, composable business-facing steps and can produce more readable and modular automation than page-centric designs.

An approach where tests are expressed as sequences of reusable action keywords, often separated from the technical implementation. It lets less technical stakeholders define test logic while engineers maintain the keyword library.

A technique where the same test logic runs repeatedly with different input and expected data drawn from external sources such as files or databases. It increases coverage per script and separates data maintenance from code.

A single test definition that accepts parameters and is executed once per supplied data set. It reduces duplication and makes it easy to add cases by extending the data provider rather than copying test code.

A collection of reusable functions, helpers, and abstractions shared across automated tests, such as login utilities or data builders. A well-curated library reduces duplication and keeps test code consistent and easier to maintain.

The chosen method for identifying UI elements, such as IDs, accessibility attributes, or XPath. Stable, intention-revealing locators reduce false failures, while brittle ones tied to layout make suites expensive to maintain.

The techniques used to coordinate automation with asynchronous system behavior, including explicit waits, polling, and event-based conditions. Correct synchronization avoids both premature actions and fixed sleeps that slow and destabilize suites.

An automated test that produces inconsistent pass and fail results on unchanged code, usually due to timing, shared state, or environment issues. Flakiness erodes trust in results and must be diagnosed and eliminated, not ignored.

Designing tests so each one sets up and cleans its own state and does not depend on others' execution order or side effects. Isolation enables parallel execution, reliable reruns, and simpler failure diagnosis.

The practice of planning, creating, provisioning, and cleaning data used by automated tests. Good management covers realistic values, privacy constraints, uniqueness, and reset between runs to keep tests independent and repeatable.

The combination of hardware, software, configuration, services, and data on which automated tests execute. Environment differences from production are a leading cause of automation failures, so configuration must be controlled and reproducible.

Using containers, virtual machines, or service virtualization to create on-demand, reproducible test environments and simulated dependencies. It increases availability and parallelism while reducing cost and configuration drift.

Simulating the behavior of dependent systems, such as third-party APIs or mainframes, so tests can run when those systems are unavailable, slow, or costly. It enables controlled responses and fault injection during automated runs.

A practice where code changes are merged frequently and each merge triggers automated build and test execution. Automation engineers integrate suites into the pipeline, manage feedback speed, and ensure results are visible and trustworthy.

An approach where software is kept in a deployable state at all times, with automated pipelines verifying each change. Automated tests at multiple levels provide the safety net that makes frequent, low-risk releases feasible.

A model suggesting many fast unit tests, fewer service or integration tests, and few slow UI tests. It guides automation investment toward quick feedback and highlights the cost of over-relying on end-to-end checks.

The component that discovers, schedules, and runs automated tests, handles parallelism, and reports results. Its capabilities, such as retries, sharding, and filtering, directly affect feedback time and suite reliability.

The tool or process that invokes test code, applies fixtures and setup, and records outcomes. Understanding its lifecycle, hooks, and configuration is essential for controlling execution order, grouping, and result reporting.

A statement that checks whether an actual result matches the expected outcome and fails the test when it does not. Precise assertions with clear messages make failures diagnosable and prevent tests that pass without verifying anything.

The collection and presentation of automation results, including pass and fail status, logs, and evidence. Actionable reports with trends and failure detail support decision-making and rapid triage in continuous pipelines.

Quantitative measures used to judge automation value and health, such as coverage, pass rate, execution time, defect detection, and maintenance effort. Metrics should guide improvement and be interpreted alongside qualitative context.

The balance of benefits such as faster feedback and repeatable regression against costs of tooling, creation, and maintenance. It is assessed over time and depends on how often tests run and how much manual effort they replace.

Accumulated shortcuts in test code and infrastructure, such as duplicated scripts, brittle locators, and hard-coded data, that raise future maintenance cost. It must be tracked and periodically repaid to keep automation sustainable.

A test result that reports a failure when the SUT is actually behaving correctly, often caused by environment or synchronization problems. Frequent false positives waste triage effort and reduce confidence in the automation suite.

A test result that reports a pass when a real defect is present, for example because assertions are too weak or the test does not exercise the faulty path. False negatives create dangerous gaps in the safety net.

Automating checks that previously working functionality still behaves correctly after changes. Prioritizing stable, high-value regression cases and running them continuously protects against unintended breakage while controlling suite size.