Regression testing checklist: what to retest before every release

A regression testing checklist lists what you retest before a release to prove that what worked before the change still works after it. For a small team it has two parts: a fixed core that runs every time (your critical user flows, tested end-to-end) and a part chosen from what changed: the area around each change, plus the layers it touches, such as integrations, data, permissions, browsers, emails, performance and accessibility.

So what should regression testing include? Everything a change could plausibly break, ranked by how much it would hurt if it did, not everything you have ever tested. Below: the checklist layer by layer, how to keep a regression test suite small and trusted, smoke versus regression versus exploratory testing, and a template to copy.

What regression testing is, and what it is not

The ISTQB glossary defines regression testing as a type of testing that follows a change, done “to detect whether defects have been introduced or uncovered in unchanged areas of the software.” The important words are “unchanged areas”. Testing the feature you just built is not regression testing. Checking that the feature next to it still works is.

The ISTQB Foundation Level syllabus (version 4.0.1, current as of October 2026) adds that the damage can land in the changed component, elsewhere in the same system or in connected systems, and can involve the environment as well as the code. It advises an impact analysis first, to see how far the regression testing has to reach.

The syllabus also separates it from confirmation testing, which the glossary also calls retesting: running the steps of a fixed bug again to confirm that the failure does not come back. Retesting confirms the fix, and the regression run checks that the fix broke nothing else.

The regression testing checklist, layer by layer

The first two layers apply to every release. The others apply when the release touches them, which for an active product is most weeks.

1. Critical user flows, end-to-end

These are the journeys that would cost you users or money if they broke: sign-up, login, password reset, the core action of your product, checkout and payment, upgrade and cancellation, data export. Test each one from start to finish on every platform you ship, and check the outcome, not only that a page loaded. “The order appears in the order history with the right total” is a check. “The confirmation page rendered” is not.

2. The area around each change

Read the change list for the release and, for each change, write down what shares code, data or screens with it. A change to the pricing function touches the cart, the invoice and the receipt email. This is the impact analysis the syllabus asks for: the glossary defines impact analysis as the identification of all work products affected by a change. Retest those areas, including the ones nobody edited directly.

3. Integrations and third parties

Payment provider, sign-in with Google or another identity provider, email and SMS delivery, webhooks in both directions, analytics, anything that needs an API key. Check them in the provider’s test mode or sandbox, then check what your product does when the provider is slow or returns an error: a clear message for the user, no double charge, no lost order. Upgraded SDKs and new API versions of a provider belong here too.

4. Data and migrations

Run every migration on a copy of data shaped like production, not on an empty database. Then check that old records still open, display and save, that imports and exports produce the same files as before, and that background jobs reading the changed tables still run. Know whether each migration can be reversed. If it cannot, write that down for the release decision.

5. Permissions and roles

Broken access control is the first entry, A01, of the OWASP Top 10:2025, the current edition as of October 2026, and OWASP reports that 100% of the applications tested had some form of it. For each role, check that it can do what it should and nothing more. A user who changes the ID in a URL must not see someone else’s record. A logged out visitor must not reach pages behind the login. The API must refuse a write without a valid token, even when the button is hidden in the UI. These checks are cheap to automate against the API and expensive to discover in production.

6. Browsers and devices

Playwright runs the same tests on Chromium, Firefox and WebKit, on branded Google Chrome and Microsoft Edge, and on emulated tablets and phones. Its browser documentation notes that testing policies often require regression testing against the current public browsers, which the stable chrome and msedge channels cover. It does not drive branded Safari: it tests a recent WebKit build, and recommends WebKit on a Mac for behavior closest to Safari. Device emulation sets the user agent, viewport and touch support; it is not a real phone. Use your analytics to decide which browsers get the full suite and which get only the critical flows.

7. Emails and notifications

Sign-up confirmation, password reset, invitations, receipts, alerts, push notifications and notifications inside the app. Check that each one is sent once, to the right person, with every variable filled in, and that each link in it opens the right page on the right environment. A password reset link that points to staging is a classic regression.

8. Performance smells

A regression check is not a load test: the question is whether this release made the product slower than the last one. Compare the load time of the key pages, the response time of the slowest endpoints and the number of requests each page makes. For a reference point, Google’s Web Vitals guidance (last updated October 31, 2024) calls a page good when its Largest Contentful Paint happens within 2.5 seconds, its Interaction to Next Paint is 200 milliseconds or less and its Cumulative Layout Shift is 0.1 or less, for at least 75 percent of page loads.

9. Accessibility basics

Run the W3C Easy Checks on the screens you changed: page title, image alternative text, headings, color contrast, visible keyboard focus, form labels and zoom. Then go through the changed flow with the keyboard only. In Playwright, the @axe-core/playwright package can scan a page inside a test, but the Playwright accessibility guide is clear that automated tests detect only some common problems and that many can only be found by manual testing.

Smoke test vs regression test vs exploratory testing

• Smoke testing is, in the ISTQB glossary, “a test type to gain sufficient confidence that a test object is ready for planned testing.” In practice, a handful of fast checks right after a deploy: the app loads, a user can log in, the main page shows data. If the smoke test fails, there is no point running anything else.
• Regression testing checks that a change did not break what already worked. It is the bulk of the checklist above, and most of it should be automated.
• Exploratory testing is “a test approach in which tests are dynamically designed and executed based on tester’s knowledge, exploration of a test item, and previous test results.” A person uses the new feature the way users will, with a written goal (a test charter) and a time box. The syllabus calls it useful when specifications are thin or time is short.

