I85PREP
⌘ K
CAT study materials
CAT study resources

CAT: Agile testing in practice / role of the tester in agile teams

CAT · Work through your exam, one topic at a time.

All guide sections

Agile testing in practice / role of the tester in agile teams

Domain focus

This domain tests the tester's day-to-day contribution in an agile team: collaboration, test planning, automation, exploratory work, metrics and professional skills. The exam favors concrete behaviors over job titles.

Core rules and concepts

  • The tester participates in backlog refinement to make stories testable, asks for examples, identifies gaps and helps define acceptance criteria and the Definition of Done.
  • During iteration planning, the tester estimates test effort, identifies test data and environments, and plans exploratory charters alongside automated checks.
  • The tester pairs with developers on unit and component tests, reviews automation design, runs API and UI checks in continuous integration, and reports meaningful information rather than raw pass counts.
  • Useful measures include escaped defects, automation reliability and feedback time, defect trends and coverage of risks; avoid velocity or bug counts as individual performance targets.
  • Testers need domain knowledge, technical fluency, critical thinking, communication and coaching. In distributed teams, explicit written examples and shared definitions reduce ambiguity.

Worked example

A tester joins a team that hands over builds after all coding is finished. Instead of waiting, the tester reviews the next story with the Product Owner, writes examples for normal, boundary and error cases, pairs with a developer on a failing component test, adds an API regression check to the pipeline and books a 90-minute exploratory charter for the first usable increment. At the retrospective, the tester shows that feedback time fell from days to hours and proposes refining acceptance criteria earlier.

Traps

  • Acting as a gatekeeper who signs off at the end; agile teams share quality ownership.
  • Reporting only test execution counts without risk or defect information.
  • Assuming automation replaces exploratory testing; they answer different questions.
  • Ignoring non-functional risks such as performance, security and usability until release.
  • Treating distributed-team silence as agreement; confirm shared examples in writing.