ISTQB CTAL-TTA cheat sheet

Risk level = likelihood of occurrence × impact (probability × consequence); rank product risks to allocate test effort and depth.

Product risk concerns quality characteristics of the test object; project risk concerns management and control of the project (schedule, staffing, tooling).

Risk-based testing is a continuous activity: identify, assess, mitigate via test design/execution, then re-evaluate as information changes.

PRISMA or similar techniques use likelihood and impact factors scored on scales; the product of the factors gives the risk class.

Pareto principle: a small proportion of risk items typically accounts for most defect-caused failures; coverage of high-risk items is prioritized.

Risk mitigation includes choosing test techniques, coverage levels, independence of testers, and review intensity proportional to risk.

Residual risk is the risk remaining after testing; it must be communicated to stakeholders for release decisions.

Risk-based regression testing selects test cases by risk of change impact and business criticality, not by test age or convenience.

Statement coverage: percentage of executable statements exercised; it is the weakest structural coverage criterion and does not guarantee decision coverage.

Decision (branch) coverage requires each decision outcome (true and false) to be exercised at least once; it subsumes statement coverage.

Condition coverage exercises each atomic condition to both true and false but does not require decision outcomes to be exercised.

Decision-condition coverage requires both decision outcomes and each atomic condition's true/false values to be exercised.

MC/DC requires each atomic condition to independently affect the decision outcome while all other conditions are held fixed.

Cyclomatic complexity V(G) = E − N + 2 (edges − nodes + 2), or number of decision points + 1; it equals the number of linearly independent paths.

Basis path testing derives a set of linearly independent paths equal to V(G) and designs at least one test per path.

Data flow testing uses definitions (defs) and uses (c-uses, p-uses); all-defs, all-uses, and all-du-paths are coverage levels of increasing strength.

Loop testing applies minimum, maximum, and one-beyond-maximum iteration counts, plus skipped-loop and interior-path variants.

Static analysis examines code or models without execution; dynamic analysis executes code, typically instrumented, to observe runtime behavior.

Static analysis detects violations of coding standards, unreachable code, unused variables, and suspicious data flow patterns before test execution.

Control flow anomalies detectable statically include unreachable code, multiple exits from a loop, and unconditional jumps into loop bodies.

Data flow anomaly: a variable defined but never used (dead), used before definition (undefined), or defined twice without intervening use.

Dynamic analysis detects memory leaks, unassigned pointers, pointer arithmetic errors, and array bound violations during execution.

Static analysis produces false positives; findings must be reviewed and triaged, not treated as confirmed defects.

Static analysis is applied early in the lifecycle and is more cost-effective per defect than dynamic detection of the same class.

Dynamic analysis tools instrument code and add overhead, so they are typically run on selected builds or test environments.

Performance testing types: load (expected load), stress (beyond limits), spike (sudden load change), endurance/soak (sustained load), scalability (increasing load).

ISO 25010 quality characteristics include performance efficiency, reliability, security, compatibility, usability, and maintainability.

Performance efficiency sub-characteristics: time behavior, resource utilization, and capacity.

Reliability sub-characteristics: maturity, availability, fault tolerance, and recoverability.

Usability testing evaluates effectiveness, efficiency, satisfaction, and freedom from risk in a specified context of use.

Security testing targets confidentiality, integrity, authentication, authorization, non-repudiation, and availability.

Non-functional tests need measurable acceptance criteria (e.g., 95th percentile response time, throughput, error rate) defined before execution.

Load test results must be analyzed with monitoring data (CPU, memory, I/O, network) to distinguish application bottlenecks from environment limits.

Test automation is the use of software to perform or support test activities; it does not replace test design or judgment.

Automation ROI depends on initial investment, maintenance cost, execution frequency, and lifetime of the test object.

The test automation pyramid favors many unit tests, fewer service/API tests, and few UI tests, reflecting cost and fragility.

A test automation architecture separates test cases, test logic (keywords/actions), and test harness/drivers for maintainability.

Design patterns: Page Object Model encapsulates UI structure; Keyword-Driven and Data-Driven separate data from script logic.

Automated test maintenance is driven by changes to the SUT, test data, environment, and tool versions; brittle locators increase maintenance cost.

Automated tests need their own verification: false positives (tests pass when they should fail) and false negatives undermine trust.

Continuous integration executes automated tests on every change; test selection and parallelization control feedback time.

Automation supports static analysis, coverage measurement, and dynamic analysis as well as regression test execution.