Regression testing

Definition

Regression testing is about protecting established behavior from unintended change. It is not a single test type. A regression suite can include a quick unit test, an API integration test, or a full system scenario when each is relevant to a risk introduced by the change.

Selecting regression coverage

Start with the changed code, its dependencies, and the behavior that could be affected. A fix for a tax calculation may need boundary cases around pricing and an integration check for persisted totals. A change to authentication may require broader permission and session scenarios. The best regression test is specific enough to catch the risk and stable enough to provide reliable feedback.

Teams can add a test after a defect is found so that the same failure is less likely to return. They should also remove or revise tests when requirements change. Keeping every historical test forever can make the suite slow, redundant, and harder to trust.

Example

Imagine a change that optimizes the code selecting a user's shipping region. Existing tests for domestic orders pass, but the change could affect international orders and the fallback for an unknown postal code. A focused regression run adds those cases and verifies both the selected region and the final shipping rule.

The regression label describes why the tests are being run after the change. The individual checks may still be unit, integration, or system tests.

Limitations

Regression testing only protects behavior represented by its tests. It will not find a new failure in an untested scenario, an incorrect requirement, or a production-only configuration problem. Do not treat a green regression suite as proof that a release is risk-free. Pair it with exploratory testing, review, monitoring, and tests targeted at the new behavior.