In many Scrum teams, the sprint looks agile on the board – and still runs like a small waterfall: the first eight days are spent developing, the last two testing, and whatever isn’t finished slips into the next sprint. Agile testing means something different. Quality is not created in a test phase at the end, but in every step of the sprint – from refinement to review. This article shows how that works in practice, what role testers play in a Scrum team and which mistakes you should avoid.
Agile testing is not a separate test technique but a way of working: tests accompany development from the start, feedback arrives in hours instead of weeks, and the whole team is responsible for quality. Traditional approaches have dedicated test levels and phases that run one after another. In Scrum, every sprint must end with a usable, tested increment. A separate test phase has no place in that rhythm.
This leads to three principles that Lisa Crispin and Janet Gregory shaped in their standard work “Agile Testing” and that still apply today:
How testing generally differs between both worlds is described in our article Agile vs. Traditional Project Management.
Agile testing starts before the first line of code is written. In backlog refinement, testers check together with the Product Owner and developers whether a user story is understandable and testable. The “Three Amigos” format has proven effective: business, development and testing discuss a story from their respective perspectives and capture concrete examples. Written in the Given – When – Then pattern, these examples become directly verifiable acceptance criteria. Vague wording such as “fast” or “user-friendly” stands out immediately. How to describe requirements cleanly from the outset is shown in Clean Requirements in IT Projects.
When the team estimates a story, the testing effort is part of it: preparing test data, automating tests, exploratory checks, adapting regression tests. If only development is estimated, the team systematically takes on too much – and testing becomes the buffer that is missing at the end of the sprint.
To avoid a mini-waterfall, the team works on few stories at the same time and finishes them one after another. As soon as a story reaches a testable state, it is checked – not only once all stories have been developed. Deviations are clarified directly in conversation rather than queued as tickets.
The Definition of Done (DoD) defines when a story counts as done. According to the Scrum Guide, it is a binding commitment to the quality level of the increment. For testing it is the most important tool, because it prevents “done” from quietly meaning “developed but not yet tested”. A practical DoD contains, for example:
The DoD should fit team and product and become stricter as the team matures.
Which tests does an agile team need? A widely used guide is the agile testing quadrants, originally described by Brian Marick and popularised by Crispin and Gregory. They classify tests by two questions: do they support the team during development or critique the finished product? And are they technology-facing or business-facing?
Many teams cover quadrants 1 and 2 well but neglect exploratory testing or postpone performance topics until shortly before go-live. How to tackle the latter in time is shown in our article on load testing.
With every sprint the software grows – and so does the number of functions to recheck after a change. Manually, this soon no longer fits into a sprint. Agile testing therefore depends on test automation: unit tests as a broad base, integration and API tests above them and only a few carefully selected UI tests, as described by the test pyramid. The automated tests run on every change in the CI/CD pipeline and provide feedback while the change is still fresh.
Automation is part of the story, not a separate project to be caught up on “at some point”. How to go about it is described in Introducing Test Automation: A 6-Step Guide and Regression Testing: How to Secure Stable Releases.
Automated tests check what someone defined in advance. Many critical defects, however, arise where nobody thought to look: unusual inputs, unexpected sequences, interactions between several functions. This is where exploratory testing comes in. A tester explores the application deliberately with a clear mission, such as “check invoice correction with edge cases”, within a fixed time box. This session-based form makes exploratory testing plannable and fits the sprint rhythm.
The Scrum Guide has no “tester” role. Everyone working on the increment is a Developer – including test specialists. That does not make testing expertise redundant. On the contrary: testers contribute methodological knowledge, for example of test design techniques such as equivalence partitioning or boundary value analysis, ask the uncomfortable questions in refinement and coach the team in testing. Developers, in turn, write unit tests and help with automation when stories pile up in test.
When several teams work on one product, cross-team coordination is needed as well: shared test environments, test data, cross-team integration tests and a common view of quality status before a release. These tasks can be captured in a lean test plan, even in an agile setting.
Agile testing works when quality is considered from the first conversation about a story: testable acceptance criteria in refinement, realistically planned testing effort, testing in parallel with development, a binding Definition of Done and growing test automation. Testers remain indispensable – as experts in test methods and as drivers for the whole team. Read more about the mindset behind Scrum in Agile Transformation: What Scrum Really Means.
The Scrum Guide does not define a separate tester role, but testing expertise in the team is highly recommended. A person with testing experience ensures testable acceptance criteria, suitable test techniques and a sensible automation strategy. Responsibility for quality still lies with the whole team.
Business checks take place continuously, for example by the Product Owner and in the Sprint Review. Where contracts or regulations require formal acceptance, it is planned for a release and carried out on the basis of the increments already tested. This keeps acceptance manageable and traceable.
No. Test automation is an important building block that keeps regression testing possible at sprint pace. But agile testing also includes testable requirements, exploratory tests, non-functional tests and collaboration within the team. Automation without these foundations does not lead to better quality.
30-minute initial consultation — free and without obligation. Together we look at your teams and show how testing can be integrated effectively into your sprints.
Book a Free Initial ConsultationMore about our service: Software Quality Assurance in Hamburg →