QAI CAST study materials
QAI CAST study resources

QAI CAST cheat sheet

QAI CAST · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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).

Quick reference

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.

Quick reference

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.

Quick reference

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.