I85PREP
⌘ K
ISTQB CT-AT study materials
ISTQB CT-AT study resources

ISTQB CT-AT: Agile Techniques and Testing Techniques

ISTQB CT-AT · Work through your exam, one topic at a time.

All guide sections

Agile Techniques and Testing Techniques

This domain, Agile techniques and testing techniques, tests whether you can combine agile collaboration with deliberate test design to get fast, meaningful feedback. Expect questions on TDD, ATDD and BDD, the test pyramid and agile testing quadrants, and how specification-, structure- and experience-based techniques apply to user stories.

Core rules

  • TDD is a design cycle: write a failing unit test (red), write the least production code to pass (green), then refactor. Tests stay fast, isolated and deterministic.
  • ATDD agrees concrete acceptance examples before coding among the three amigos (business, developer, tester). Those examples become executable acceptance tests.
  • BDD expresses ATDD examples in ubiquitous language as Given/When/Then scenarios, often automated through step definitions.
  • Test pyramid: many unit/component tests, fewer service/API tests, very few UI tests. The inverted “ice-cream cone” is slow and brittle.
  • Agile testing quadrants (Marick): Q1 technology-facing/team-supporting (unit), Q2 business-facing/team-supporting (functional examples), Q3 business-facing/product-critiquing (exploratory, usability), Q4 technology-facing/product-critiquing (performance, security). Cover all four deliberately.
  • Apply equivalence partitioning, boundary value analysis, decision tables and state transition testing to story rules; use statement/decision coverage for code and exploratory testing for unknown risk.

Worked example

Story: “A customer can withdraw cash; daily limit $500; balance must cover the amount.” Partition the amount: ≤0 invalid; 0 < amount ≤ min(balance, 500) valid; amount > balance invalid; amount > 500 invalid. Boundaries: 0, 0.01, 500, 500.01, balance, balance+0.01. Reasoning: the three amigos agree these examples, automate rule checks at API level, keep one UI smoke path, and run a time-boxed exploratory session on the ATM screen. A decision table covers blocked card, insufficient funds and limit exceeded without duplicating every boundary.

Traps

Treating TDD as “test first” and skipping refactor; automating acceptance only through the UI; confusing ATDD with testing after development; using BDD keywords without business language; chasing 100% coverage with weak assertions; ignoring Q3/Q4 risks.