ISTQB CTAL-ATT cheat sheet

Requirement quality criteria (ISO/IEC/IEEE 29148 style): necessary, unambiguous, complete, singular, feasible, verifiable, correct, conforming - a requirement that cannot be verified cannot be tested.

Agile requirement levels: epic → feature → user story → acceptance criteria; the INVEST mnemonic (Independent, Negotiable, Valuable, Estimable, Small, Testable) is the standard quality check for user stories.

Acceptance criteria formats: rule-oriented (bullet checklist) versus scenario-oriented (Given/When/Then); scenarios map one-to-one onto executable acceptance tests.

Three specification-based test design techniques derive from requirements: equivalence partitioning, boundary value analysis, and decision tables; decision tables are chosen when requirements combine multiple conditions.

Requirements traceability matrix links requirement ID → design → test case → defect; bidirectional traceability detects both uncovered requirements and orphan tests.

Non-functional requirements need measurable thresholds (e.g., 500 concurrent users, p95 response < 2 s); vague terms such as 'fast' or 'user-friendly' are untestable and must be quantified during review.

Reviews of requirements are static testing: defect detection cost rises roughly by an order of magnitude per phase, so requirement review is the cheapest defect removal point.

Definition of Ready gates a story into a sprint (testable, sized, acceptance criteria agreed); Definition of Done gates it out (all agreed tests executed and passing).

Ambiguity heuristics for review: passive voice without an actor, pronouns without a referent, comparatives without a baseline, and absolutes ('always', 'never') without conditions.

Quadrants model: Q1 technology-facing/unit and component tests, Q2 business-facing functional tests and examples, Q3 business-facing exploratory and usability testing, Q4 technology-facing non-functional and performance testing.

Test pyramid heuristic: many unit tests, fewer service/API tests, fewest UI tests; the inverted 'ice-cream cone' (UI-heavy) is the anti-pattern because it slows feedback and raises maintenance cost.

Whole-team approach: developers, testers, and business stakeholders jointly own quality; the tester's role shifts from gatekeeper to coach and example facilitator.

Three Amigos: business analyst, developer, and tester review a story together before development to expose assumptions and agree on examples and acceptance criteria.

ATDD/BDD cycle: discuss → distill → develop (outside-in); examples become executable specifications that fail first, then pass after implementation.

Exploratory testing in agile is session-based: charter, timebox (typically 60–120 minutes), session sheet with coverage notes, bugs, and issues; debrief follows.

Continuous integration rule: every commit triggers build plus automated test suite; a red build is fixed before new work is merged (stop-the-line).

Sprint cadence test activities: backlog refinement (testability review), sprint planning (test estimation), daily collaboration, continuous testing, sprint review (demo of working software), retrospective (process improvement).

Risk-based testing in agile: product risk = likelihood × impact; test depth and automation priority are allocated to highest-risk stories first.

Test automation architecture layers: test generation/design, test definition (test cases and data), test execution (runner), test adaptation (glue/harness), and the system under test; a layer change should not ripple through all others.

Design patterns: Page Object (encapsulates page structure and locators), Screenplay/Actor (tasks and interactions composed per actor), and Builder (constructs test data) - each isolates change to one place.

TAS (test automation solution) maintainability metrics: low duplication, clear naming, a single place per locator, and independence of test cases from each other and from execution order.

Automation ROI factors: execution frequency, script lifespan, stability of the feature, cost of manual execution, and cost of maintenance; one-off or highly volatile tests are poor automation candidates.

Test data strategies: static data sets, data generated on the fly, and production-like anonymized data; test data must be independent of other tests' state to avoid order dependencies.

Flaky test handling: quarantine, root-cause analysis (timing, shared state, environment), and re-run only as a diagnostic - not as a fix; a flaky suite destroys trust in red results.

Continuous integration feedback loop: fast unit suite on every commit, longer regression suite per merge/nightly; suite runtime is a design constraint, not an afterthought.

Verification of the automation solution itself: the TAS needs its own tests, code review, version control, and defect tracking; automation code is production-quality code.

Metrics to judge automation: pass/fail trends, defect detection effectiveness, coverage of risk, execution time, and maintenance effort per test - not test count alone.

Deployment pipeline stages: commit → build → unit tests → integration/component tests → deploy to test environment → system/regression tests → deploy to staging → acceptance → production; each stage is a quality gate.

Continuous delivery vs continuous deployment: CD-delivery keeps every change releasable with a manual production trigger; CD-deployment releases automatically; both require automated tests and rollback capability.

Environment parity: test, staging, and production should match in configuration, data shape, and infrastructure (infrastructure as code) so that test results are predictive.

Release vs deployment: deployment puts code into an environment; release makes functionality available to users - feature toggles decouple the two and enable dark launches and canary releases.

Canary release and blue-green deployment reduce risk: canary sends a small traffic percentage to the new version with monitoring; blue-green switches traffic between two identical environments with fast rollback.

Rollback and roll-forward plans must be tested; a deployment is not 'done' until the recovery path is verified.

Shift-left and shift-right: shift-left moves testing earlier (static analysis, unit tests, reviews); shift-right tests in production (monitoring, observability, synthetic transactions, chaos experiments).

Deployment risk indicators: change size, test coverage of the change, previous failure rate of the component, and time since last deployment - small, frequent changes carry lower risk.

Post-deployment verification: smoke tests against production, health checks, log and metric monitoring, and alerting thresholds defined before release.