CAT key terms

A short 2001 statement of four values and twelve principles that prioritizes individuals, working software, customer collaboration, and responding to change over rigid process, documentation, contracts, and fixed plans.

Building a product in short repeated cycles, each adding a small slice of functionality, so feedback arrives early and risk is reduced compared with one big delivery at the end.

The accumulated, potentially shippable product functionality produced by the end of an iteration; each increment builds on earlier ones and should meet the team's agreed definition of done.

A fixed-length iteration, commonly one to four weeks, during which a Scrum team turns selected backlog items into a usable increment and holds its own ceremonies.

An ordered, evolving list of everything the team might build, expressed as user stories or other items, prioritized by value, risk, and dependency, and refined continuously rather than frozen.

The ongoing activity of clarifying, splitting, estimating, and reordering backlog items so that upcoming work is small enough, understood well enough, and testable before it enters an iteration.

A short description of a desired capability written from a user's perspective, usually as role, goal, and benefit, that acts as a placeholder for a conversation rather than a full specification.

The conditions a user story must satisfy to be accepted by the customer or product owner; they guide development, define test expectations, and support agreement on scope before coding starts.

A shared team checklist describing the quality conditions every increment must meet, such as reviewed code, passing automated tests, and documentation, so that 'done' is not subjective.

The practice of involving testers, developers, business representatives, and others together in planning, specification, and review so quality is owned by everyone rather than delegated to a separate test group.

A short collaboration session among business, development, and testing perspectives to explore a story, expose assumptions and edge cases, and agree examples before implementation begins.

A technique that captures requirements as concrete, realistic examples with expected outcomes, which then become the basis for acceptance tests and shared understanding across the team.

An approach that expresses desired behavior in structured natural-language scenarios using given, when, then form, so business stakeholders, developers, and testers share one readable specification.

Writing acceptance tests from agreed criteria before implementation, then building code until those tests pass, so that scope and expected behavior are fixed by examples rather than by prose.

A developer practice of writing a failing unit test first, then the minimum code to pass it, then refactoring; it produces a safety net of automated tests and drives design.

A guideline showing many fast low-level unit tests, fewer service or integration tests, and very few slow user-interface tests, to balance feedback speed, cost, and confidence.

Simultaneous learning, test design, and execution in which the tester uses knowledge and intuition to probe the product, often time-boxed and guided by charters rather than fixed scripts.

A way to structure and report exploratory testing using time-boxed sessions with a charter, notes, and a debrief, making unscripted work visible, measurable, and accountable.

Selecting, prioritizing, and depth-adjusting test activities according to the likelihood and impact of failure, so limited time is spent where product risk is greatest.

The chance that the delivered product fails to meet stakeholder needs, for example through defects, poor usability, security weakness, or performance limits; it drives test prioritization.

Re-executing selected tests after changes to confirm that existing behavior still works; in agile it is usually automated and run continuously because change is frequent.

Frequently merging each developer's work into a shared mainline and running automated build and test checks on every change, so integration defects surface within minutes rather than weeks.

Keeping the product in a state where any passing build could be released to users at short notice, supported by automated testing, deployment pipelines, and configuration management.

An automated sequence of build, test, and environment stages that moves a change toward release, failing fast and giving fast feedback on quality at each stage.

The accumulated cost of shortcuts in design, code, or tests that makes future change slower or riskier; it must be made visible and repaid deliberately.

Improving the internal structure of code or tests without changing external behavior, performed safely because an automated test suite quickly reveals any accidental breakage.

A fast, isolated automated test that checks a small piece of code, such as a function or class, usually written and maintained by developers as part of test-driven development.

The amount of backlog work a team completes per iteration, often measured in story points; it supports forecasting and planning but is not a productivity score for comparing teams.

A relative unit used to size backlog items by effort, complexity, and uncertainty rather than elapsed time, enabling estimation before detailed design exists.

A consensus estimation technique in which team members privately choose cards representing relative sizes, then discuss differences until agreement emerges, reducing anchoring by senior voices.

Agreeing which increments and features will be delivered in an upcoming release, based on priority, estimated size, capacity, and the quality level required for launch.

A team leadership style in which the leader removes obstacles, protects focus, and coaches rather than directs; common in Scrum masters and agile test leads.

A team that decides for itself how to divide and perform work, within agreed goals and constraints, rather than waiting for a manager to assign tasks and methods.

A regular team meeting to inspect how work was done, identify what helped or hindered quality and collaboration, and commit to a small number of concrete improvements.

A tester collaborates on stories and criteria, designs and automates checks, explores for risks, interprets results, and advocates for quality, rather than acting as a gatekeeper at the end.

A test suite shape with many slow manual or user-interface tests and few unit tests, producing slow feedback, brittle automation, and high maintenance cost.

A model that classifies tests by whether they support the team or critique the product and whether they are business-facing or technology-facing, helping a team balance its test portfolio.