ISTQB CTAL-ATT flashcards

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

Verifiable requirement

A requirement is verifiable when a test can objectively confirm whether it is met, typically because it states a measurable threshold, an observable behavior, or an unambiguous condition.

INVEST criteria

A checklist for user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable. Stories failing a criterion are reworded or split before entering a sprint.

Acceptance criteria

Conditions a story must satisfy to be accepted by the business. Written as rule checklists or Given/When/Then scenarios, they become the basis for acceptance tests.

Decision table testing

A specification-based technique for requirements combining several conditions. Columns list condition combinations and expected actions; each feasible column yields at least one test case.

Boundary value analysis

A technique selecting values at and around the edges of an equivalence partition, such as minimum, minimum minus one, maximum, and maximum plus one, where defects cluster.

Requirements traceability matrix

A table mapping each requirement to design elements, test cases, and defects. Bidirectional tracing reveals uncovered requirements and test cases with no requirement basis.

Definition of Ready

A team agreement listing what a backlog item needs before sprint planning: clear value, agreed acceptance criteria, testability, sizing, and resolved dependencies.

Ambiguity review heuristics

Review checks targeting untestable wording: missing actor in passive sentences, undefined pronouns, comparatives without a baseline, and absolutes lacking stated conditions.

Test quadrants

A model classifying tests by business versus technology focus and by supporting the team versus critiquing the product, guiding which test types a team plans.

Test pyramid

A guideline favoring many fast unit tests, fewer service-level tests, and few UI tests, because lower levels give faster feedback and cheaper maintenance.

Three Amigos

A short pre-development session where business, development, and testing perspectives review a story to surface assumptions and agree on examples and acceptance criteria.

ATDD cycle

Acceptance-test-driven development: discuss examples with stakeholders, distill them into executable acceptance criteria, then develop code until those tests pass.

Session-based exploratory testing

Exploratory testing structured by a charter and a timebox, usually 60 to 120 minutes, documented with coverage notes, defects, and issues, followed by a debrief.

Whole-team quality

The agile principle that all roles share responsibility for quality; testers contribute testability advice, examples, and tooling rather than acting as a final gate.

Definition of Done

A shared checklist a story must satisfy to count as complete, typically including code review, automated tests passing, and acceptance criteria demonstrated.

Risk-based test prioritization

Ordering test effort by product risk, calculated as likelihood of failure multiplied by impact, so the highest-risk items are tested and automated first.

Continuous integration

A practice where every commit triggers an automated build and test run, and a failing build is fixed before further changes are merged.

Page Object pattern

An automation design pattern encapsulating a page's locators and operations in one class, so UI changes are absorbed in a single place instead of many tests.

Screenplay pattern

An automation pattern modeling actors who perform tasks built from interactions, giving readable, composable tests with reusable, low-coupling step libraries.

Test adaptation layer

The part of a test automation architecture that connects test cases to the system under test through interfaces and tools, isolating tests from technology changes.

Automation ROI

The return from automating a test, driven by execution frequency, expected lifespan, feature stability, manual execution cost, and ongoing maintenance cost.

Flaky test

A test producing different results on unchanged code, usually from timing, shared state, or environment issues. It must be quarantined and root-caused, not just re-run.

Test data independence

A property of automated tests whereby each test creates or selects its own data, so results do not depend on execution order or on other tests' side effects.

Test automation solution tests

Tests and reviews applied to the automation code itself, including unit tests of helpers, code review, and version control, treating automation as production code.

Single locator ownership

The rule that each UI element locator is defined in exactly one place, so a UI change requires one edit and cannot leave stale duplicates in the suite.

Deployment pipeline

An automated sequence of build, test, and deployment stages with quality gates, moving a change from commit toward production with fast feedback at each stage.

Continuous delivery

A practice keeping software in a releasable state at all times, with automated testing and deployment to staging, while the production release remains a manual decision.

Continuous deployment

An extension of continuous delivery in which every change passing all automated gates is deployed to production automatically, without a manual release step.

Feature toggle

A configuration switch that enables or disables functionality at runtime, decoupling deployment from release and supporting dark launches and quick disablement.

Canary release

A deployment strategy routing a small share of traffic to the new version while monitoring error rates and metrics, expanding traffic only if behavior is acceptable.

Blue-green deployment

A strategy running two identical environments, switching live traffic from blue to green after verification, which allows near-instant rollback by switching back.

Shift-right testing

Testing and monitoring performed in production after release, including observability, synthetic transactions, and controlled experiments, to catch issues real users encounter.