ISTQB CT-AT key terms

A development practice where tests are written before production code. Each cycle starts with a failing test, then code is written to pass it, followed by refactoring. It drives design and provides fast feedback.

A collaborative practice where acceptance tests are written before implementation, based on shared understanding of desired behavior. These tests guide development and confirm that the feature meets business needs.

An agile practice that extends TDD by expressing tests in natural language using Given-When-Then scenarios. It fosters collaboration between developers, testers, and business stakeholders to clarify requirements and automate acceptance checks.

A collaborative approach where team members build a shared understanding of features by illustrating them with concrete examples. These examples become the basis for acceptance tests and documentation.

Documentation that is automatically generated from executable specifications and updated continuously. It reflects the current system behavior and avoids becoming outdated like traditional static documents.

A specification written in a form that can be executed as an automated test. It serves both as a precise requirement and as a verification mechanism, ensuring the implementation matches the intended behavior.

An approach where testers simultaneously learn about the system, design tests, and execute them. It emphasizes tester autonomy, continuous learning, and using feedback from previous tests to guide further exploration.

A structured way to manage exploratory testing by dividing testing into time-boxed sessions. Each session has a charter, and results are documented to provide traceability and accountability.

A brief statement that guides an exploratory testing session. It describes what to test, why, and how, focusing on risks or areas of interest, without prescribing detailed test steps.

An approach that uses experience-based rules of thumb (heuristics) to guide test design and execution. Heuristics help testers decide what to test and how to find defects efficiently.

An approach that prioritizes testing efforts based on the likelihood and impact of potential failures. It ensures that the most critical risks are addressed first, optimizing resource use.

A model that suggests having many low-level unit tests, fewer service-level tests, and even fewer UI tests. It promotes fast feedback and maintainable automation by balancing test types.

The use of software tools to execute tests, compare actual outcomes with expected results, and report results. It aims to reduce manual effort, increase repeatability, and support frequent regression testing.

A generic term for any object that stands in for a real object during testing, such as stubs, mocks, fakes, or spies. Test doubles isolate the system under test from its dependencies.

A test double that simulates the behavior of a real object and verifies that it was called as expected. Mocks are often used to check interactions between objects.

A test double that provides canned responses to calls made during a test. Stubs are used to control the indirect inputs to the system under test and do not verify interactions.

A practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration is verified by an automated build and test process to detect integration errors early.

A software engineering approach where code changes are automatically built, tested, and prepared for release to production. It ensures that software can be released reliably at any time.

An extension of continuous delivery where every change that passes automated tests is automatically deployed to production. It requires robust automation and monitoring to minimize risk.

An automated process that builds, tests, and deploys software through a series of stages. It provides fast feedback and ensures that only quality code reaches production.

A set of automated steps that compile, test, and package software from source code. It is a core component of continuous integration and delivery, ensuring consistent and repeatable builds.

The practice of managing and provisioning computing infrastructure through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. It enables consistent and repeatable environments.

Testing at the level of APIs, where tests interact directly with the application's programming interfaces. It focuses on functionality, reliability, performance, and security of the API, often bypassing the user interface.

Testing that focuses on the services or components of a system, often at the API level. It verifies the behavior of individual services and their interactions, independent of the user interface.

Testing individual units or components of software in isolation. It is typically performed by developers using frameworks like JUnit or NUnit, and is the foundation of the test pyramid.

The process of restructuring existing code without changing its external behavior, to improve readability, maintainability, or performance. It is a key practice in agile development and TDD.

The implied cost of additional rework caused by choosing an easy solution now instead of a better approach that would take longer. It can accumulate and slow down future development if not managed.

A tool that tracks changes to source code over time, enabling collaboration and history tracking. It is essential for continuous integration and agile practices like branching and merging.

A set of guidelines, protocols, and tools used to design and manage automated tests. It provides structure, reusable components, and reporting capabilities to make automation efficient and maintainable.

A test automation approach where test cases are described using keywords that represent actions or functions. It separates test logic from implementation details, making tests easier to write and maintain.

A testing approach where test scripts read data from external sources (e.g., files, databases) to drive test cases. It allows the same test logic to be executed with multiple sets of data.

A tool that supports writing and executing BDD scenarios, typically using a domain-specific language like Gherkin. Examples include Cucumber and SpecFlow. It bridges the gap between business and technical stakeholders.

A controlled setting where tests are executed, including hardware, software, network, and data configurations. It should mimic production closely enough to produce valid results.

The process of planning, creating, and maintaining data sets for testing. It ensures that tests have access to appropriate, realistic, and secure data, often in compliance with privacy regulations.

The ongoing observation of a live system's health and performance using tools that collect metrics, logs, and alerts. It helps detect issues quickly and supports continuous deployment.

A deployment pattern where a new version is rolled out to a small subset of users before being deployed to everyone. It allows testing in production with limited risk.

A deployment strategy with two identical environments (blue and green). At any time, one is live and the other is idle. New releases are deployed to the idle environment, tested, and then traffic is switched.