Testing in Agile
Testing in Agile examines how testing work is planned, designed and executed inside an agile project. The exam focuses on the Agile Testing Quadrants, risk-based testing, exploratory testing and the tester's role in a whole-team approach.
Core rules and concepts
- The Agile Testing Quadrants (Marick) classify tests by purpose: Q1 technology-facing tests that support the team (unit, component); Q2 business-facing tests that support the team (functional acceptance, examples); Q3 business-facing tests that critique the product (exploratory, usability, user acceptance); Q4 technology-facing tests that critique the product (performance, security, reliability).
- Quadrants are a map, not a sequence. A single story may need work in several quadrants.
- Risk-based testing uses product risk (likelihood times impact) to order and deepen testing. Reassess risk every iteration, because risk changes as the product and market change.
- Exploratory testing is structured: charter, timebox, session sheet, debrief. It complements rather than replaces automated regression checks.
- Test levels overlap; each level has a purpose, not a single owner. The whole team owns quality.
- Testers contribute to iteration planning by asking testability questions and estimating test effort, not just by executing tests.
Worked example
A team has eight days left in an iteration and two stories: payment retry logic and a cosmetic UI restyle. Risk assessment: retry logic has high defect likelihood and high impact (double charges), so it gets exploratory sessions, automated checks and a review of state transitions. The restyle has low impact, so it gets a visual check and a smoke test. Reasoning: effort follows risk, not story size or the loudest stakeholder.
Traps
- Treating quadrants as project phases.
- Measuring testing only by execution counts.
- Calling unstructured clicking "exploratory testing".
- Dropping regression automation when deadlines tighten.