Type	Question it answers	When it runs
Smoke	Is this build alive enough to test?	After every deploy, in minutes
Regression	Did the change break what worked?	Every pull request and the release build
Exploratory	What did nobody think to test?	New and risky features, before release
Confirmation	Is this bug really fixed?	After each fix

A smoke test is not a smaller regression suite for days when time is short. If only the smoke test ran before a release, record that as a risk in the release decision.

How to keep a regression test suite small and trusted

A regression suite helps only if it runs on every change and a red result stops a merge. The syllabus notes that regression suites are run many times and generally grow with each release, which makes regression testing a strong candidate for automation.

Select tests by risk, not by habit

Every test in the suite should protect a user flow or a rule that matters, and you should be able to say which one. Score your flows for likelihood and impact (our risk-based testing guide has a simple matrix), test the high scores deeply, and delete tests that check the same thing twice. Tags make the tiers runnable: Playwright lets you tag a test, for example @smoke, and run only that tier with --grep.

# Smoke tier, after each deploy
npx playwright test --grep @smoke

# Full regression on a pull request, failing the run if any test was flaky
npx playwright test --fail-on-flaky-tests

# Fast first pass: test files changed since main, plus test files importing them
npx playwright test --only-changed=main

The last command (Playwright 1.46 and later) picks tests by which files changed in git. A product change that no test file imports selects nothing, so it is a fast first pass, never the regression run.

Run it automatically on every pull request

Where continuous integration is used, the syllabus calls it good practice to include automated regression tests. Run it on every pull request, not only before a release, so a regression is caught while the change is still small. Our guide to running Playwright in GitHub Actions has a workflow to start from. Then make the job a required status check: on GitHub, a protected branch accepts a merge only after all required status checks pass.

Fix flaky tests, do not mute them

A test that passes and fails on the same code teaches the team to ignore red, and a muted test is a hole in the net that nobody sees. Trace each flaky test to its cause and fix it, or quarantine it where everyone can see it, with an owner and a date. Our guide to flaky tests in Playwright covers both. The --fail-on-flaky-tests option fails the run when any test is flagged as flaky, so a retry cannot hide the problem. Have a person label every failure as a product bug, a test problem or an environment problem before anyone reruns the job.

A regression testing checklist you can copy

Paste this into the release ticket or the release pull request, fill it in before the release review, and bring the results to your Go/No-Go release checklist, where the decision is made. The manual checks (emails in real mail clients, a real phone, the look of a new screen) go in it too, each with an owner.

## Regression: <release name or version>, build <id>

### Every release

- [ ] Smoke tests passed on the deployed build: <link>
- [ ] Full automated regression suite ran on this build: <link>
- [ ] Every failure triaged: <n> product bugs, <n> test problems, <n> environment
- [ ] Tests muted or skipped since the last release: <none | list, owner, date>
- [ ] Critical flows passed end-to-end on: <web | iOS | Android | API>

### Around each change

- [ ] Change list read, impact written down for each change: <link>
- [ ] Shared components and functions changed in this release retested: <list>
- [ ] Fixed bugs retested, and the area around each fix: <list>

### When the release touches them

- [ ] Integrations in test mode: payments, sign-in, email, webhooks: <result>
- [ ] Provider slow or down: clear error, no double charge, no lost data: <result>
- [ ] Migrations run on production-shaped data, reversible: <yes | no, accepted by>
- [ ] Old records open, display and save; imports and exports unchanged
- [ ] Each role can do what it should and nothing more, in the UI and the API
- [ ] Browsers: full suite on <main browser>, critical flows on <others>
- [ ] Emails and notifications: sent once, right content, links to the right env
- [ ] Performance: key pages and endpoints no slower than the last release
- [ ] Accessibility on changed screens: keyboard only, focus, labels, contrast

### Manual and exploratory

- [ ] Exploratory session on new features: <charter, who, time box, findings>
- [ ] Manual checks: <real devices, mail clients, visual review>, owner: <name>

### Not tested, and why

- <list, for the Go/No-Go review>

How we do it

In our service, the regression suite is plain Playwright code in your repository, chosen from a risk-based test plan we agree with you, and it runs in your CI on every pull request. Claude agents write the tests and update them when the product changes. A QA engineer reviews every change before it is merged and looks at every failure before it becomes a bug report or a test fix, and new features get exploratory testing by a person. Before each release the results go into a signed Go/No-Go report, and shipping stays your decision. The how it works page has the details.

Sources

• Regression testing, confirmation testing, impact analysis, smoke testing and exploratory testing, ISTQB Glossary
• Certified Tester Foundation Level syllabus, version 4.0.1, ISTQB
• A01:2025 Broken Access Control, OWASP Top 10:2025
• Browsers, Emulation, Accessibility testing, Annotations, Command line and Release notes, Playwright documentation
• Web Vitals, web.dev
• Easy Checks: a first review of web accessibility, W3C Web Accessibility Initiative
• About protected branches, GitHub Docs

Researched and drafted with Claude, Anthropic's AI model, and checked against the sources it links. Spotted an error? Tell us and we will correct it.