Before every meaningful update
Re-test what already worked before you ship what's new
A regression cycle re-tests your existing functionality before a release, across the critical flows and devices your users rely on, so an update that adds a feature doesn't break logging, booking or checkout without anyone noticing.
What you get
What’s included
Regression checklist, reused or written
We run your existing checklist, or write one from your critical flows if none exists. You keep it afterwards.
A full pass over existing flows
Every flow on the checklist re-tested on the release candidate build.
Device and browser coverage
Run across an agreed device and browser matrix, on physical hardware where the risk is highest.
Extra checks around the change
Closer attention to the areas the new code touches, based on what your developers tell us changed.
Regression report
Each regression logged with severity, environment, reproduction steps and frequency, ready for your developers.
A good fit if
- Teams shipping an update that touches shared code like sign-in, payments or sync
- Apps upgrading frameworks, OS targets or major dependencies
- Products whose last release broke something that used to work
- Teams with a regression checklist from earlier QA work and nobody to run it
Not included
- In-depth testing of brand-new features. An exploratory cycle does that
- Writing automated regression tests
- A go/no-go recommendation, which comes with QA & Release Readiness
- Fixing the regressions found
How it runs
From kickoff to handover
- Step 1
Changes and checklist
You share what changed and the release candidate build. We confirm your checklist or write one.
- Step 2
Run the regression pass
Every critical flow re-tested across the agreed devices, with extra checks around the changed areas.
- Step 3
Report
Regressions written up and prioritized, so your team knows what to fix before the release goes out.
Questions
Questions about Regression cycle
We already have automated tests. Do we still need a regression cycle?
Automated tests catch what they were written to catch. Manual regression catches layout breaks, permission dialogs, sync problems on real devices and anything nobody thought to automate. If you're unsure where that line should sit, QA automation discovery is a separate service that plans which tests are worth automating.
How often should we run one?
Before any release that touches shared code, upgrades dependencies or changes payments, sign-in or data sync. If that describes every release, ongoing QA includes regression before each one.
What if we don't have a regression checklist?
We write one from your critical flows as part of the cycle, and it stays with you.
Should we book a regression cycle or release readiness?
Regression checks that existing features still work. Release readiness adds a test strategy, exploratory testing of the new work and a written go/no-go. For a routine update, regression is usually enough. For a launch or a major version, choose release readiness.
Do you test on staging or on the live app?
On the release candidate, which usually means staging or a test build. Testing the build you plan to ship is the point of the cycle.
More from QA & Release
Keep exploring
Often paired with this
Work with us
Ready to start Regression cycle?
Tell us about your business. We'll confirm the scope and send you a start date.