Types of Regression Testing: Corrective, Progressive, Selective, and Complete

Corrective Regression Testing

Corrective regression testing re-runs the existing test suite without modifying any test cases. It applies when the code change does not alter the specified behavior of any feature. Common scenarios include performance optimizations, internal refactors that do not change public interfaces, dependency version bumps, and infrastructure changes like switching from one database host to another.

The key characteristic is that no test should need updating. If the change was purely internal, the existing tests describe the expected external behavior, and they should all still pass. Any failure is a genuine regression, not a test that needs adjusting to match a new specification. This makes corrective regression the easiest type to automate and the most efficient to run, because the suite requires zero preparation before execution.

The risk with corrective regression is overconfidence. If the test suite has gaps, a change might be internally correct but break an untested behavior. A refactor that changes the order of database writes might pass every test while silently breaking a downstream process that depends on write ordering but was never tested. Corrective regression is only as strong as the coverage of the existing suite.

Progressive Regression Testing

Progressive regression testing happens when the change intentionally alters feature behavior, requiring test updates alongside the code changes. A redesigned user registration flow with new validation rules, an API version that adds required fields, or a pricing engine that now applies regional tax rules all demand tests that match the new specification.

The workflow has two parts. First, update or write tests to cover the changed and new behavior, ensuring they pass against the new code. Second, run the entire updated suite to verify that the changes did not break unrelated features. The first part is standard feature testing. The second part is the regression testing, and it is where side effects surface.

Progressive regression testing requires more effort per cycle than corrective because someone must decide which tests to update, write the new test logic, and verify that the updates accurately reflect the new specification rather than simply making a failing test green. A common mistake is updating a test to match the new output without confirming the new output is actually correct. The test passes, but it is validating a bug.

Teams that skip the "run the full suite" step of progressive regression end up with updated tests that pass in isolation but miss the side effects of the change on other parts of the system. A new tax calculation rule might work perfectly in the pricing tests while breaking the invoice generation tests that downstream consumers depend on. Running the full suite after updates catches this class of problem.

Selective Regression Testing

Selective regression testing runs a carefully chosen subset of the full test suite, including only the tests that could potentially be affected by the change. It is the primary tool for keeping large regression suites practical in fast-moving codebases where running everything on every commit would take hours.

The selection can follow several strategies. Code dependency analysis traces which tests exercise the changed code, directly or transitively, and selects only those. Risk-based selection picks tests based on the likelihood and severity of failure in the affected area. Historical analysis selects tests that have historically been most likely to fail when similar code was changed. Each method trades accuracy for speed in different ways.

The danger of selective regression is missing tests that should have run. If the selection algorithm does not trace an indirect dependency, a test that would have caught a regression gets skipped, and the regression merges silently. Teams mitigate this risk by running the full suite periodically, typically nightly or before releases, to catch anything selective runs missed. The combination of selective runs on every commit and complete runs on a schedule is the standard pattern in mature continuous integration setups.

Tooling for selective regression has improved significantly. Playwright supports tagging and sharding, letting teams tag tests by feature area and run only the relevant tags on a given change. Jest and pytest both support running tests related to changed files. Specialized test impact analysis platforms go further by instrumenting code coverage per test and building a dependency map that automates the selection entirely.

Complete Regression Testing

Complete regression testing runs every test in the suite against the changed codebase. It provides the highest confidence that no regression exists anywhere, at the highest cost in time and compute.

Complete regression makes sense in three situations. First, for small suites that run in minutes, where selective approaches save negligible time and add unnecessary complexity. A suite of 500 unit tests that finishes in 30 seconds should always run completely. Second, before major releases or production deployments, where the cost of missing a regression is high enough to justify the wait. Third, after changes with broad potential impact, like framework upgrades, compiler version changes, or modifications to core shared libraries that touch every part of the system.

For suites that take hours, complete regression is usually reserved for nightly or weekly runs rather than per-commit checks. The nightly results serve as a backstop: if a regression slipped through the selective runs during the day, the complete run catches it overnight, limiting the blast radius to one business day of commits. This pattern works well when the team reviews nightly results first thing each morning and treats failures as high-priority work.

