What is regression testing?
Regression testing re-runs checks on existing behaviour after a code change to confirm that nothing that used to work has broken. It covers the parts of the application the change could affect, as well as the new feature itself.
Decide what a regression run must cover.
Start with the behaviour your users and your business depend on: payments, access rules, pricing and the journeys people use every day. A focused set that runs on every change is worth more than a complete suite nobody waits for. Add checks where defects have appeared before, and retire checks that no longer protect anything.
Run regression checks automatically.
Automated regression testing works best when nobody has to remember to start it. With Cue April, set an approved schedule or watch selected branches, and eligible checks start within your standing scope and budget. Repeat runs need current authority, an available runner and enough budget, and a blocked run stays visible instead of silently passing.
- Run unit, API, Playwright and Gherkin suites against the tested revision.
- Keep passed, failed, blocked and incomplete checks distinct.
- Review the evidence from each run before the release decision.
Turn every confirmed bug into a check.
When a run finds a defect, reproduce it, fix it and keep the case. Cue April can turn an approved finding into a regression draft, including a portable Playwright regression from a verified exploratory finding. Your team reviews each draft before it joins the suite, and a fresh run verifies what the fix actually changed.
Check that the suite would notice a fault.
A regression suite that always passes may be testing too little. Mutation testing makes small, deliberate changes to the code and shows which ones the suite misses, so you can strengthen the checks that guard your riskiest code.