ISTQB CTAL-TAE cheat sheet

TAS (Test Automation Solution) architecture layers: test design/management, test execution (harness), SUT interfaces (adapters), and the SUT itself; the TAA (Test Automation Architecture) defines their structure, interfaces, and reuse points.

Design principles from the syllabus: single responsibility per component, separation of concerns between test logic and SUT access, high cohesion/low coupling, and reuse of building blocks across TAS and TAA levels.

TAS development follows an iterative/incremental lifecycle: conception, design, build (pilot, then incremental expansion), deployment, maintenance/evolution, and decommissioning; each phase produces defined work products.

A pilot project validates the TAS on a small, representative scope before rollout; its success criteria (coverage, defect detection, ROI, maintainability) gate the decision to scale.

TAA design patterns: Page Object (UI abstraction), Facade (simplified subsystem access), Adapter (SUT interface translation), Factory (test data/object creation), Singleton (shared resources such as config or driver), and Observer (event/reporting hooks).

The Test Automation Manager owns TAS strategy, tool selection, ROI, and team enablement; the TAE owns design, implementation, and technical maintenance of the TAS; roles must be explicit in the automation plan.

Metrics for a TAS include automation coverage, defect detection effectiveness, false-positive/false-negative rates, script maintenance effort per change, execution time, and automation ROI; collect them continuously, not once.

Tool selection criteria: fit to SUT technology and interfaces, licensing/cost, vendor support and roadmap, integration with CI/ALM, skills availability, extensibility, and total cost of ownership across the TAS lifecycle.

The TAS must support both functional and non-functional automation (performance, security, usability) where in scope; different SUT interfaces (UI, API, service, database, message queue) require dedicated adapters.

Automation verification is distinct from SUT verification: the TAS itself must be tested for correctness, reliability, and maintainability before its results are trusted for release decisions.

Verification levels for a TAS: component/unit tests of harness and adapters, integration tests of TAS-to-SUT interfaces, and end-to-end smoke tests of the full solution.

A TAS defect classification scheme separates TAS defects (false results, flakiness, environment) from SUT defects; only SUT defects count toward defect detection effectiveness metrics.

Review and static analysis of automation code apply the same rigor as production code: naming, structure, exception handling, logging, and configuration management are reviewable artifacts.

Traceability must link automated tests to requirements/risks so coverage and gap analysis are measurable; orphan tests and uncovered high-risk requirements are reportable findings.

Continuous integration of the TAS requires deterministic test data, environment provisioning (containers/VMs), and version-controlled configuration; non-determinism is the primary cause of flaky results.

Return on automation investment is computed from saved manual execution effort, reduced cycle time, earlier defect detection, and TAS build/maintenance cost over the same period.