What is Regression Testing?

What is regression testing?

Regression testing is the practice of rerunning your existing test suite against every code change to confirm that nothing previously working has broken. The word "regression" means a backwards step: a feature that passed yesterday and fails today. Regression tests catch those backwards steps before they reach users.

Every shipped bug becomes the seed of a regression test. The fix lands with a new test that reproduces the bug, and from then on the suite asserts that bug never returns. Over years, the regression suite becomes the executable memory of every defect the team has paid for.

Regression testing vs smoke testing vs full QA

Three layers, increasing scope:

• Smoke testing: seconds. Did the build come up? 5-15 critical-path checks. Gate-only.
• Regression testing: minutes to an hour. Did anything that used to work now break? Hundreds to thousands of tests covering every shipped feature.
• Full QA / acceptance: hours, often manual. Does every flow meet spec for the upcoming release? Includes exploratory + manual checks.

Regression sits in the middle and is the test type most teams invest in most heavily, because it's automatable, repeatable, and gates every merge.

Functional vs visual vs performance regression

• Functional regression. Unit, integration, end-to-end tests. "Add to cart still adds an item." The majority of any regression suite.
• Visual regression. Screenshot comparison; pixel diffs flag unintended CSS or layout changes. Tools: Percy, Chromatic, Playwright's toHaveScreenshot().
• Performance regression. p95 latency at expected load shouldn't degrade between releases. Run a load test against the baseline and the new build; assert latency, throughput, and error rate didn't get worse. Easy to skip and the first thing to bite in production.

When to run regression tests

1. On every pull request. Before merging. The PR doesn't merge unless regression passes.
2. On every main-branch commit. Catches integration issues from concurrent PRs that each passed individually.
3. Pre-release. A complete regression run against the release candidate before deploy. Often slower / more thorough than the per-PR run.
4. Nightly. The expensive parts of the suite (browser tests, performance regression, long-running integration) run overnight without blocking developer flow.

Key regression-testing practices

1. Every fixed bug gets a test. The fix and the regression test land in the same commit. No exceptions.
2. Tests are deterministic. Flaky regression tests train the team to ignore failures. Eliminate timing assumptions, mock external services, fix or delete flakes within a week.
3. Tests run fast. A full PR-blocking regression run should finish in under 10 minutes; otherwise developers context-switch and lose flow. Parallelize.
4. Performance is part of regression. A load test in CI/CD with assertions on p95 + error rate catches the slow drift that functional tests miss.

How to run performance regression

Take the same script you use for load testing and run it against both the baseline build and the new build at identical load. Compare p95, p99, throughput, and error rate.

In JMeter, save the JTL output and diff aggregated metrics. In k6, use thresholds in the script: http_req_duration: ['p(95)<800'] fails the build when p95 exceeds 800 ms. Failed thresholds set the exit code, so CI catches the regression automatically.

For multi-region load against a real CDN edge, run from LoadFocus. Performance regression that ran from a single local machine misses regressions in geo-distributed paths (DNS, edge cache, regional database failover).

If your team doesn't have time to build performance regression into CI, LoadFocus offers load testing services where engineers design the regression scenarios, wire them into your pipeline, and triage failures against historical baselines.