Lesson 1 of 86 min read
Agile in plain words: what changes for testers
In Agile, software is built and released in small pieces every few weeks instead of one big release at the end. For testers this means testing never waits until the end — you test a little, all the time, alongside developers.
Key takeaways
- 1The Agile Manifesto values working software, collaboration and responding to change over heavy documentation and fixed plans. It does not mean 'no documentation' — it means just enough.
- 2Waterfall: requirements, design, build, then a long testing phase at the end. Agile: every sprint includes all of these for a small slice of features.
- 3Testers move from 'gatekeeper at the end' to 'quality coach throughout': asking questions in refinement, testing stories as soon as they're built, and automating regression.
- 4The whole team owns quality. Developers write unit tests; testers bring risk thinking, exploratory testing and user perspective.
- 5Popular Agile frameworks: Scrum (fixed sprints, most common in QA job descriptions), Kanban (continuous flow, no sprints) and SAFe (Agile at large companies).
Same feature, two ways
Feature: 'Customers can save items to a wishlist' Waterfall (6 months): Month 1-2 requirements -> Month 3-4 build everything -> Month 5 testing -> 140 bugs found at once, release slips, nobody remembers the code. Agile (2-week sprints): Sprint 1: add item to wishlist -> tested and shipped Sprint 2: remove item, wishlist page -> tested and shipped Sprint 3: share wishlist link -> tested and shipped -> Bugs found days after the code is written, while it's fresh. -> Customer feedback from sprint 1 changes what is built in sprint 3.
Go deeper
Expert notes beyond the basics
- 01
The four values and what they mean on a Monday morning
Individuals and interactions over processes and tools: walk over (or message) the developer instead of only commenting on a ticket. Working software over comprehensive documentation: a short checklist of scenarios beats a 40-page test plan nobody reads. Customer collaboration over contract negotiation: when a requirement is unclear, ask the product owner rather than guessing. Responding to change over following a plan: when priorities change mid-sprint, re-plan your testing instead of complaining. The items on the right still have value — Agile just values the left more.
- 02
The testing quadrants: what to test, and who does it
A common Agile model splits testing into four groups. Q1: unit and component tests (developers, automated). Q2: functional tests, story tests and examples (testers and developers, automated or manual). Q3: exploratory, usability and acceptance testing (testers and users, manual). Q4: performance, security and reliability (specialists and tools). A tester who mentions all four quadrants in an interview shows they understand quality is more than clicking through screens.
- 03
The test automation pyramid
Because Agile ships every sprint, regression testing must be fast. The pyramid says: many fast unit tests at the bottom, fewer API/service tests in the middle, and a small number of slow UI tests on top. Manual exploratory testing sits alongside, finding what scripts can't. When a team has mostly UI tests (an 'ice-cream cone'), runs become slow and flaky — something a QA engineer should point out.
- 04
Shift-left and shift-right
Shift-left means testing earlier: reviewing stories, pairing with developers, testing APIs before the UI is built. Shift-right means learning from production: monitoring errors, feature flags, A/B tests and reading customer feedback. Modern Agile testers do both.
Common mistakes to avoid
- - Thinking Agile means no documentation or no planning. It means lightweight, useful documentation and frequent re-planning.
- - Running a 'mini waterfall' inside the sprint: developers code for 8 days, testers get everything on day 9.
- - Believing quality is only the tester's job. In Agile the whole team owns it.
- - Skipping regression because 'we only changed a little' — small changes break things too.
Try it yourself
Your manager says: 'We're Agile now, so testers don't need to write any test cases.' Write a short, polite reply (3-4 sentences) explaining what testing documentation still makes sense in Agile.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
What is the role of a tester in an Agile team?
Model answer
A tester is involved from the start of each story, not just at the end. I help clarify acceptance criteria during refinement, identify risks and edge cases early, test stories as soon as they're ready within the sprint, report bugs quickly, maintain automated regression tests and give the team honest information about whether a story meets the Definition of Done.
- Q2
What is the difference between Agile and Waterfall?
Model answer
Waterfall runs phases in sequence — requirements, design, build, test, release — with testing late and change expensive. Agile delivers small working increments in short iterations, with testing inside every iteration, frequent feedback and easy change. Waterfall can suit fixed, well-understood, regulated projects; Agile suits products where requirements evolve.
- Q3
What are the Agile testing quadrants?
Model answer
A model that groups tests by purpose: Q1 technology-facing tests that support the team (unit, component); Q2 business-facing tests that support the team (functional, story tests); Q3 business-facing tests that critique the product (exploratory, usability, UAT); Q4 technology-facing tests that critique the product (performance, security). It helps a team check that no type of testing is forgotten.
- Q4
What is the test pyramid and why does it matter in Agile?
Model answer
It recommends many fast, cheap unit tests, fewer API tests and only a small number of slow UI tests. In Agile we release often, so regression must run in minutes inside CI; a pyramid-shaped suite gives fast, reliable feedback while UI-heavy suites become slow and flaky.
Knowledge check
+5 points
In Agile, when does testing happen?