Regression Test

Origin & evolution

The IEEE defines regression testing as the selective retesting of a system or component to verify that modifications have not caused unintended effects and that it still meets its requirements (summarised on Wikipedia). The idea is as old as software maintenance: once teams could change shipped code, they discovered that a fix for one problem routinely broke something nearby, and that old faults re-emerged after being patched.

A durable discipline crystallised around that observation👁️ObservationUser ResearchA specific behaviour or statement observedView reference →: add a test for every bug. When a defect is found, you first write a failing test that reproduces it, then fix the code until the test passes, and the test stays in the suite permanently. The reproduction becomes a tripwire. If the same defect is ever reintroduced by a later change, the test fails before the bug reaches a user.

The field also learned the cost. Wikipedia notes that fixes are often fragile, correcting the narrow case first observed while leaving general cases open, which is exactly why the guarding test earns its keep. The counter-pressure is suite bloat: a regression set that accretes a test per bug for years grows slow and noisy, so mature teams treat regression-suite curation, pruning duplicates and merging overlapping cases, as ongoing maintenance.

How it works in practice

A payments team ships a discount-code feature. A user reports that stacking two percentage codes produces a negative total. The engineer reproduces it, writes a test asserting that applyDiscounts(["SAVE20","SAVE15"]) floors at zero, watches it fail, then fixes the clamp logic until it passes.

That test now lives in the suite forever. Eight months later, an unrelated refactor of the pricing engine reorders how discounts compound. The negative-total test goes red in CI before the change merges. Nobody remembered the original incident🚨IncidentDevOps & PlatformA production incidentView reference →, and nobody needed to. The regression test carried the memory of a past failure into a present that had forgotten it.

Regression test vs. its neighbours

• Bug is what the regression test remembers. The bug is the defect that occurred; the regression test is the durable assertion written so the same defect cannot recur silently. One bug typically yields exactly one regression test, through regression_test_addresses_bugRegression TestaddressesBugcross-domain.
• Test suite📂Test SuiteQuality AssuranceA suite of related testsView reference → is the home, not the kind. A regression test is an ordinary test case🌵Test CaseQuality AssuranceAn individual test caseView reference → whose role is guarding against reintroduction; the suite is where it runs alongside feature and integration tests. Regression testing is a purpose a suite serves, not a separate suite.
• Release🚢ReleaseProduct SpecificationA shipped version of the productView reference → is what the regression set protects. New-feature tests prove that what you are adding works; regression tests prove that what already worked still does. The regression layer is the safety net under a release, which is why teams gate ship decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → on it.

In the graph

In the Unified Product Graph, regression_test♻️Regression TestQuality AssuranceA regression test sits in the quality and testing region as a specialised member of a suite. It joins its collection through test_suite_includes_regression_testTest SuiteincludesRegression Testhierarchy, traces back to its origin defect through regression_test_addresses_bugRegression TestaddressesBugcross-domain, and connects forward to the ship gate through regression_test_guards_releaseRegression TestguardsReleasecross-domain. That triangle, suite to bug to release, is what makes regression coverage queryable: the graph can show which past defects are still guarded, and which releases ship without that net.