ISTQB CTAL-TAE flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Test Automation Architecture (TAA)

The high-level structural design of a test automation solution: its layers, components, interfaces, and the principles guiding their organization and reuse across the test organization.

Test Automation Solution (TAS)

The concrete implemented system of tools, scripts, harnesses, and data that executes automated tests against the SUT; it is built, deployed, maintained, and eventually retired.

Test Automation Manager role

Owns automation strategy, tool selection, budget and ROI, and team enablement; accountable for the automation program rather than for individual script design details.

Test Automation Engineer role

Designs, implements, and maintains the TAS: architecture, adapters, harness, test scripts, and technical reporting; responsible for TAS quality and maintainability.

Page Object pattern

A design pattern modeling each UI page or screen as a class exposing services and elements; test logic calls page methods instead of locating elements directly, reducing duplication.

Facade pattern

Provides a simplified, unified interface to a complex subsystem, such as wrapping multiple SUT services behind one automation API so tests depend on fewer details.

Adapter pattern

Translates between the TAS and a specific SUT interface (UI, API, database, message queue), isolating technology-specific code so test logic stays interface-independent.

Factory pattern

Centralizes creation of test objects or test data, so tests request instances from a factory rather than constructing them directly, improving consistency and reducing duplication.

Singleton pattern

Ensures one shared instance of a resource such as configuration, driver, or logger; useful for shared state but risky for parallel execution and test isolation.

Observer pattern

Lets components subscribe to events (test start, failure, completion) so reporting, logging, and cleanup hooks react without tight coupling to the test logic.

Pilot project

A small, representative automation effort run before full rollout, used to validate the TAS design, estimate effort, and decide whether to scale the solution.

Automation ROI

Return on investment comparing benefits (saved manual effort, faster cycles, earlier defect detection) against TAS build, tooling, and maintenance costs over a defined period.

Automation coverage

The proportion of test conditions, requirements, or risks covered by automated tests; must be read alongside risk level, since high coverage of low-risk items is misleading.

Defect detection effectiveness

The share of real SUT defects found by the TAS, excluding TAS-caused false failures; a key measure of whether automation actually improves quality feedback.

False positive (TAS)

A test result reporting failure when the SUT is correct, usually caused by TAS or environment problems; erodes trust and consumes triage effort.

False negative (TAS)

A test result reporting pass when the SUT is defective, usually caused by weak assertions, synchronization gaps, or masked errors; the most dangerous automation failure mode.

Flaky test

A test producing inconsistent results across identical runs due to timing, shared state, or environment instability; must be fixed or quarantined, not retried indefinitely.

Test harness

The execution infrastructure that starts tests, provides data and environment, invokes the SUT through adapters, captures results, and reports outcomes.

Test data management

Provisioning, masking, versioning, and cleanup of data used by automated tests so runs are repeatable and independent; includes synthetic and production-derived data strategies.

Tool selection criteria

Factors for choosing automation tools: SUT technology fit, cost and licensing, vendor support, CI/ALM integration, extensibility, skills availability, and total cost of ownership.

TAS maintainability

The ease of modifying the automation solution as the SUT changes; driven by abstraction layers, naming conventions, low duplication, and separation of test logic from interface code.

TAS decommissioning

Planned retirement of an automation solution when the SUT, tool, or technology is replaced; includes archiving assets, migrating reusable components, and releasing licenses.

Continuous integration for TAS

Automatically building and running the automation suite on every change, requiring version-controlled configuration, deterministic data, and provisioned environments to be reliable.

SUT interface adapter

Technology-specific component translating TAS calls into SUT interactions (UI driver, API client, DB connector); isolates the harness from SUT implementation changes.

Keyword-driven testing

An approach where test steps are defined as reusable keywords with parameters, letting testers compose tests without coding; the TAS interprets keywords at execution.

Data-driven testing

Separating test logic from test data so one script runs against many data sets; requires careful data design and cleanup to keep runs independent.

Behavior-driven development automation

Expressing tests as executable specifications in natural-language-like form (Given/When/Then) that map to step implementations, improving collaboration and readability.

Automation feasibility analysis

Assessment of which tests can and should be automated, based on SUT stability, interface accessibility, data needs, execution frequency, and expected ROI.

Test automation lifecycle

The staged progression of a TAS: conception, design, build and pilot, deployment, maintenance and evolution, and decommissioning, each with defined work products.

TAS verification levels

Testing the automation solution itself: unit tests of harness components, integration tests of adapters, and end-to-end smoke checks confirming the TAS reports results correctly.

Traceability in automation

Linking automated tests to requirements or risks so coverage and gaps are measurable; orphan tests and uncovered high-risk items become explicit, reportable findings.

Object repository

A centralized store of UI element locators used by the TAS; centralizing them reduces maintenance when the SUT interface changes but requires governance to avoid duplication.