02 /QA & Manual Testing
Regression Testing
A maintained pass over behaviour that already worked, run before a release so a change in one area does not quietly break another. The hard part is not running it — it is keeping the suite small enough to stay affordable and broad enough to still catch things.
What you get
A risk-ranked regression suite
Built from what actually breaks and what costs most when it does, rather than from an attempt to re-test everything. A suite nobody can finish is a suite nobody runs.
A release-gate pass
Executed on a candidate build with a clear verdict: what passed, what failed, and what that means for shipping. A pass with unresolved failures and no recommendation is not a decision.
Defect verification
Every fix from the previous cycle is retested explicitly. Regression suites often assume fixes stayed fixed, which is exactly the assumption regression testing exists to challenge.
Suite maintenance
Cases are retired as features change, not left to accumulate. An unmaintained regression suite spends its time reporting failures that are the suite’s own fault.
How it runs
- 01
Establish the baseline
We work out what "already worked" means: which flows are stable, which are still moving, and which have a history of breaking. Defect history is more useful here than the feature list.
You provide: Release history and any record of past incidents
- 02
Rank by risk
Each candidate area gets weighed by consequence and by how often it has actually broken. The output is a suite ordered so that stopping halfway still leaves the important part done.
We produce: A ranked regression suite
- 03
Run against the candidate
Executed on the build you intend to ship, in an environment that resembles production closely enough for the result to mean something.
We produce: Execution record · Defect reports
- 04
Report with a recommendation
A go / no-go view with the reasoning, so the release decision is yours to make on evidence rather than on a percentage.
We produce: Release report with a recommendation
Where this stops
- Not automated by default. If your release cadence justifies it, automating this suite is the right move — but that is a framework build, and it is a different piece of work with a different cost.
- Not a replacement for testing the new feature. Regression covers what already worked; the change itself needs its own coverage.
- Not a guarantee. A regression pass reduces the chance of a known-good area breaking; it does not eliminate it, and any supplier who says otherwise is overselling.
Related reading
- Quality assurance
How to write a bug report a developer can act on
A defect report is a handover of an unfinished investigation. Most of them fail in the same three places, and none of the repairs involve a longer template.
- Test automation
Test data management: five strategies and what each one costs
How a test obtains the state it needs decides whether a suite survives parallel execution. Five approaches, the failure mode of each, and the problems nobody puts in the estimate.
- Test automation
When to automate a test, and when the answer is no
Not a philosophy of automation but a decision taken one case at a time. Five signals, four possible verdicts, and why "keep it manual" is not the losing option.
FAQ
Regression Testing questions we hear often
How long does a regression cycle take?
It depends entirely on suite size, and suite size is a choice rather than a fact. We would rather agree a timebox first and fit a risk-ranked suite inside it than quote an open-ended cycle — that way the constraint shapes what gets covered instead of surfacing as an overrun.
Should we automate our regression suite instead?
If you release often, eventually yes. The threshold is roughly where the manual pass starts dictating your release cadence rather than fitting inside it. Automating early, before the flows have settled, is how teams end up maintaining scripts that break on every refactor.
What happens when a regression test fails?
It gets triaged before it gets reported. A failure is either a real defect, an intended change nobody told us about, or a fault in the test itself — and reporting all three as bugs is what makes teams stop trusting a suite.
Can you run this on every release?
Yes, and it works best as a standing arrangement, because the value compounds: the suite gets tuned, the false alarms drop, and we build the history that makes risk-ranking accurate rather than speculative.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.