Regression testing in agile happens inside every sprint, alongside the stories being built. Targeted tests run on each pull request, the full suite runs before sprint review and every release, and hotfixes get a check of their own. The whole team shares the work while one tester curates the suite, and it stays fast when tests are chosen by what changed.
Every sprint ships new code, and some of it quietly breaks features that shipped months ago. The demo still goes well, because acceptance tests only look at the story on screen. The break surfaces later, often in a flow nobody on the team touched that sprint.
A story can pass every acceptance criterion and still change something another feature depends on, like a shared calculation or an API response. Catching that before release is the whole job of regression testing, and in agile it has to happen while the sprint is still running.
What is regression testing in agile?
Regression testing in agile is the practice of re-running previously passing tests throughout each sprint to confirm that new user stories, bug fixes, and refactors haven’t broken existing functionality. Instead of a single test phase before release, it runs continuously as part of the team’s sprint cadence and Definition of Done.
The core idea is the same as any regression testing. What changes is the timing.
Waterfall teams ran regression once, near the end, against a finished build. Agile doesn’t have that kind of pause. Each story merges as soon as it’s done, so the codebase never sits still long enough to test it all at once.
| Aspect | Waterfall | Agile |
|---|---|---|
| When it runs | One phase before release | Every story, sprint, and release |
| How the suite changes | Rarely | Grows every sprint |
| Who runs it | A separate QA team | The whole team |
| Main constraint | Calendar time at the end | Feedback speed in CI |
Where regression testing fits in a two-week sprint
Planning day is where most teams skip it. That’s a mistake, because it’s also the cheapest place to start.
| Sprint moment | Regression activity | Scope |
|---|---|---|
| Sprint planning | Flag stories that touch shared code like cart, auth, or pricing, and note which existing flows they could affect | No tests run yet |
| Story in progress | Targeted tests run on every pull request for the changed area | Narrow |
| Mid-sprint | A nightly run of the broader suite | Medium |
| Last days of the sprint | The full suite runs before sprint review | Full |
| Release | A final run on the release candidate | Full |
The mid-sprint run matters more than it looks, because two stories can each pass their own pull request checks and still break each other once both land on the main branch.
Retro is the last stop. So if a regression escaped this sprint, someone should ask why no test caught it, and the answer usually turns into a new test.
When should agile teams run regression tests?
Four triggers cover almost every situation an agile team runs into.
| Trigger | What to run | Why it matters |
|---|---|---|
| A story’s pull request | Tests for the changed module and anything that calls it | Fast feedback before the merge |
| End of sprint | The full suite | Catches interactions between stories |
| Before a release | The full suite on the release candidate | It’s the build users will actually get |
| After a hotfix | Critical flows plus tests near the fix | Hotfixes skip the normal sprint flow |
Per-story runs are a form of selective regression testing. You trade breadth for speed on each pull request and let the sprint-end run catch whatever the narrow checks missed.
After each deploy, a handful of smoke tests confirm the build is alive before anyone trusts the deeper results.
Dependency upgrades deserve their own mention. A library bump in the middle of a sprint isn’t a story, so it often skips planning entirely. Run the full suite anyway.
Who owns regression testing in an agile team?
Everyone runs it. But only one person curates it.
| Role | Regression responsibility |
|---|---|
| Developers | Run targeted tests before opening a pull request and add a test for every bug they fix |
| Agile tester or QA | Curates the suite, decides what goes in each tier, and digs into failures that aren’t obvious |
| Product owner | Names the business-critical flows that must never break |
| Scrum master | Protects time for suite maintenance and brings escaped regressions to retro |
That’s also why the Definition of Done matters. If "regression suite passes and new tests are added for this story" sits in the DoD, nobody can mark a story done without it.
Without that line, however, regression becomes whatever QA has time for on the last Thursday of the sprint.
In agile testing, testers work inside the team instead of after it, and regression is where that shows most. As a result, a tester who joins planning knows which flows a story could break before anyone writes a line of code.
How to keep the regression suite fast sprint after sprint
Every sprint adds tests. Very few teams remove any. Over time, a suite that used to report back in minutes runs long enough that developers start merging before it’s done.
- Pick tests by what changed. Tag tests by module so CI runs only what a pull request touches. The full suite still runs, just not on every commit.
- Critical flows go first. Login, checkout, and payments should report before anything else, so a cut-short run still tells you what matters.
- Keep automation in the pipeline. Automated regression tests in CI give every developer the same answer, which a script on someone’s laptop never will.
- Prune at retro. Duplicate tests go. So do tests for retired features and tests nobody on the team can explain.
- Quarantine flaky tests fast. A test that fails at random teaches people to ignore red builds.
API coverage tends to lag behind UI coverage in agile teams, because writing API tests for every story feels like extra work at the end of a sprint. Keploy closes that gap by turning the API calls a developer already makes while checking a story into regression tests, with dependency mocks, that run in CI. The suite grows with each story without a separate scripting task.
Common mistakes in agile regression testing
- The hardening sprint. Saving regression for a dedicated sprint before release brings waterfall back with extra meetings. Bugs found there are weeks old, and the developers who wrote them have moved on.
- Testing only on the last day. By then, several stories have merged on top of each other and nobody knows which one broke checkout.
- No regression line in the Definition of Done. Stories get marked done on acceptance criteria alone.
- A suite that only grows. It slows down until people stop waiting for it.
- Chasing an automation percentage. A high number means little if the payment flow isn’t covered.
Conclusion
AI coding assistants are already writing more of the code that lands in each sprint. More code per sprint means more changes, and every change is a fresh chance to break something that worked yesterday.
Teams that tie regression to each story will absorb that volume without slowing down. Teams still running a hardening sprint will find it getting longer every quarter.
FAQs
When is regression testing done in agile?
Regression testing in agile runs on every story’s pull request, at the end of each sprint, before each release, and after any hotfix. Per-story runs are narrow and fast. The sprint-end and release runs cover the full suite.
Who is responsible for regression testing in a Scrum team?
The whole Scrum team shares it. Developers run targeted tests and add tests for the bugs they fix, while the agile tester or QA engineer curates the suite. The product owner defines which flows are business-critical.
Should regression testing be part of the Definition of Done?
Yes. Adding "regression suite passes and new tests are added" to the Definition of Done stops stories from being marked complete on acceptance criteria alone. It also makes regression a team habit instead of a QA task at the end of the sprint.
Is a hardening sprint a good way to handle regression?
Usually not. A hardening sprint delays feedback by weeks, so bugs are harder to trace and more expensive to fix. Running regression inside every sprint catches the same bugs while the code is still fresh.
How much of agile regression testing should be automated?
Automate the stable, repeatable checks that run on every pull request, especially API calls and critical user flows. Complex UI behavior and exploratory scenarios often still need a person. The goal is coverage of what matters, not a target percentage.
What’s the difference between agile testing and regression testing in agile?
Agile testing covers every testing activity inside a sprint, from acceptance tests to exploratory sessions. Regression testing in agile is one part of it, focused only on confirming that existing features still work after each change.