QA Regression Testing Checklist

A regression testing checklist to run before each release: test scope, environment, critical flows, cross-browser checks, bug triage and a clear QA sign-off.

Typical schedule per release candidate
The checklist 5 sections, 19 items
Variables {{product}} {{version}}
Start from CI

Use this template Free, no credit card. Imports the checklist into your Runbook organization.

Use this checklist when a release candidate is ready in a test or staging environment and needs a manual regression pass before it ships. It checks that existing features still work after the changes in this release. It is not a replacement for automated tests. It covers what automation in most small teams does not: real browsers and devices, visual problems, emails and the judgement of a person who knows the product.

Who owns it

A QA engineer owns the run. In teams without dedicated QA, it rotates between developers, but the person testing should not be the main author of the changes. The release manager uses the sign-off at the end of the run for the go or no-go decision.

Common pitfalls

Testing everything equally. A full manual pass of every feature takes too long and gets rushed. Always test the critical flows, then focus on areas touched by this release.
A test environment that does not match production. Different config, empty data or disabled integrations hide bugs. Check the environment before you start.
Only one browser and one account type. Many bugs only appear for admins, new users or on a mobile screen. Test with different roles and screen sizes.
Bugs reported without a decision. Every bug found needs a call: blocks the release, or deferred with a ticket. Leaving that to release day causes delays.
The same manual steps every release. If a check is repeated every time, automate it and remove it from the manual list.

The checklist: Regression test {{product}} {{version}}

Scope and setup

Changes in {{version}} are listed and the areas they touch are identified
Test environment runs exactly {{version}} with production-like configuration
Test data and accounts for each user role are ready
Automated test suite passed on {{version}} and its report is linked

Critical flows

Sign-up, login, logout and password reset work
The core workflow of {{product}} works from start to finish
Write down the exact steps once, in the template, so every tester checks the same thing.
Payments, subscriptions or invoices work with test data optional
Permissions are respected: a normal user cannot see or change admin data
Emails and notifications are sent and their links work

Changed areas

Each new or changed feature in {{version}} is tested against its acceptance criteria
Features next to the changed code are tested for side effects
Bugs fixed in {{version}} are retested and confirmed as fixed

Compatibility

Main flows work in the latest versions of the major browsers you support
Layout works on a phone-sized screen
Basic accessibility checks pass: keyboard navigation, focus and labels optional
Import, export or API endpoints used by customers still work optional

Triage and sign-off

Every bug found is logged with steps to reproduce and a severity
Each bug is marked as release-blocking or deferred with a ticket
QA sign-off for {{version}} is recorded, with open risks listed

Checklist as Markdown

# Regression test {{product}} {{version}}

## Scope and setup
- [ ] Changes in {{version}} are listed and the areas they touch are identified
- [ ] Test environment runs exactly {{version}} with production-like configuration
- [ ] Test data and accounts for each user role are ready
- [ ] Automated test suite passed on {{version}} and its report is linked

## Critical flows
- [ ] Sign-up, login, logout and password reset work
- [ ] The core workflow of {{product}} works from start to finish
  Write down the exact steps once, in the template, so every tester checks the same thing.
- [ ] Payments, subscriptions or invoices work with test data (optional)
- [ ] Permissions are respected: a normal user cannot see or change admin data
- [ ] Emails and notifications are sent and their links work

## Changed areas
- [ ] Each new or changed feature in {{version}} is tested against its acceptance criteria
- [ ] Features next to the changed code are tested for side effects
- [ ] Bugs fixed in {{version}} are retested and confirmed as fixed

## Compatibility
- [ ] Main flows work in the latest versions of the major browsers you support
- [ ] Layout works on a phone-sized screen
- [ ] Basic accessibility checks pass: keyboard navigation, focus and labels (optional)
- [ ] Import, export or API endpoints used by customers still work (optional)

## Triage and sign-off
- [ ] Every bug found is logged with steps to reproduce and a severity
- [ ] Each bug is marked as release-blocking or deferred with a ticket
- [ ] QA sign-off for {{version}} is recorded, with open risks listed

Start this checklist from your pipeline

When a release candidate is deployed to staging, POST /api/v1/runs with template "Regression test {{product}} {{version}}" and assign it to QA.

curl -X POST https://runbook.metastic.ch/api/v1/runs \
  -H "Authorization: Bearer $RUNBOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template": "Regression test {{product}} {{version}}", "variables": {"product": "…", "version": "…"}}'

See the API and the GitHub Action

Frequently asked questions

What is included in regression testing?

Regression testing checks that features that worked before still work after a change. A good pass covers the critical user flows every time, plus the areas around the changes in the current release. It combines automated tests with a focused manual pass.

How do I decide what to regression test manually?

Test the flows that would hurt most if they broke, such as login, the core workflow and payments. Then add the areas touched by this release and their neighbours. Anything you test the same way every release is a good candidate for automation.

Who should sign off on regression testing?

The person who ran the tests signs off on what was tested and what was found. The release manager then decides whether to ship, based on that sign-off and the open bugs. Keeping the two roles separate makes it clear that QA reports risk and the release owner accepts it.

Updated 2026-11-04