Regression testing is the practice of re-running existing tests after a code change to confirm that features which worked before still work. It catches the side effects of new work: a fixed bug that breaks a neighbouring screen, a refactor that changes an API response, a dependency upgrade that alters behaviour. It runs best as an automated suite on every change.
Why do regressions happen
Software is connected in ways nobody fully holds in their head. A change to a shared function, a database column or a configuration value reaches code its author never opened. The larger the codebase, the more places a small edit can reach. Regression tests turn that hidden coupling into a failing check instead of a support ticket.
What is the difference between regression testing and retesting
Retesting checks that one specific bug is fixed, using the test that exposed it. Regression testing checks that the fix and everything around it did not break anything else. You retest first, then run the regression suite. Both are needed, but only regression testing scales across a whole product.
What types of regression testing are there
Teams usually choose between three scopes:
- Full regression. Run every test. Slowest, used before major releases or after large refactors.
- Selective regression. Run the tests for the modules a change touches, plus their dependants.
- Smoke regression. Run a small set of critical-path tests, such as sign-in, checkout and core API calls, on every commit.
A sensible setup runs smoke tests on every pull request, selective tests nightly and the full suite before release.
How do you build a regression suite that stays useful
Start with the paths where a failure costs money or trust. Add a test every time a bug reaches production, so the same bug cannot return. Keep tests fast and independent, since a slow or flaky suite gets ignored. Delete tests that no longer describe real behaviour, because a suite nobody trusts protects nothing.
Automate the suite in your CI pipeline and make a red build block merging. Manual regression passes still help for exploratory checks and visual review, but they should cover what automation cannot, not repeat it.
What changes when AI writes the code
Coding agents produce changes quickly and often touch more files than a person would in one sitting. That raises the value of regression tests, because review time per line drops while the number of changes rises. The suite becomes the contract the agent has to satisfy. A weak suite means the agent can pass it while breaking behaviour nobody wrote down.
This is why testing software you did not design matters: coverage numbers say little, while tests tied to real behaviour say a lot. Pair a strong suite with a careful review of AI-generated code and keep a person accountable for what merges.
What this means when you hire
A good engineer treats tests as part of the feature. In our vetting, candidates work in a real codebase for two sixty-minute sessions, one with AI tools off and one with their own agents on, and the scorecards show how they verify changes. If you need dedicated test capacity, see QA engineers, from €5,600 a month for a full-time engineer.
How often should you run regression tests
As often as your pipeline can afford. The fast tier should run on every commit, so a failure points at one change. Slower tiers can run nightly. The goal is a short gap between breaking something and finding out, because the cost of a fix grows with every change stacked on top of the bad one.
Short answers
Is regression testing manual or automated?
Mostly automated. Manual passes cover exploratory and visual checks that scripts cannot judge well.
How is regression testing different from smoke testing?
Smoke testing is a small, fast check of critical paths. Regression testing is broader and checks that existing behaviour still works after a change.
How many regression tests do you need?
Enough to cover the paths where failure costs money or trust. Add a test for every bug that reaches production.
Do AI coding agents need regression tests?
Yes. Agents change code quickly, and a strong suite is how a team confirms those changes did not break existing behaviour.
