What This Is
Regression testing is the practice of running your existing tests on every change to make sure the change has not broken anything that previously worked. It is not a separate test suite — it is the discipline of running the suite you already have, on every commit, and treating any failure as a blocker.
The bugs regression testing catches are the most demoralising kind: a feature that worked perfectly last week stops working this week because someone made an unrelated change in a different part of the system. Without regression testing, you find out from a user. With regression testing, you find out from CI before the change is even merged.
This service is most often delivered as a process and tooling engagement, not just a writing engagement. The technical work is making sure tests run consistently, fail loudly, and recover quickly when they break. The organisational work is establishing the team norms that keep regression testing trustworthy: a failing test must be fixed, not disabled, and a fix must include a test that prevents the same bug from recurring.
When You Need This
Regression testing becomes urgent when:
- The same bug — or the same kind of bug — keeps coming back in different forms after each release
- Your team has tests but they are run inconsistently — some commits run them, some do not
- Releases are getting slower and more nervous because nobody is sure what a given change might break
- A previous incident cost real money or customers and the postmortem identified missing test coverage
- You have inherited a codebase with patchy tests and need a strategy for closing the gaps without rewriting everything
This is not the right service if you have no test suite at all — there is nothing to regress against. We start with Automated Testing in that case and bring the regression discipline as part of the build.
How We Work
Regression testing engagements focus on closing the gaps that let regressions through. The first question is not “what tests are missing” but “what regressions have happened recently, and why did the existing suite not catch them.” Postmortem-driven test writing produces tests that protect against bugs that have actually occurred — not theoretical ones.
Every fixed bug becomes a test. When we fix a regression for a client, we add a test that fails before the fix and passes after it. That test stays in the suite forever. The next time someone makes a change in that area, the test is there to catch the same class of bug if it tries to come back. Over time the suite becomes a recorded history of every bug the system has ever had.
We address flaky tests as a priority. Flaky tests destroy regression testing more than missing tests do, because they teach the team to ignore failures. We quarantine flaky tests, fix the underlying instability (race conditions, time-dependent assertions, shared state), and bring them back to the main suite once stable.
We tighten the merge gate. Tests that run but do not block do not protect anything. We configure CI so that a failing test prevents the merge, full stop. No bypass, no override, no “we will fix it after.” The cultural shift is the most valuable part of the engagement.
What You Get
- Regression test suite built from the bugs that have actually hit your system, not hypothetical ones
- Postmortem-to-test workflow — every incident produces a test that prevents recurrence
- Flaky test triage — existing flaky tests fixed or quarantined, with a process to keep the suite trustworthy
- CI gate configuration so failing tests block merges and deploys
- Coverage analysis identifying the highest-risk areas with no current protection
- Team documentation on how to add regression tests when fixing bugs
- Optional retainer for ongoing test health and gap-closing
Technologies We Use
The technologies are the same as our other testing engagements — PHPUnit, Pest, Vitest, Playwright, Bitbucket Pipelines, GitHub Actions. What distinguishes regression testing is the process layered on top, not the tools.
Related Systems
Regression testing protects every system we build, but the value is greatest in systems where bugs have real-world cost. A billing system where a regression could miscalculate VAT would be expensive to repeat. A contract management system where a regression could allow a signed document to be altered would be a compliance issue. The systems where bugs hurt most are the systems that need regression testing most.
Talk to Us About Stopping Regressions
If the same bugs keep finding their way back into your system, get in touch and we will scope an engagement that turns each one into a test that holds the line.
