Continuous Testing Foundation key terms

The practice of running automated checks throughout the delivery pipeline so that feedback on quality arrives continuously, rather than in a single phase near release.

Moving testing and quality activities earlier in the lifecycle, so defects are caught during design, coding, and build instead of after deployment.

A cultural and technical movement that unites development and operations teams around shared goals, automation, and rapid, reliable delivery of value to users.

Using tools and scripts to execute checks, compare actual results with expected ones, and report outcomes without manual intervention, enabling repeatable and frequent verification.

A model that recommends many fast unit tests, fewer service or integration tests, and a small number of slow end-to-end UI tests to balance speed and confidence.

A fast, isolated check of a single function, method, or class, usually written by developers and run on every code change.

A check that verifies how two or more components, services, or systems work together, including their interfaces, data contracts, and error handling.

A test that exercises a complete user workflow across the real system, from interface through all integrated layers, to confirm the whole chain behaves correctly.

A check that confirms previously working behavior still works after a change, protecting against unintended side effects in existing functionality.

A quick, shallow set of checks that confirms a build is stable enough to justify deeper testing, often run right after deployment.

A narrow check focused on a specific fix or change to confirm it behaves as intended before broader regression testing proceeds.

A coding approach in which a developer writes a failing test first, then writes just enough code to pass it, then refactors while keeping all tests green.

A collaboration practice where business, development, and testing stakeholders express expected behavior as concrete examples in plain language that can be automated as acceptance tests.

A check that confirms a feature satisfies agreed business criteria, often derived from user stories and used to decide whether work is complete.

A shared team agreement listing the conditions a work item must satisfy, including testing and quality criteria, before it can be considered complete.

An automated sequence of build, test, and deployment stages that moves code from commit toward production, giving fast feedback at each stage.

A practice where developers merge small changes into a shared mainline frequently, with each merge triggering automated build and test runs.

A practice that keeps software in a releasable state at all times, with every change passing automated verification so release becomes a routine business decision.

An automated checkpoint in the pipeline that evaluates defined criteria, such as test pass rates or coverage thresholds, and blocks promotion when they are not met.

A high-level description of how quality will be achieved, covering scope, risk-based priorities, environments, automation approach, roles, and reporting for a product or program.

A concrete document or record describing the specific scope, schedule, resources, environments, and entry and exit criteria for a particular testing effort.

Prioritizing test effort according to the likelihood and business impact of failure, so the most dangerous areas receive the deepest and earliest coverage.

Preconditions that must be satisfied before a test phase or activity starts, such as a stable build, available environment, and approved test data.

Conditions agreed in advance that must be met to declare a test phase complete, such as target pass rates, coverage levels, and no open critical defects.

The controlled creation, provisioning, masking, and cleanup of data used by tests, so results are repeatable and sensitive information stays protected.

Simulating dependent systems that are unavailable, costly, or unreliable so that tests can run predictably and independently of external components.

The configured combination of hardware, software, networks, and data on which tests execute, ideally managed as code and kept close to production parity.

Managing servers, networks, and environments through versioned configuration files so they can be created, rebuilt, and replicated consistently and automatically.

A test that passes and fails inconsistently on unchanged code, usually due to timing, shared state, or environment issues, eroding trust in automation.

The degree to which automated tests produce the same result under the same conditions, a prerequisite for using test outcomes as release decisions.

An organized collection of test cases grouped for a purpose, such as a regression suite or a smoke suite, that is executed and reported together.

Ordering tests so the highest-value checks run first, maximizing feedback speed when time or compute capacity is limited.

Choosing which tests to run for a given change, often by analyzing code impact, to cut pipeline time while retaining meaningful coverage.

A measure of how much source code is exercised by tests, commonly reported as statement, branch, or line percentages, useful as a signal rather than a goal in itself.

Quantitative indicators such as pass rate, defect escape rate, coverage, and cycle time that show whether testing is effective and where to improve.

The share of defects found after release compared with all defects found, indicating how well pre-release testing prevented problems from reaching users.

Simultaneous learning, test design, and execution in which a skilled tester probes the product without pre-scripted steps, guided by risk and observation.

Structuring exploratory testing into time-boxed sessions with a clear charter and recorded notes, making unscripted work measurable and reviewable.

A structured review after an incident that focuses on systemic causes and process improvements rather than individual fault, feeding lessons back into testing.