Regression testing

Regression testing is the repeated execution of tests to confirm that a modification to software has not caused a regression — that is, the reappearance of a bug or the breaking of a feature that previously worked. The name describes not a technique for writing a test, but the reason for running it: making sure new changes have not damaged an existing part of the system.

How regression testing works

Every time a new feature, a fix or a refactor lands in the code, there is a risk it will break a seemingly unrelated element — because they share a function, data or application state. To catch this, previously written unit tests, integration tests and end-to-end tests are run again. When a test that used to pass suddenly turns red, that signals a regression to fix before deployment. On large projects the full suite can take hours, so teams apply test selection (running only the tests related to the change) and prioritisation. A separate case is visual regression, where screenshots of the interface are compared to detect unintended changes in appearance.

Practical application

Regression testing only makes sense when it is automated and run consistently — manually repeating hundreds of scenarios after every change is impossible. That is why it is wired into the CI/CD pipeline: each commit automatically fires the whole suite, and a failing test blocks the release. A good practice is the rule that whenever a new bug is found, you first write a test that reproduces it and only then the fix — so the same bug never returns unnoticed. As a result, a growing regression pack acts as a safety net that lets the team change code confidently without fear of breaking working features.