ISTQB CT-AT flashcards

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

Three amigos

A short pre-development conversation among business, development, and testing perspectives to agree on examples and acceptance criteria, exposing ambiguity and missing requirements before code is written.

ATDD

Acceptance Test-Driven Development: acceptance tests are created collaboratively from acceptance criteria before implementation, then automated and used to confirm the story is complete.

BDD Given/When/Then

A specification format where Given sets the initial context, When is the action or event, and Then is the expected outcome; scenarios become executable acceptance tests.

TDD red-green-refactor

A cycle of writing a failing test (red), writing minimal code to pass it (green), then improving design while keeping tests green; tests drive design and provide regression safety.

Exploratory testing session

A time-boxed, charter-driven activity combining learning, test design, and execution, followed by a debrief that records coverage, defects, and areas needing further testing.

Equivalence partitioning

A black-box technique dividing inputs into classes expected to be handled the same way; one representative value per class is tested, reducing cases without losing coverage.

Boundary value analysis

A black-box technique testing values at and adjacent to the edges of equivalence classes, such as minimum, minimum-1, maximum, and maximum+1, where defects cluster.

Decision table testing

A technique tabulating combinations of conditions and their expected actions; it exposes gaps and contradictions in business rules that involve interacting conditions.

State transition testing

A technique modeling states, events, and transitions; it derives tests for valid transitions, invalid transitions, and paths, suited to status-driven or workflow behavior.

Decision coverage

A white-box measure requiring each decision to take both true and false outcomes at least once; it subsumes statement coverage but does not guarantee all conditions are exercised.

Test automation pyramid

A distribution guideline with many fast unit tests, fewer service or API tests, and few slow UI tests, balancing feedback speed against confidence in end-to-end behavior.

Page Object Model

A design pattern where each screen or component is represented by a class encapsulating its locators and actions, so test logic stays stable when the UI changes.

Keyword-driven framework

An automation framework where test steps are written as keywords in data files and interpreted by a driver, letting non-programmers define tests and separating logic from data.

Data-driven testing

An approach where one test script is executed repeatedly with different input and expected-output data sets, typically held externally, increasing coverage with less duplicated code.

Flaky test

A test producing different results on unchanged code, usually from timing, shared state, or unstable data; it must be quarantined and root-caused because it erodes trust in automation.

Automation ROI criteria

Automation is justified when checks are repeated often, stable, time-consuming manually, high risk, or needed for fast feedback; one-off or volatile checks usually are not.

Test automation strategy

A documented plan covering scope, tool selection criteria, architecture, test data, environments, roles, metrics, and maintenance, aligned with product risks and the delivery pipeline.

Continuous integration

A practice where every code change triggers an automated build and test run, giving fast feedback on integration defects and keeping the mainline in a working state.

Continuous delivery

A practice keeping the product in a state where any passing build can be released to production on demand; release is a business decision, not a technical bottleneck.

Continuous deployment

An extension of continuous delivery where every change passing all automated pipeline gates is deployed to production automatically, without a manual release decision.

Deployment pipeline

An automated sequence of build and test stages, ordered to fail fast, that takes a commit to a releasable artifact and provides evidence of quality at each gate.

Shift left

Moving testing and quality activities earlier in the lifecycle, such as reviews, static analysis, and unit tests, so defects are found when they are cheapest to fix.

Shift right

Extending testing into production using monitoring, canary releases, A/B testing, and telemetry, so real usage reveals risks that pre-release environments cannot reproduce.

Feature toggle

A configuration switch enabling or disabling functionality without redeployment, decoupling deployment from release; toggles accumulate debt and require coverage of both states.

Blue-green deployment

A release technique running two identical environments and switching traffic to the new one after verification, enabling near-instant rollback by switching back.

Canary release

A release technique exposing a new version to a small subset of users while monitoring errors and metrics, then progressively expanding traffic if behavior is acceptable.

Rollback testing

Verifying that reverting to the previous version restores service, including database migration reversibility, configuration compatibility, and handling of data written by the new version.

Static analysis

Examination of code or models without execution, detecting standards violations, complexity, data-flow issues, and security patterns; it cannot replace runtime testing.

Formal inspection

The most rigorous review type, with defined roles, entry and exit criteria, preparation, logging, and follow-up; it is used for high-risk artifacts and can measure defect density.

Consumer-driven contract testing

Consumers define expected provider interactions as contracts; providers verify them, detecting interface mismatches early without fragile end-to-end environment setups.

Test data management

Planning, generating, masking, and cleaning data so tests are repeatable and independent; using unmasked production data risks privacy breaches and non-reproducible results.

Whole-team quality ownership

In Agile, all team members share responsibility for quality; testers contribute test design expertise and coach others rather than acting as a separate final gate.