ISTQB CTAL-TA cheat sheet

Product risk level is derived from the likelihood of occurrence and the impact if it occurs; the resulting level (very high, high, medium, low) drives test depth, coverage and effort.

Risk management steps (ISO 31000 / PRAM) are: identify, assess (analyse and evaluate), mitigate, and monitor/control throughout the lifecycle.

The test analyst contributes technical input on product risk likelihood; business stakeholders usually judge business impact and acceptability.

Project risks (schedule, budget, staffing, tools) belong to the test manager; product risks (quality of the deliverable) are the test analyst's principal focus.

Risk mitigation options include testing, reviews, training, prototyping and contingency; testing mitigates risk by supplying information that reduces uncertainty.

Higher risk demands more rigorous techniques and stronger coverage: for example full decision-table rule coverage instead of equivalence partitioning alone.

Risk-based prioritisation orders test conditions and test cases so that those covering the highest risk levels are designed and executed first.

Risks are re-assessed at each phase or iteration and after defects or changes are discovered; residual risk is reported at test closure.

Risk identification techniques include brainstorming, interviews, workshops, checklists, independent expert opinion and risk poker.

Test analysis produces test conditions from the test basis; test design turns test conditions into test cases and test data; implementation produces procedures and suites.

Equivalence partitioning: divide inputs or outputs into partitions with identical expected behaviour; invalid partitions are tested separately and never combined with valid ones.

Two-value boundary value analysis on a range a..b tests a-1, a, b and b+1; three-value BVA additionally tests a+1 and b-1.

Decision tables: n binary conditions give 2^n rules; full coverage requires all rules, minimum coverage requires only rules that change the specified outcome.

State transition coverage criteria from weakest to strongest are: all states, all transitions (0-switch), then N-switch coverage.

Use case testing coverage is measured as the percentage of basic, alternative and exception flows exercised by the designed test cases.

Pairwise (all-pairs) testing requires every combination of two parameter values to appear at least once; orthogonal arrays and covering arrays generate the sets.

Experience-based techniques (error guessing, checklist-based, exploratory) complement systematic techniques when specifications are poor or time is short.

A traceability matrix links test basis items to test conditions, test cases and results, enabling coverage measurement and impact analysis.

ISO 25010 quality characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability and portability.

Functional suitability = functional completeness + functional correctness + functional appropriateness; it is the test analyst's core responsibility.

Usability comprises learnability, operability, user error protection, user interface aesthetics and accessibility.

Compatibility = co-existence (sharing an environment without adverse effect) + interoperability (exchanging information correctly with other systems).

Security subcharacteristics are confidentiality, integrity, non-repudiation, accountability and authenticity; these are mainly the technical test analyst's scope.

Reliability = maturity, availability, fault tolerance and recoverability; performance efficiency = time behaviour, resource utilisation and capacity.

Portability = adaptability, installability and replaceability; it is tested against the explicitly defined hardware, software and organisational environments.

Accessibility testing commonly uses the WCAG principles: perceivable, operable, understandable and robust.

Data conversion testing verifies the completeness, correctness and integrity of migrated data, often using record counts and checksums.

ISO 20246 review types: informal review, then formal types - walkthrough, technical review and inspection - in increasing order of formality and rigour.

Review process activities are: planning, initiation, individual review, communication and analysis, and fixing and reporting.

Inspection uses defined entry and exit criteria, a moderator, individual preparation with checklists, documented findings and formal follow-up of defects.

A walkthrough is author-led; a technical review is performed by technically qualified peers; an informal review has no defined process and no documented output.

The test analyst reviews the test basis (requirements, designs, user stories) for ambiguity, inconsistency, non-testability and missing or contradictory coverage.

Review technique selection options include ad hoc, checklist-based, scenario-based, perspective-based reading, role-based and systematic review.

Defects found in reviews are logged like test defects; the earlier in the lifecycle a defect is found, the lower the relative cost of correction.

Review success factors include clear objectives, an appropriate mix of participants, training, checklists, management support and a defined process.

Severity is the impact of a defect on the system and is assigned by testers; priority is the urgency of correction, agreed with business stakeholders; the two are independent.

Minimum defect report content: unique ID, title, author and date, environment, steps to reproduce, expected and actual results, severity, priority, status and references.

Defect workflow states typically include new, assigned, open, fixed, ready for retest and closed, plus rejected, duplicate and deferred.

Defect removal efficiency = defects found in test / (defects found in test + defects found after release) x 100%.

Defect density = number of defects divided by a size measure such as function points, lines of code or test cases; used to compare modules and estimate remaining defects.

Test estimation approaches include expert judgement, planning poker, ratio of development effort, function point analysis, test case counts and test point analysis.

Monitoring and control uses test progress reports based on defect trends, test case execution status, coverage achieved and risk burn-down.

Configuration management for testware requires version control, baselines and change control over test cases, test data and test scripts.

Test closure activities cover archiving deliverables and the test environment, closing or deferring defects, documenting residual risk and recording lessons learned.