ISTQB CTAL-TM key terms

A long-lived, generic description of how testing is generally organized and performed across an entire organization, independent of any single project. It provides reusable rules, standards, and practices from which project-level test approaches are derived.

A short, high-level statement of an organization's overall aims, principles, and intent regarding testing. It sits above the organizational test strategy and gives direction without prescribing detailed practices or techniques.

The concrete implementation of testing for one specific project or release. It selects starting point, techniques, levels, and exit criteria to fit that project's context, risks, and constraints, and is documented in the test plan.

Adapting the organizational test strategy to the specific context of a project, such as its risk profile, lifecycle model, technology, and regulatory constraints. Tailoring justifies deviations rather than applying organizational rules blindly.

A framework describing staged levels of testing capability, from ad hoc practice to continuously optimized and measured processes. Organizations use it to benchmark current practice and plan improvement steps with defined entry criteria per level.

A structured, cyclic effort to raise the effectiveness and efficiency of testing, typically by assessing current practice, selecting prioritized improvements, implementing them, and measuring the outcome before repeating.

The defined responsibilities within a test organization, such as test manager, test leader, test analyst, and technical test analyst. Clear role definition prevents gaps and overlaps in accountability across the test process.

The role accountable for planning, monitoring, controlling, and reporting test activities, and for leading the test team and engaging stakeholders. The role focuses on management concerns rather than designing individual test cases.

A combination of knowledge, skills, and behavior needed to perform a testing task well, for example risk analysis, test design, communication, or tool use. Competencies are assessed and developed to match task demands.

A grid mapping team members against required competencies, showing current proficiency and gaps. Test managers use it to plan training, assignments, and recruitment, and to identify single points of failure in the team.

The set of management actions that sustain team engagement and commitment, such as clear goals, recognition, autonomy, fair workload, and development opportunities. Motivation strongly influences defect detection and retention.

Testing performed by team members or teams located in different places or time zones, or outsourced to another organization. It raises challenges in communication, handover, shared tooling, and consistent process adherence.

A development practice in which a failing automated test is written before production code, then code is written to pass it and refactored. Tests thereby drive design and provide a continuously growing regression safety net.

A collaborative practice where examples of desired behavior are written in structured natural language before implementation. These examples become executable acceptance tests and improve shared understanding among business, development, and testing.

The conditions a work item must satisfy to be accepted by its stakeholders. They define scope for testing and are typically expressed as concrete examples or checklist items agreed before development begins.

An agreed checklist stating what must be true for a work item to be considered complete, often including review, testing, and documentation. It prevents work from being counted as finished while quality activities remain outstanding.

A regular team reflection at the end of an iteration or milestone examining what went well, what did not, and what to change. Test managers use it to adapt test processes and team practices based on evidence.

Moving testing and quality activities earlier in the lifecycle, for example reviewing requirements or writing tests before coding. Earlier defect detection usually lowers cost and shortens feedback loops.

A practice where developers merge code frequently into a shared mainline, with automated build and test runs on each change. It provides rapid feedback on integration defects and keeps the codebase releasable.

A document or record describing scope, objectives, approach, resources, schedule, risks, and exit criteria for test activities. It guides control and communication and is updated as context changes.

Conditions that must be met before a test activity can reasonably begin, such as approved requirements, a stable build, or available test environment. Unmet criteria signal risk and justify a formal go or no-go decision.

Agreed conditions for declaring a test activity or level complete, such as coverage thresholds, defect closure rates, or residual risk acceptance. They support objective decisions about releasing or stopping testing.

Predicting the effort, duration, and resources needed for test activities using techniques such as expert judgment, analogy, or metrics-based models. Estimates are revisited as actual data accumulates.

The ongoing collection of data about test execution, defect status, coverage, and effort against plan. It provides the factual basis for control decisions and for reporting to stakeholders.

Taking corrective action when monitoring shows deviation from plan, for example reprioritizing tests, reallocating people, adjusting scope, or changing exit criteria with stakeholder agreement. Control turns measurement into decisions.

A structured communication of test status and results to stakeholders, covering progress, coverage, defects, risks, and recommendations. Reports vary in depth from daily dashboards to formal test completion summaries.

A quantitative measure used to track testing, such as defect density, test execution rate, or requirement coverage. Metrics must be interpreted in context and chosen to support decisions rather than to impress.

A project control technique comparing planned value, earned value, and actual cost to assess schedule and budget performance. Test managers can apply it to test effort and progress against the test plan.

Any person or group with an interest in test activities or their results, such as product owners, developers, operations, auditors, and customers. Their needs and influence shape communication and reporting.

An agreed description of who receives which test information, in what form, and how often. It prevents both information overload and dangerous silence by matching reporting to each stakeholder's decisions.

The likelihood and impact of a product failing to meet stakeholder needs or causing harm. Product risks drive test prioritization, technique selection, and the depth of coverage applied to each area.

Allocating test effort and rigor in proportion to analyzed product risks, so that high-risk areas receive early, deeper, and more varied testing. It aligns testing with what matters most to the business.

Identifying risks and assessing their likelihood and impact, often using workshops or checklists. The resulting risk levels guide test planning, prioritization, and the choice of mitigation activities.

Actions taken to reduce the likelihood or impact of a risk, such as additional testing, reviews, contingency planning, or scope reduction. Residual risk remains after mitigation and must be accepted explicitly.

The risk that remains after mitigation activities have been applied. It must be communicated to decision makers, who formally accept it when approving a release or ending test activities.

The process of recording, classifying, prioritizing, tracking, and resolving defects, including agreed workflows and status models. Effective defect management preserves information for analysis and prevents duplicate or lost reports.

A regular meeting where reported defects are reviewed to confirm validity, assign severity and priority, and decide on handling. Triage keeps the defect backlog meaningful and aligned with current risk.

Two separate attributes of a defect: severity describes the impact on the product, while priority describes how urgently the business wants it fixed. They often differ and should be assigned independently.

A technique for tracing defects back to underlying process or technical causes rather than individual symptoms. Findings feed process improvement and prevent recurrence of similar defects.