ISTQB CTAL-TTA key terms

A testing approach in which the identification, analysis and prioritisation of product risks guides test planning, design, execution and reporting, so effort concentrates where failure would hurt most.

The likelihood that a software product or system will suffer a failure-related harm, such as defects causing financial loss, safety issues, poor user experience or damage to reputation.

A risk affecting the management and control of a project, such as staffing shortages, unrealistic schedules, budget cuts or supplier delays, rather than the quality of the delivered product itself.

The activity of identifying risks and assessing each one's likelihood and impact, often using a matrix or scoring scheme, to determine its level and inform test prioritisation.

The combined rating of a risk derived from its likelihood and impact, used to rank risks and decide how much and what kind of testing each area should receive.

The first step of risk analysis in which stakeholders, testers and developers brainstorm and collect potential product and project risks from requirements, architecture, past defects and domain knowledge.

Actions taken to reduce either the likelihood or the impact of a risk, such as adding reviews, increasing test coverage, introducing redundancy or deferring a risky feature.

A maintained record listing identified risks with their ratings, owners, mitigation actions and status, used to track and communicate risk throughout the project lifecycle.

Ordering test conditions, cases or suites so that higher-risk areas are tested earlier and more thoroughly, ensuring that if time runs out the most important coverage is already done.

A white-box metric measuring the percentage of executable statements exercised by a test suite; it is weaker than decision coverage because it ignores untested branches.

A white-box metric requiring each decision (such as an if condition) to evaluate to both true and false at least once; it subsumes statement coverage and is also called branch coverage.

Coverage requiring every possible transfer of control out of a decision point to be taken at least once; in most code it is equivalent to decision coverage.

A white-box metric requiring each individual boolean sub-expression in a compound decision to take both true and false values at least once, without guaranteeing the decision itself takes both outcomes.

A metric requiring both decision coverage and condition coverage to be achieved, so every decision takes both outcomes and every atomic condition takes both values.

A rigorous metric requiring every possible combination of truth values for the atomic conditions within each decision to be tested at least once, giving the strongest of the common condition metrics.

A metric requiring that each atomic condition be shown to independently affect the decision outcome, achieved by holding other conditions fixed while flipping the condition under test.

The general measure of how much of a program's structure has been exercised by tests, expressed through metrics such as statement, decision, condition or path coverage.

A directed graph representing a program's possible execution paths, with nodes for basic blocks and edges for transfers of control, used to derive coverage and complexity measures.

A structural metric counting the number of linearly independent paths through a program, calculated as edges minus nodes plus two for a control flow graph; it indicates test effort and maintainability.

A white-box technique that uses cyclomatic complexity to select a set of linearly independent paths through the code so that each path introduces at least one new edge.

A white-box technique that examines where variables are defined and used, looking for anomalies such as define-use paths that are never exercised or uses before definitions.

Examination of source code, models or other artefacts without executing them, typically by tools that detect coding standard violations, suspicious patterns, unreachable code or potential security flaws.

A tool that parses code or models and reports issues such as complexity hotspots, unused variables, null dereferences or rule violations, often integrated into build pipelines for early feedback.

Analysis performed while the software executes, using instrumentation to observe runtime behaviour such as memory use, thread activity, pointer errors or performance bottlenecks.

A dynamic analysis activity in which instrumented code or tools detect defects during execution, for example memory leaks, buffer overflows, uninitialised variables or race conditions.

A dynamic analysis technique that monitors allocation and release of memory during execution to find blocks that are no longer reachable but never freed, which can degrade or crash long-running systems.

A systematic manual examination of source code by one or more people to find defects, improve maintainability and check adherence to standards, often supported by static analysis findings.

Testing of quality attributes other than functional behaviour, such as performance, security, usability, reliability and portability, verifying how well the system behaves rather than what it does.

Testing to determine how a system's responsiveness, throughput and resource use behave under specified conditions, covering load, stress, spike and endurance variants.

Performance testing that exercises the system at or near expected peak workload levels to verify it meets response time and throughput requirements under realistic demand.

Performance testing that pushes the system beyond expected limits to find the point of failure and observe how it degrades and recovers, revealing robustness problems.

Performance testing that sustains a typical or elevated load over a long period to expose problems such as memory leaks, resource exhaustion or gradual degradation.

Evaluating how effectively, efficiently and satisfactorily users can achieve goals with the product, often through observation of representative users performing realistic tasks.

The use of tools and scripts to execute tests, compare actual and expected results, and report outcomes, with the aim of repeatability, speed and freeing testers for higher-value work.

An organised set of guidelines, libraries, abstractions and tooling that structures automated tests, supporting maintainability and reuse; common types include data-driven, keyword-driven and behaviour-driven.

The collection of tools, drivers, stubs and scripts that support automated test execution, including the means to invoke the system under test and capture its outputs.

A design pattern in UI automation where each page or screen is represented by a class encapsulating its elements and actions, reducing duplication and making tests resilient to interface changes.

The comparison of benefits gained from automation, such as reduced execution time and earlier defect detection, against its costs, including tooling, scripting and maintenance effort.

A simplified stand-in for a called component that returns fixed or predefined responses, used in test harnesses to isolate the component under test when the real dependency is unavailable or unsuitable.