# What is regression testing?

Regression testing checks that a change has not broken behavior that worked before, including parts of the software the change did not touch.

Last updated September 29, 2026, 8 min read

## Learning objectives

After reading this article you will be able to:

-   Define regression testing and a software regression
-   Explain how to choose what to rerun after a change
-   Distinguish regression testing from retesting a fix

## Related content

-   [What is software testing?](https://specstory.com/learning/testing/software-testing)
-   [What is smoke testing?](https://specstory.com/learning/testing/smoke-testing)
-   [What is end-to-end testing?](https://specstory.com/learning/testing/end-to-end-testing)
-   [What is the difference between unit, integration and end-to-end tests?](https://specstory.com/learning/testing/unit-vs-integration-vs-e2e-tests)

## What is regression testing?

Regression testing is a type of testing that reruns existing tests after a change to check that earlier behavior still works. It checks more than the changed code, because a change in one file can break a feature in another. A test that runs again for this reason is a regression test.

The defect it checks for is a software regression. A software regression is a defect where a feature that worked before a change fails after it, often in code the change did not touch. The word regress means to go back to a worse state. A dependency update can cause a regression too.

The International Software Testing Qualifications Board (ISTQB) [defines regression testing](https://glossary.istqb.org/en_US/term/regression-testing) as testing that checks, after a change, whether defects were introduced or uncovered in unchanged parts of the software. The ISTQB keeps it separate from [retesting a fix](https://specstory.com/learning/debugging/bug-fix-verification). Many guides use "regression testing" for both.

Regression testing is not a level of [software testing](https://specstory.com/learning/testing/software-testing), so any test can be a regression test, from a unit test to an [end-to-end test](https://specstory.com/learning/testing/end-to-end-testing). The regression tests in a [test suite](https://specstory.com/learning/glossary#test-suite) are often called the regression suite. Teams usually automate them, because the checks repeat after each change.

## How does regression testing work?

Regression testing follows a loop after each change:

1.  A developer records a change in a [commit](https://specstory.com/learning/glossary#commit).
2.  A continuous integration and delivery ([CI/CD](https://specstory.com/learning/ci-cd/ci-cd)) pipeline, or the developer, chooses which existing tests to rerun.
3.  The test runner runs those tests against the changed code.
4.  The test runner reports which tests now fail.
5.  A person checks whether each failure is a regression or an intended change.

Diagram: How a regression test finds a regression

The same tests run before and after the change. A test that passed before and fails after flags a likely regression.

Step 2 is the hard part, because a full suite can be too slow for each change. Guides often list the choices as the types of regression testing:

-   **Retest all.** The whole suite reruns. This is also called full or complete regression testing. It skips nothing and takes the longest.
-   **Test selection.** The test runner reruns only the tests linked to the files changed since a given branch or commit, e.g. with the `--changedSince` flag in Jest. It is also called selective or partial regression testing, and [test impact analysis](https://specstory.com/learning/ci-cd/test-impact-analysis) is one way to do it. It can skip a test that depends on the change in a way the links do not record.
-   **Test prioritization.** The tests most likely to fail run first, e.g. those that cover the changed code. The whole suite still runs, but failures appear sooner.

Teams often combine them. A short [smoke test](https://specstory.com/learning/testing/smoke-testing) runs on each commit, a selected set runs before a merge, and the full suite runs nightly or before a release. Running tests on each commit ties a failure to the change that caused it.

## What is an example of a regression?

Here is an illustrative example. Acme Co. sells furniture online. Its test suite has an older test that adds 2 items to the cart and checks that both are still there at the end of checkout.

A developer asks a [coding agent](https://specstory.com/learning/ai-coding/coding-agent) to "Let customers edit their delivery address during checkout." The agent changes how checkout saves the address and adds a test for the address field. That test passes. The CI/CD pipeline then reruns the checkout tests linked to the changed files, and the older cart test fails:

```text
FAIL tests/checkout.test.js
  ● checkout › keeps cart items through checkout

    expect(received).toHaveLength(expected)

    Expected length: 2
    Received length: 0
    Received array:  []
```

The address saved, but the cart emptied. The cart worked before the change and fails after it, and the request never mentioned the cart. That failure is a software regression. The agent's own test could not catch it, because that test checked only the address.

The agent changes the checkout code again. The team reruns the failing cart test to confirm the fix, then reruns the rest of the suite to check that the fix broke nothing else. This example is simplified. A real project would also rerun checks on the other checkout steps, e.g. the order total.

## What changes when a coding agent writes the code?

On the [SWE-CI benchmark](https://arxiv.org/abs/2603.03823), most models kept a codebase free of regressions in fewer than a quarter of long-running maintenance tasks. The benchmark counts a regression when a code change makes a test that passed before fail.

When a coding agent writes a change, the existing regression tests are often the only checks in the run that the agent did not write. The agent generates its added tests from the same prompt as its code. Those tests usually check the feature the agent built and miss the [working features](https://specstory.com/learning/debugging/agents-break-working-features) it broke.

The agent can also edit those older tests. If a regression test fails and the agent changes its expected value to match the broken output, the suite passes while the behavior stays broken. That result is a [false pass](https://specstory.com/learning/verification/false-pass).

A practical adjustment is to run the regression suite from a copy the agent cannot edit, e.g. the test files on the main branch. The old expected results then still apply until a person approves a change in behavior.

## What are the limits of regression testing?

The main limits of regression testing are these:

-   **It covers only old behavior.** A regression suite checks only what earlier tests recorded. Code with no tests has no regression check until someone adds one, e.g. with [golden file testing](https://specstory.com/learning/test-quality/golden-file-testing), which saves current output as the expected result. A passing suite is not the same as complete coverage.
-   **It costs time.** Rerunning a large suite on each change is slow. Test selection saves some of that time at the risk of skipping the test that would have failed.
-   **Flaky tests blur the result.** Regression testing depends on the same code giving the same result. A [flaky test](https://specstory.com/learning/debugging/flaky-tests) can fail on unchanged code, so a failure after a change is not always a regression.
-   **Intended changes fail too.** When a team changes behavior on purpose, the tests for the old behavior fail. A person decides which failures are regressions and which tests to update.

## How is regression testing different from retesting a fix?

Retesting a fix repeats the exact steps that exposed a defect, on the fixed code, to confirm that the failure is gone. The ISTQB calls this [confirmation testing](https://glossary.istqb.org/en_US/term/confirmation-testing). Regression testing is broader. It checks whether the fix, or any other change, broke something that worked before.

The two overlap after a fix, because the retest usually stays in the suite as a regression test. Teams that verify a bug fix usually run both, the retest first.

## How does RunStory help with regression testing?

A regression suite checks only the workflows its tests already cover. What passed before needs to remain true, unless someone explicitly decides otherwise. RunStory runs your software in a separate environment, tries relevant workflows, and checks the results.

Your coding agent receives the actions RunStory took and evidence of the unexpected result. After your agent makes the change, RunStory repeats the failing workflow to check that the problem is resolved. It is in private alpha for CLIs and web apps.

[Join the RunStory alpha →](https://specstory.com/runstory#alpha)

## FAQs

### What does regression test mean?

A regression test is an existing test that runs again after a change to check that earlier behavior still works. The word regress means to go back to a worse state. A regression test that passed before and fails after a change points to a software regression.

### Are regression tests the whole suite or a sample?

Regression tests can be the whole suite or a selected sample, and teams often use both. A selected sample can run before each merge because it is faster. The whole suite runs nightly or before a release, because selection can skip the test that would have failed.

### When should a regression test run?

A regression test should run after any change that could affect existing behavior, including a bug fix and a dependency update. Many teams run a short set of tests on each commit and the full suite nightly or before a release. Frequent runs tie a failure to the change that caused it.

### Is a failing regression test always a bug?

A failing regression test is not always a bug, because the change may have altered that behavior on purpose. A person checks each failure and decides whether it is a regression or an intended change.

---

Source: [What is regression testing? | Types and examples | SpecStory](https://specstory.com/learning/testing/regression-testing)