ISTQB CTAL-TA key terms

A possible event or condition related to the software product that could cause harm to stakeholders, such as failure to meet needs or a defect in production.

An approach that prioritizes test activities and effort according to the level of product risk, so the most significant risks are tested first and most thoroughly.

The activity of identifying, analyzing, and evaluating risks to decide their levels and significance, providing the basis for selecting what to test.

Examining identified risks by estimating their likelihood and impact in order to assign risk levels and decide how much testing each risk needs.

A rating, often based on likelihood and impact, that indicates how serious a risk is and helps determine the priority and depth of testing.

Actions taken to reduce either the likelihood or the impact of a risk, such as adding tests, reviews, or design changes.

The ongoing management of risks by selecting and applying mitigation actions, then tracking whether those actions reduce risk as intended.

The set of documents and knowledge, such as requirements, designs, and user stories, used as the source for identifying test conditions and designing tests.

A specific aspect of the test basis that is relevant to testing, such as a function, rule, or quality attribute, and that will be covered by test cases.

The test activity that examines the test basis to identify test conditions and decide what should be tested, before test cases are designed.

The test activity that turns test conditions into test cases and other testware, using techniques and coverage criteria to select the most valuable tests.

A black-box technique that divides inputs or outputs into groups expected to behave similarly, so one value from each group can represent the whole group.

A black-box technique that tests values at the edges of equivalence partitions, including boundary and adjacent values, because defects often occur at those edges.

A technique that models combinations of conditions and the actions that result, then derives test cases to cover the business rules represented in the table.

A technique that models a system as states and transitions triggered by events, then designs tests to cover valid and invalid transitions and state sequences.

A combinatorial test design technique that selects test cases so every possible pair of values from any two parameters is included at least once.

An experience-based approach where the tester simultaneously learns about the system, designs tests, and executes them, often guided by a written charter.

The percentage or degree to which defined coverage items, such as partitions, rules, or transitions, are exercised by the test cases that have been designed or run.

A category of software quality, such as usability, security, or performance efficiency, defined in ISO/IEC 25010 to describe product attributes that can be tested.

The quality characteristic describing how well software provides functions that satisfy stated and implied needs when used under specified conditions.

The quality characteristic describing how well software uses resources and delivers acceptable response times and throughput under stated conditions and workloads.

The quality characteristic describing how effectively, efficiently, and satisfactorily users can achieve their goals in a specified context of use.

Testing that checks whether software can be used by people with diverse abilities, including those using assistive technologies such as screen readers or keyboard navigation.

Testing that assesses whether software protects information and functions from unauthorized access, use, disclosure, disruption, modification, or destruction.

The quality characteristic describing how well software performs specified functions under stated conditions for a specified period, including availability and fault tolerance.

The quality characteristic describing how well a product performs its functions while sharing an environment or resources with other products.

A static evaluation of a work product by one or more people who examine it to find defects, ambiguities, and improvements, often before the product is tested dynamically.

A review type in which the author leads reviewers through a work product, explaining it and seeking feedback, mainly to build shared understanding and find defects.

A documented review performed by technically qualified reviewers who examine a work product against technical criteria, such as standards, specifications, or design principles.

The most formal review type, following a defined process with assigned roles, entry and exit criteria, and metrics, to find defects systematically.

The review role responsible for planning the review, leading meetings, keeping the team focused, and ensuring the review process is followed effectively.

A review technique in which each reviewer examines a work product from a particular stakeholder viewpoint, such as tester or designer, to find different types of defects.

The process of recording, classifying, prioritizing, tracking, and resolving defects, and of reporting on their status throughout the project.

A document that describes a defect with enough detail, such as steps, environment, and expected versus actual results, for others to understand, reproduce, and fix it.

The degree of impact that a defect has on the system or its users, such as loss of data or minor display problems, usually assessed independently of fix scheduling.

The order or urgency assigned to fixing a defect, based on business needs, project constraints, and stakeholder concerns rather than only on technical impact.

A meeting or process in which defects are reviewed and assigned severity, priority, ownership, and a decision about whether and when to fix them.

The sequence of states a defect moves through from discovery to closure, such as new, assigned, fixed, retested, and closed, including possible reopening.