Fundamental agile testing principles, practices and processes
Domain focus
This domain tests how agile principles become testing practices: whole-team ownership of quality, continuous feedback, iterative planning and fit-for-purpose documentation. The exam expects you to connect principles to concrete activities, not recite slogans.
Core rules and concepts
- Quality is a whole-team responsibility; testers collaborate, coach and provide information rather than act as a final gate.
- Testing is continuous and shift-left: review stories and acceptance criteria before coding, test at unit and component level early, and keep regression checks automated.
- Agile planning is layered: release planning sets scope and quality goals; iteration planning selects stories and defines tasks; daily coordination adapts work; review and retrospective inspect product and process.
- The agile testing quadrants help select coverage: technology-facing tests that support the team (unit, component), business-facing tests that support the team (acceptance), business-facing tests that critique the product (exploratory, usability) and technology-facing tests that critique the product (performance, security).
- Test automation should follow a pyramid: many fast unit and component checks, fewer service or API checks, and few brittle UI checks.
Worked example
A team plans a four-week release and schedules 'system testing' only in the final week. A tester should challenge this. Acceptance criteria and examples should be reviewed during backlog refinement; unit and component tests should run with every commit; API acceptance tests should run in continuous integration; exploratory sessions should begin as soon as a usable increment exists. Final-week system testing remains useful as end-to-end confidence, but it cannot replace feedback throughout the release.
Traps
- Saying 'the tester owns quality' or 'testing starts after development.'
- Planning every test at release start and refusing to adapt.
- Treating the test quadrants as sequential phases or as a mandate to automate everything.
- Equating 'working software over documentation' with having no acceptance criteria or traceability.