The conclusion first: a QA’s job in agile development is not to guarantee quality outright, but to put the team in a state where quality can keep being reasoned about.
Agile and QA are widely assumed to fit badly together. With short sprints and a specification that keeps moving, plenty of people end up thinking “I do not know what QA is supposed to do here”, “testing cannot keep up”, or “we just check everything at the end anyway”.
I felt the same at first, working as QA on agile teams. But sharing a few premises and making the criteria explicit organizes the QA position considerably.
This article covers three things:
- What QA is actually responsible for in agile development
- Why the traditional QA approach tends to break down
- Practices that did not strain the team in practice
Sponsored
The criterion: quality is the team’s ability to continue, not a later phase
Quality in agile rests on a specific premise: not “are there few bugs” but “is the team in a state where it can keep delivering value”.
That is not improvised. The twelve principles behind the Agile Manifesto include “continuous attention to technical excellence and good design enhances agility”. The position is not that you drop quality to move faster, but that maintaining quality is a condition of speed.
In Scrum, this is made explicit as the Definition of Done. The Scrum Guide describes it as a formal description of the state of a Product Backlog item when it meets the quality measures required for the product. The point is that “how far is far enough” exists as a team agreement.
On that premise, the QA role changes shape.
| Traditional image | What it actually is in agile |
|---|---|
| The person who owns the test phase | The person who builds a way of working that resists breaking |
| A specialist who finds bugs | A person who makes quality risk visible |
| The person who inspects at the end | A person involved in the Definition of Done itself |
Why traditional QA struggles in agile
Almost always it is a mismatch of premises, not a shortfall in ability.
“Test once the spec is settled” stops being possible
In waterfall, requirements, design, implementation, testing formed a reasonably clear sequence, and QA could confirm quality after the specification settled. I wrote about that context in QA in waterfall development.
In agile, this is normal:
- The specification changes mid-sprint
- Something is deliberately built rough to test a hypothesis
- The next sprint changes direction
Waiting for the specification to settle before testing leaves QA permanently behind.
The expectation that QA equals testing persists
The other half is how the team sees it. “We have QA, so quality is covered.” “Bugs are QA’s job to find.” Where that survives, you get:
- Weaker self-checking by developers
- All verification funnelled into QA
- A testing crunch at the end of every sprint
The gap between agile’s premises and what people expect from QA is wider than most teams realize.
Sponsored
The core QA role: making quality risk visible
The framing that fit best in practice was surfacing quality risk early and legibly.
Start from the premise that you will not test everything
In agile, “test everything before shipping” is often not a realistic idea at all. So QA prioritizes organizing risk:
- Where is this likely to break?
- Where is the user impact largest?
- How far can we actually vouch for it this time?
From sprint planning onward I would flag things early: “this area’s spec is ambiguous, worth watching”, “this broke last time too”.
Hand over decision material, not just results
“Pass / fail” is not enough output from QA.
- Which aspects have been examined
- Which aspects still carry doubt
Just having that makes release decisions and scope adjustments easier. Less protecting quality than assembling the material for thinking about it.
Applied to E2E testing, that becomes a quality standard for E2E tests.
A map of what to cover: the agile testing quadrants
When deciding QA’s scope, I work from the agile testing quadrants — proposed by Brian Marick and developed by Lisa Crispin and Janet Gregory in Agile Testing.
| Quadrant | Axes | Content | Automation |
|---|---|---|---|
| Q1 | Technology-facing, supporting the team | Unit, component and API tests | Nearly all |
| Q2 | Business-facing, supporting the team | Functional tests, acceptance criteria | Where feasible |
| Q3 | Business-facing, critiquing the product | Exploratory testing, usability, UAT | Humans |
| Q4 | Technology-facing, critiquing the product | Performance, load, security | Tooling |
The value of this diagram is that it lets you explain that QA is not the person who covers everything. Q1 belongs to developers, and QA taking it over helps nobody. QA’s strongest contribution is Q3, exploratory testing, which cannot be automated.
When someone says “leave all the testing to QA”, showing the quadrants is the fastest way to have the conversation — and it keeps the discussion off feelings.
Sponsored
Practices that worked
Involve QA from the first half of the sprint
Rather than parking testing at the end, get involved in:
- Checking requirements
- Agreeing acceptance criteria
- Enumerating likely failure paths
That alone cut late-sprint rework substantially. The point is not “for testing” but “to make it harder to break before it is built”.
Agreeing acceptance criteria is essentially the same work as test design. Settle “what does correct look like” before implementation starts and there is nothing to argue about later.
Share test design “lightly”
Rather than perfecting detailed test cases, sharing these in a short note or verbally often worked better:
- What aspects will be examined
- What is being dropped this time
Naming what is dropped is what makes this work. Once the unexamined area is shared, developers know where to be careful.
Automate what you want to protect, first
“Automate everything” tends to fail. I prioritized:
- What gets touched every time
- What hurts most when it breaks
Automation is not the goal; it is a means of protecting the team’s ability to continue. How to decide what goes into E2E is in what to protect with E2E tests.
Aim for a team that is easier to work in because QA is there
QA’s value in agile cannot be measured by bug counts. These changes suggest it is working:
- Release decisions got easier
- Conversations about quality stopped turning emotional
- The tension at the end of a sprint dropped
For me, the role clicked when someone said “with QA here, I can move forward without worrying”.
Summary
- The aim of agile QA is not guaranteeing quality but creating a state where quality can keep being reasoned about
- The Agile Manifesto principles include “continuous attention to technical excellence and good design enhances agility”
- In Scrum, the Definition of Done is where the quality agreement lives
- Traditional QA breaks because “test after the spec settles” no longer holds
- QA’s central work is making quality risk visible: decision material, not pass/fail
- Use the agile testing quadrants to explain the split. QA’s strength is Q3 exploratory testing
- Agreeing acceptance criteria early cuts rework by itself
- In test design, sharing what was dropped matters more than exhaustive cases
- Automate what you want to protect — not everything
Trying to protect all of it is what exhausts QA. Share the criteria, put risk into words, and stand alongside the team, and agile and QA are not the poor fit they are said to be.
If you are unsure what to do as QA on an agile team, change when you get involved and from what angle before changing how much you test.
