QAI CAST cheat sheet
QAI CAST · Keep the key ideas within reach.
Software Testing Fundamentals
Seven ISTQB test principles: testing shows presence of defects, exhaustive testing is impossible, early testing saves cost, defect clustering applies, tests wear out (pesticide paradox), testing is context dependent, absence-of-errors fallacy.
Verification asks 'are we building the product right?' against specifications; validation asks 'are we building the right product?' against user needs.
Test levels: component (unit), integration, system, and acceptance testing; each level has distinct objectives, entry criteria, and typical defect classes.
Static testing finds defects without executing code: reviews (informal, walkthrough, technical review, inspection) plus static analysis tools.
Error is a human action; defect (bug/fault) is the resulting flaw in a work product; failure is the observable deviation from expected behavior during execution.
The V-model pairs each development phase with a test level: requirements to acceptance, design to system/integration, coding to component testing.
Functional testing covers what the system does (features, business rules); non-functional testing covers how well it does it (performance, security, usability, reliability).
Regression testing confirms changes did not break existing behavior; it is best driven by change impact analysis and automated suites.
Test Planning and Design
A test plan documents scope, objectives, approach, entry and exit criteria, resources, schedule, risks, and deliverables; it is a living artifact updated as context changes.
Entry criteria gate test start (test environment ready, test data available, build smoke-tested); exit criteria gate completion (planned tests executed, defect thresholds met, coverage targets reached).
Equivalence partitioning divides inputs into classes expected to behave identically; one representative per valid and invalid class is sufficient.
Boundary value analysis targets edges of ordered partitions: minimum, minimum+1, maximum, maximum-1, and often just outside the range.
Decision tables model combinations of conditions and expected actions; the number of rule columns is 2^n for n binary conditions before collapsing.
State transition testing derives tests from states, events, guards, and actions; coverage levels are all-states, all-transitions (0-switch), and n-switch.
Risk-based testing prioritizes by risk = likelihood x impact; high-risk items get deeper, earlier, and more frequent testing.
Test design techniques split into black-box (specification-based), white-box (structure-based: statement and branch coverage), and experience-based (error guessing, exploratory testing).
Test Execution and Defect Management
A defect report contains a unique ID, title, environment/build, preconditions, reproducible steps, expected vs actual result, severity, priority, status, and evidence.
Severity measures impact on the system (how badly it breaks functionality); priority measures urgency of the fix for the business; they are assigned independently and can disagree.
Defect life cycle: New, Assigned/Open, In Progress, Fixed/Resolved, Retest, Verified/Closed, plus Reopened, Deferred, Duplicate, Rejected, and Cannot Reproduce.
A defect is 'rejected' when it is not a defect (works as designed, duplicate, or environmental); 'deferred' when valid but postponed to a later release.
Test execution logs must record actual results, timestamps, tester identity, build identifier, and pass/fail status so results are reproducible and auditable.
Retesting a fix confirms the specific defect is resolved; regression testing confirms the fix did not introduce new failures elsewhere.
Defect clustering follows the Pareto principle: a small number of modules typically contain most defects, so effort should concentrate there.
Defect density = defects found / size of work product (per KLOC, per function point, or per requirement); it allows comparison across modules and releases.
Test Measurement and Metrics
Defect detection percentage (DDP) = defects found in testing / (defects found in testing + defects found after release) x 100; higher DDP indicates more effective pre-release testing.
Defect removal efficiency (DRE) = defects removed before delivery / total defects (pre-delivery + post-delivery) x 100.
Test execution progress = executed tests / planned tests x 100; pass rate = passed tests / executed tests x 100.
Requirements coverage = requirements with at least one test / total requirements x 100; traceability matrices are the standard evidence source.
Statement coverage = statements executed / total executable statements; branch (decision) coverage = branches exercised / total branches; 100% branch coverage implies 100% statement coverage, not the reverse.
Defect leakage = defects escaped to production / total defects reported x 100; it is the inverse view of DDP and signals gaps in test design.
Mean time to failure (MTTF) and failure rate are reliability metrics; MTBF = MTTF + mean time to repair.
Metrics are only meaningful with a defined baseline, consistent counting rules, and trend context; a single data point cannot show improvement or decline.
Testing Tools and Automation Basics
Tool categories: test management, static analysis, test design, test execution/automation, performance, security, and monitoring/coverage tools.
The automation pyramid favors many fast unit tests, fewer service/API tests, and few slow UI tests; UI-heavy suites are the most brittle and costly to maintain.
A test automation framework is a design pattern plus libraries: linear, modular, data-driven, keyword-driven, and hybrid are the common models.
An automated check has a pass/fail oracle; without a reliable oracle the script reports results that cannot be trusted.
Flaky tests pass and fail on unchanged code; common causes are timing/synchronization, shared state, test-order dependence, and unstable test data.
Continuous integration runs automated suites on every commit; suites must be fast, deterministic, and self-provisioning to stay useful.
Test data management covers synthetic data generation, anonymization of production-like data, and reset/teardown between test runs.
Tool selection criteria include fit to the technology stack, licensing and total cost of ownership, skill requirements, integration with CI and defect tracking, and vendor support.