Regression testing has a bad reputation in most engineering teams. It's the thing that happens at the end of the sprint when everyone's exhausted and the release window is closing. It's the manual grind that somebody has to do. It's the reason QA becomes a bottleneck.
That reputation is earned, but it's earned by doing regression testing badly. When it's done well, with a structured checklist, clear prioritisation, and the right mix of automated and manual coverage, it's the single most reliable way to prevent known functionality from breaking in production. The teams I've worked with who had real regression discipline had significantly lower escaped defect rates and significantly less stressful releases. The numbers backed it up consistently.
This checklist is what we use and refine at goGreenlit. It's designed to be adapted to your product, not followed blindly, but the structure and the prioritisation logic apply across most web applications and SaaS products.
Why most regression testing fails
Before the checklist, it's worth naming the failure modes so you know what you're designing around.
Regression testing is crammed into the last two days of the sprint
When regression testing is a phase rather than a continuous practice, it creates a predictable crisis at the end of every sprint. The checklist is too long to execute in the time available, triage decisions get made under pressure, and things slip through. The fix is to run partial regression checks continuously throughout the sprint, with the full regression suite reserved for pre-release validation.
The regression suite tests the wrong things
Many regression suites grow organically: a bug gets reported, a test case gets added, repeat. The result is a test suite that's dense around historically buggy areas and thin around business-critical flows. The highest-priority regression scenarios should map to the highest business risk, not the highest historical bug count.
Manual regression scales poorly as the product grows
A product with three major features can be regressed manually in a few hours. A product with 30 features and hundreds of integration points cannot. Without automation, regression testing either grows unsustainably or coverage quietly shrinks to fit the available time. The answer is not to automate everything it's to automate the scenarios that are stable, high-value, and repeatably executable.
The regression testing checklist
This is organised into five tiers, ordered by priority. If you're under time pressure, Tier 1 is non-negotiable. Tiers 2 and 3 should be completed before every release. Tiers 4 and 5 are best handled through automation running continuously rather than manually before each release.
Tier 1: Critical path always test these
These are the scenarios where a failure causes immediate, visible damage to users or revenue. Every release, no exceptions.
Critical path checklist
- Core user authentication: login, logout, session expiry, password reset flow
- Primary revenue or conversion flow (checkout, subscription signup, onboarding)
- Key API integrations your product depends on (payment processor, authentication provider, core third-party services)
- Data persistence: create, read, update, delete on your primary data entities
- Role-based access: verify users cannot access resources beyond their permission level
- Error handling on critical paths: what happens when the payment API times out, when a required field is missing, when a session expires mid-flow
Tier 2: High-impact user flows test before every release
These are the scenarios users encounter most frequently or that, if broken, would generate immediate support tickets and churn.
High-impact flows checklist
- User profile management: edit, save, and display of user-controlled data
- Search and filtering functionality on primary content types
- Notification and email trigger flows (verify they fire and contain correct data)
- File upload and download if your product involves user-generated content
- Cross-browser smoke test on Chrome and Safari (the two browsers covering 80%+ of most user bases)
- Mobile responsive check on key flows for any public-facing product
- Pagination, infinite scroll, and list loading on high-traffic views
Tier 3: Integration and data integrity test before releases with backend changes
These scenarios matter most when the release includes changes to APIs, data models, or third-party integrations. Skip them for pure frontend-only releases where no backend changes were made.
Integration and data checklist
- REST API endpoint validation for any changed or adjacent endpoints (status codes, response schemas, error payloads)
- Database query correctness on any queries touched by the release
- Third-party webhook receipts and outbound webhook payloads
- Data migration correctness if the release included a schema change
- Background job and async task execution (verify jobs complete and data lands correctly)
- Rate limiting and throttling behaviour under normal load
Tier 4: Edge cases and negative paths automate these
These scenarios are important but slow and repetitive to test manually. They're best handled by an automated regression suite running on every pull request.
Automation targets checklist
- Form validation: empty required fields, field length limits, invalid format inputs
- Duplicate submission prevention (double-click on submit buttons, network delay scenarios)
- Session and token expiry handling mid-flow
- Concurrent user actions on shared resources
- Character encoding edge cases (special characters, unicode, emoji in user inputs)
- Large dataset handling (what happens at 10,000 records vs 10)
Tier 5: Performance and accessibility run periodically
These don't need to block every release, but they should be verified on a defined cadence rather than ignored indefinitely.
Periodic checks
- Page load time on primary views under realistic conditions (not localhost)
- Core Web Vitals score (LCP, CLS, INP) via PageSpeed Insights
- Accessibility: keyboard navigation, screen reader compatibility on primary flows
- SSL certificate validity and HTTPS redirect behaviour
- Broken link scan on publicly accessible pages
The prioritisation rule we use: For every test case on your regression checklist, ask two questions. First: if this breaks in production, what's the immediate business impact? Second: how often does this area change? High business impact plus frequent change equals Tier 1 or 2. Low business impact plus stable code equals Tier 4 or 5, and it should be automated.
How to make this work inside a sprint without it eating the whole sprint
The checklist above looks like a lot of work when you read it as a sequential to-do list. It doesn't feel that way when it's distributed across the sprint properly. Here's the distribution that works:
Day 1 to 2: Impact analysis
When sprint tickets are assigned, map which existing features could be affected by the changes in scope. This is a 30-minute conversation between QA and the lead developer, not a full analysis. The output is a list of additional regression scenarios to run this sprint beyond the standard checklist the areas that could have been touched indirectly.
During the sprint: Continuous smoke testing
As features complete development and move to staging, run Tier 1 and Tier 2 scenarios against them immediately. Don't wait for all features to be complete. This surfaces integration issues while the code changes are still fresh and cheap to fix.
Day before release: Pre-release regression run
Run the full Tier 1 and Tier 2 checklist on the release candidate build. Your automated regression suite should cover Tier 4 and be running in CI. Tier 3 gets spot-checked based on the impact analysis from day one. This whole session should take 2 to 4 hours, not 2 to 4 days. If it's taking longer, your checklist has grown beyond what can be sustainably executed manually and it's time to push more coverage into automation.
Release sign-off criteria
Define this before the sprint, not the morning of the release. Our standard criteria: all Tier 1 cases pass, all Tier 2 cases pass or have documented known issues with a severity below P1, automated regression suite is green, no P1 defects are open. If these conditions are met, the release goes. If they're not, the release waits. This isn't negotiable on a per-sprint basis, and having it documented means the pressure to ship doesn't override the quality bar.
If your team's regression testing is a manual scramble at the end of every sprint, goGreenlit can help you restructure it. We embed in your sprint cycle, build the Playwright automation suite, and establish the regression process your product actually needs.
Book a free call →How much of this should be automated?
The honest answer is: as much of Tier 1 through Tier 4 as is technically feasible and economically worthwhile. A Playwright automation suite covering the critical path and high-impact user flows takes 4 to 6 weeks to build properly on a typical SaaS product. Once it's in CI, those tests run on every pull request and every staging deploy, catching regressions in minutes rather than hours.
The scenarios worth automating are the ones that are stable (the UI doesn't change frequently), high-risk (if they break, users notice immediately), and repetitively tested (you run them every sprint). The scenarios worth keeping manual are the exploratory ones new features, edge cases you haven't thought of yet, UX judgment calls that no script can make.
The goal is a regression strategy where your automated suite handles the known risk and your manual testing time is freed up for the exploratory coverage that actually requires human judgment. That's the combination that drives a 45% reduction in escaped defects. Neither one alone gets you there.