Agile testing changed how software is built. It also changed how software is tested. Understanding agile testing is essential for any modern QA role — it's one of the top topics in QA interviews.
The Old Way vs The Agile Way
Waterfall testing Build everything first, then test everything at the end. QA was a separate phase — a gate before release. Problems: bugs found late (expensive to fix), QA is a bottleneck, adversarial relationship between dev and QA.
Agile testing Test continuously throughout development. QA is embedded in the team, not a separate phase. Testing happens alongside development within each sprint.
QA's Role in Scrum
Sprint Planning - Help estimate testing effort for stories - Identify testing risks early - Ask questions about acceptance criteria - Flag stories that need more definition before development
Daily Standup - Share testing progress - Raise blockers (environment issues, unclear requirements) - Coordinate with developers on stories ready for testing - Communicate risks or concerns
During the Sprint - Write test cases as developers write code - Test stories as soon as they're code-complete (don't wait!) - Run automated regression tests - Perform exploratory testing on completed features - Communicate bugs to developers immediately (face-to-face or chat, not just tickets)
Sprint Review - Demo tested features - Share quality metrics (bugs found, test coverage) - Provide feedback on the sprint from a quality perspective
Sprint Retrospective - Suggest improvements to the testing process - Discuss what went well and what didn't for quality - Propose experiments for the next sprint
The Testing Bottleneck Problem
The most common agile testing anti-pattern:
Sprint Day 1-8: Developers write code Sprint Day 9-10: ALL testing happens
This creates a bottleneck — QA is overwhelmed at the end while idle at the start. The fix:
Continuous testing within sprints - Developers pair with QA on acceptance criteria BEFORE coding - QA writes test cases while developers write code (in parallel) - Stories are tested as they're completed, not in batch at the end - Small, frequent deliveries beat large, end-of-sprint dumps
The ideal flow - Day 1-2: QA refines upcoming stories, writes test cases - Day 3-8: QA tests stories as developers complete them - Day 9-10: Regression testing, exploratory testing, sprint wrap-up
Definition of Done (DoD)
The DoD is the team's shared agreement on what "done" means. A typical DoD includes:
- Code is written and code-reviewed
- Unit tests are written and passing
- Feature is tested by QA
- No open critical or high-priority bugs
- Acceptance criteria are verified
- Test cases are added to the regression suite
- Documentation is updated (if needed)
QA should be involved in defining and enforcing the DoD.
Testing Types in Agile
Story testing Test each user story against its acceptance criteria. This is the primary QA activity during a sprint.
Regression testing Automated regression suite runs on every build. Catches regressions introduced by new code.
Exploratory testing Allocated time each sprint for exploratory testing on new and existing features. Finds bugs that scripted tests miss.
Sprint regression A focused regression cycle at the end of each sprint, covering features from the current and recent sprints.
Practical Tips
Shift left Get involved early. Review requirements, write acceptance criteria, identify risks before development starts.
Automate early Start automating regression tests from Sprint 1. A small automated suite that grows each sprint is better than a massive manual regression.
Communicate constantly In agile, quick verbal communication beats detailed bug reports for minor issues. Save formal bug reports for significant defects.
Don't be a gatekeeper Your job isn't to block releases — it's to inform the team about quality risks. Present data, let the team decide.
Track quality trends - Bugs per sprint (trending down = improving) - Bugs found in production (the metric that matters most) - Test automation coverage (trending up = good) - Average bug fix time
Key Metrics for Agile QA
- Sprint burndown (are stories completing on time?)
- Bug escape rate (bugs found in production / total bugs)
- Automation coverage (% of regression automated)
- Defect reopening rate (are fixes working?)
- Sprint velocity stability (volatile velocity suggests quality issues)
The Mindset Shift
Traditional QA: "I find bugs" Agile QA: "I help the team build quality in"
This shift is fundamental. In agile, quality is everyone's responsibility, and the QA engineer is the quality advocate — coaching the team, building processes, and ensuring quality is considered at every step.