I85PREP
⌘ K
ISTQB CT-AT study materials
ISTQB CT-AT study resources

ISTQB CT-AT: Test Automation Approaches

ISTQB CT-AT · Work through your exam, one topic at a time.

All guide sections

Test Automation Approaches

This domain, test automation approaches, tests whether you can design a maintainable automation solution rather than a pile of scripts. Questions cover strategy, the automation pyramid, architecture layers, framework styles, design patterns, tool selection, metrics and continuous integration fit.

Core rules

  • Strategy before tools. Define scope, risks, test levels, environments, data and ownership; automate stable, valuable, repeatable checks first.
  • Test automation architecture commonly separates test generation, test definition, test execution and test adaptation (harness/drivers), with reporting and logging across layers. Keep test logic, data and locators separate.
  • Framework styles: linear (record/playback), modular, data-driven, keyword-driven, hybrid and model-based. BDD tools add a business-readable layer but still need good engineering.
  • Patterns: Page Object and Screenplay isolate UI interaction; Factory/Builder create data; Singleton is used sparingly because it hides dependencies.
  • Tool selection considers technology fit, skills, cost, vendor support, CI/ALM integration and a proof of concept. Metrics include coverage, execution time, flakiness, maintenance effort and defects found - not test-case counts.
  • Flaky tests usually come from timing, order dependency, shared data or unstable environments. Fix or quarantine them; never normalise reruns.

Worked example

A suite of 300 UI tests takes six hours and 20% are flaky. Reasoning: inspect the pyramid first - move business-rule checks to API/service tests, keep a small critical UI path, introduce Page Objects, data-driven login cases, explicit waits and parallel execution. Run unit and API tests on every commit; run UI smoke on merge and full regression nightly. Expected outcome: minutes-level feedback, fewer false failures, lower maintenance.

Traps

Tool-first adoption; record/playback at scale; no version control for test code; measuring success by number of automated cases; hard-coded sleeps; shared test data; treating all tests as equally urgent in the pipeline.