Regression testing is the practice of re-checking features that already worked to confirm they still work after a change. A regression is when something that used to behave correctly stops doing so, often in a part of the system nobody meant to touch. For a business, that might be a booking confirmation that no longer appears, a login that fails on one browser, or a report that suddenly shows the wrong totals.
Why a change can break something nobody touched
Business systems are made of connected parts. A small edit in one place can reach further than expected because:
- Code is shared. A function that formats dates or calculates prices may be used by several pages, so fixing it for one screen can change the result on another.
- Data changes shape. Adding a field, renaming a status or changing a database rule can affect reports, exports and integrations that read the same data.
- Dependencies are updated. Libraries, frameworks, browsers and mobile operating systems receive updates that can change how existing code behaves.
- Connected services change. A payment, messaging or ERP system may update its API or its behaviour, and the part of your system that talks to it may need to adapt.
Testing only the new feature does not catch these side effects. Regression testing looks back at what was already working.
What a regression test checks
A regression test repeats an agreed set of steps and compares the result with what is expected. Good candidates are the journeys that matter most to the business and its users, such as:
- signing in and resetting a password;
- submitting a form, booking or order and receiving the confirmation;
- role permissions, for example confirming that staff accounts cannot reach admin-only screens;
- calculations that affect money or stock, such as prices, discounts or balances;
- data passed to or from connected systems.
Illustrative example: A team changes the layout of a booking page to add a promotional banner. The banner displays correctly, but on smaller screens the change pushes a button out of reach so it can no longer be tapped. A regression check that completes a booking at a mobile screen size would flag the problem before customers run into it.
Manual and automated regression testing
Regression testing can be done by a person following a written checklist, or by automated scripts that run the same steps in a browser or a mobile app. The two approaches work well together.
- Manual checks suit journeys that change often, need human judgement or are run rarely. They depend on the tester having enough time and following the same steps each round.
- Automated checks suit stable, important journeys that are repeated many times, for example before every release. They run the same way each time and can keep evidence such as screenshots and step logs, but they need updating when the journey itself is changed on purpose.
Many teams start with a short manual checklist for their most important journeys, then automate the checks they repeat most often.
Where to start
Testing every screen and button is rarely practical. A more useful approach is to:
- List the critical journeys: the steps where a failure would stop sales, bookings, payments or daily operations.
- Write down the expected result for each step, so that "working" has a clear meaning.
- Prepare safe test data and accounts, so checks do not create real orders, send real messages or move real money.
- Decide when checks run: before each release, after dependency or integration updates and, where agreed, as scheduled non-destructive checks in production.
- Agree who acts on a failure and how it is reported.
What regression testing does not do
Passing regression tests shows that the checked steps behaved as expected in the tested environment. It does not prove that a system has no bugs. Regression testing is also separate from security, performance, accessibility and usability testing, which need their own methods. Treat it as one safety net among several, and review what it covers when the system changes.
If your system already has a support arrangement, the software support SLA can state which journeys are re-checked before releases. Systems with many connections also benefit from regression checks around each integration point; read what system integration is.
For a service-focused overview, see technine.io’s automated UI and user journey testing service.
Frequently asked questions
Is regression testing the same as testing a new feature?
No. Testing a new feature checks that the new behaviour works. Regression testing checks that existing behaviour still works after the change. A release usually needs both.
How often should regression tests run?
At minimum, before changes reach users. Many teams also run them after updating libraries, platforms or connected services. The right frequency depends on how often the system changes and how costly a failure would be.
Do small businesses need automated regression testing?
Not always. For a system that changes rarely, a written checklist covering a few critical journeys may be enough. Automation becomes more useful as releases become more frequent or the same checks take too long to repeat by hand.