Parallelism reduces the wall clock cost of complete regression significantly. Splitting a 60-minute suite across 10 CI runners cuts the wait to 6 minutes. Modern frameworks support this natively: Playwright shards by test file, pytest-xdist distributes across processes, and CI platforms like GitHub Actions and GitLab CI support matrix strategies that spin up parallel jobs automatically. The compute cost stays the same, but the developer experience changes from "blocks the afternoon" to "ready before the coffee is done."

Unit-Level Regression Testing

Unit-level regression runs isolated tests against individual functions, methods, and classes. These tests do not start servers, open browsers, or connect to databases. They test logic in isolation, typically by providing inputs and asserting on outputs, and they run in milliseconds per test.

Unit-level regression is the foundation of every regression strategy because of its speed and specificity. A failing unit test tells you exactly which function broke and what input triggered the failure, which is far more diagnostic than a failing E2E test that says "the checkout page shows an error" without pointing at the cause. Running thousands of unit tests on every commit is practical even on modest CI hardware, making complete unit-level regression the default for most teams.

The limitation is scope. Unit tests verify that individual pieces work correctly in isolation, but they do not verify that the pieces work correctly together. A function that calculates tax correctly can still participate in a regression if the calling code passes it the wrong arguments after a refactor. Integration and end-to-end tests fill this gap by testing the assembled system, and a practical regression strategy uses all three layers.

Partial Regression Testing

Partial regression testing is a looser term for running some but not all tests, typically those in the immediate vicinity of the change. It is less formal than selective regression because the selection is usually manual rather than algorithm-driven: the developer eyeballs the change, picks the tests that seem related, and runs those.

Partial regression works acceptably for small teams with small codebases where one developer understands the whole system. It breaks down as the codebase grows, because the "eyeball the impact" step becomes unreliable when the developer cannot trace all the call paths in their head. Most teams that start with partial regression eventually formalize it into selective regression with tooling support, or they adopt complete regression and invest in parallelism to keep it fast.

How Types Apply to Real Scenarios

The abstract categories make more sense with concrete situations. Consider a web application with a suite of 2,000 unit tests, 300 integration tests, and 80 end-to-end browser tests.

Scenario one: a developer refactors the database access layer to use connection pooling instead of individual connections. No behavior changes, only internal implementation. This is corrective regression. Every existing test should still pass without modification. Run the full unit suite on the commit, the integration tests on the PR (since the database layer is directly involved), and the full suite nightly to confirm nothing was missed.

Scenario two: the product team adds a new payment option, buy now pay later, alongside existing credit card and PayPal options. This is progressive regression. New tests are written for the BNPL flow, existing checkout tests are reviewed to confirm they still accurately describe the other payment paths, and any tests that assumed "payment method" is always a credit card or PayPal get updated. The full suite runs to verify the new option integrates cleanly.

Scenario three: a different developer fixes a bug in the search ranking algorithm, a change that only affects the search module. The team uses selective regression, running the 150 unit tests tagged as search-related and the 12 E2E tests that exercise search functionality, skipping the 1,800 unit tests and 68 E2E tests that have nothing to do with search. The selective run finishes in 3 minutes instead of the full suite's 25 minutes.

Scenario four: the team is preparing a major release that includes six merged PRs touching authentication, checkout, search, and the admin dashboard. Each PR was selectively regression tested when it merged, but the combination of all six has not been tested together. This calls for complete regression, running every test in the suite across all browsers, to verify the combined changes have no aggregate side effects.

Choosing the Right Type

The choice is not exclusive. Most teams use multiple types at different stages of their workflow. A practical combination looks like this: unit-level regression runs completely on every local save and every CI push. Selective regression runs integration and E2E tests affected by the changed code on every pull request. Complete regression runs the full suite nightly and before releases. Progressive regression applies whenever a feature change requires test updates, with corrective regression as the default for all other changes.

The goal is not to pick one approach and commit to it forever, but to match the regression type to the risk and the timeline. Fast feedback on every commit catches most problems cheaply. Periodic comprehensive runs catch whatever the fast runs missed. The balance point shifts as the suite grows, the CI infrastructure scales, and the team's tolerance for test execution time evolves.