ISTQB CTAL-TTA flashcards

33 cards. Read the term and the definition here. The deck at the top of this page is optional.

Product risk

A risk that the test object itself may fail to satisfy a quality characteristic or stakeholder need. It is assessed by likelihood and impact to prioritize test effort.

Project risk

A risk related to managing and controlling the test project, such as schedule slippage, insufficient skills, tooling failure, or unclear requirements. It is handled by test management.

Risk level formula

Risk level is computed as likelihood of occurrence multiplied by impact (consequence). Scores are ranked to decide test depth, technique choice, and coverage targets.

Residual risk

The risk that remains after planned test activities are complete. It is reported to stakeholders so they can make an informed release or acceptance decision.

Risk-based regression selection

Regression test cases are selected by the risk of change impact and business criticality of the affected functions, rather than by test age or execution convenience.

Risk mitigation via testing

Testing mitigates product risk by choosing techniques, coverage levels, review intensity, and tester independence proportional to the assessed risk level of each requirement or feature.

Statement coverage

The percentage of executable statements exercised by a test suite. It is the weakest structural criterion and does not guarantee that every decision outcome has been exercised.

Decision coverage

Every decision in the code is exercised with both a true and a false outcome at least once. Decision coverage subsumes statement coverage.

Condition coverage

Every atomic condition within a decision is exercised with both true and false values at least once. It does not require both decision outcomes to be exercised.

MC/DC

Modified condition/decision coverage requires each atomic condition to independently affect the decision outcome while all other conditions are held fixed, plus both decision outcomes exercised.

Cyclomatic complexity

V(G) = E − N + 2 for a control flow graph, or decision points + 1. It equals the number of linearly independent paths through the code.

Basis path testing

A white box technique that derives a set of linearly independent paths equal to the cyclomatic complexity and designs at least one test case for each path.

All-defs coverage

A data flow coverage level requiring every definition of a variable to be reached by at least one path to some use of that variable.

Definition-use pair

A pairing of a point where a variable is defined (assigned) with a later point where that definition is used, either in a computation or a predicate.

Static analysis

Examination of code, models, or specifications without executing them. It detects coding standard violations, unreachable code, unused variables, and suspicious data flow patterns.

Dynamic analysis

Analysis performed by executing instrumented code to observe runtime behavior. It detects memory leaks, unassigned pointers, pointer arithmetic errors, and array bound violations.

Data flow anomaly

A suspicious pattern in variable usage such as defined but never used, used before definition, or defined twice without an intervening use. Static analysis can detect these.

False positive in static analysis

A reported violation that is not an actual defect. Findings must be triaged and reviewed before being logged as defects.

Unreachable code

Code that cannot be executed on any control flow path, for example statements after an unconditional return or jump. Static analysis detects it without execution.

Static versus dynamic cost

Static analysis is applied early and is generally more cost-effective per defect for the classes it detects; dynamic analysis requires executable code and adds instrumentation overhead.

Load testing

Non-functional testing that exercises the system at expected or anticipated load levels to verify performance requirements such as response time and throughput.

Stress testing

Testing beyond expected load limits, or with reduced resources, to determine the system's limits and how it fails and recovers under overload.

Spike testing

Testing with sudden, sharp increases and decreases in load to observe how the system handles abrupt changes in demand and whether it recovers.

Endurance testing

Sustained load testing over an extended period to reveal problems such as memory leaks, resource depletion, and degradation of response times over time.

ISO 25010 characteristics

A product quality model including functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability, used to structure non-functional testing.

Performance efficiency

An ISO 25010 characteristic with sub-characteristics time behavior, resource utilization, and capacity. Each needs measurable acceptance criteria for performance testing.

Reliability sub-characteristics

ISO 25010 reliability comprises maturity, availability, fault tolerance, and recoverability. Each can be targeted by specific non-functional test types and metrics.

Usability testing

Testing that evaluates effectiveness, efficiency, satisfaction, and freedom from risk in a specified context of use, often involving representative users and realistic tasks.

Test automation ROI

Return on investment depends on initial investment, ongoing maintenance cost, execution frequency, and the lifetime of the test object. Frequently run, long-lived tests pay back fastest.

Test automation pyramid

A model favoring many fast unit tests, fewer service or API tests, and few fragile UI tests, reflecting relative execution cost and maintenance effort.

Page Object Model

A design pattern in which each UI page or component is represented by a class encapsulating its locators and actions, reducing duplication and maintenance when the UI changes.

Keyword-driven testing

A framework approach where test cases are expressed as sequences of keywords with data, separated from the implementation of the keywords, improving readability and reuse.

Automated test false positive

A test that reports a pass when the condition it checks is actually violated. It undermines trust in the suite and requires verification of the test itself.