This free regression testing checklist runs one regression cycle before a release or after a significant change. QA leads, test engineers and development teams use it to decide what to retest and to show that they did. A cycle starts with change impact analysis: list what changed, map it to the areas it touches and rate each area for risk. You then choose the regression scope, Full, Risk-based or Smoke, and only the automated run for that scope appears. The checklist confirms the release candidate, environment and test data match production, runs the automated suite, separates flaky tests from real failures, covers the areas without automation by hand, and logs and retests every defect. Exit criteria are set before testing starts. If they are not met, re-run steps appear before the QA lead records the sign-off, and the cycle ends by adding tests for the defects that got through.
Testing a release asks two different questions. Does the new work do what it should? And did the change break anything that used to work? The first is functional and confirmation testing, which the QA Testing Checklist covers from test plan to sign-off. The second is regression testing, and it is the one teams repeat for every release, usually with the least time to spare.
Because it repeats, a regression cycle needs its own short routine: decide the scope from what changed, run the same suites against a build that matches production, and keep the suite honest by quarantining flaky tests and adding a test for every defect that got through. The release decision sits with the Feature Release Process Checklist, and the deploy with the Production Deployment & Rollback Checklist.
Covers: test cases written from the specification, functional, edge case and acceptance testing of the change itself.
When: once per feature, as part of the full test lifecycle.
Output: evidence that each requirement was met.
Covers: impact analysis, scope, environment parity, automated and manual regression, defects and retest, exit criteria.
When: every release candidate, hotfix or significant change.
Output: a signed-off regression summary and a better suite for next time.
Covers: go/no-go, release notes, the deployment strategy, smoke tests in production and rollback.
When: after the QA sign-off.
Output: a release in production with a rollback plan.
Eight phases take one release candidate from change impact analysis to suite maintenance. The scope chosen in Phase 2 decides which automated run appears in Phase 4, re-run steps appear in Phase 7 when the exit criteria are not met, and the QA sign-off halts the checklist until it is recorded.
Regression scope starts from what changed, not from the size of the suite. The release, its planned date and the people who sign off are recorded on the first task.
The scope chosen on the first task decides which automated run appears in Phase 4. The product owner agrees the scope and the exit criteria on the last task.
A regression run only means something if it tests the build that will ship, in an environment and with data that behave like production.
Only the run for the scope chosen in Phase 2 appears. Every result is recorded against the build under test.
Manual regression covers what the suite cannot: areas with no automation, end-to-end journeys and real integrations. In a Smoke cycle, cover the critical journeys and mark the other tasks not applicable.
Every regression is logged against the build it was found in, fixed or deferred by a decision, and retested before it counts as closed.
Re-run steps appear when the exit criteria are not met. The QA lead records the decision on the last task, and the checklist halts there until they do.
The cycle ends by improving the suite for the next one. Every defect that got past the automated run is a test the suite is missing.
Scope is a trade between time and risk. Running everything every time is the safest option and the slowest, and on a large suite it tempts teams to skip runs altogether. Choose the scope from the impact analysis in Phase 1, write the reason down, and widen it when a change turns out to touch shared code you did not expect.
| Scope | Use it when | What runs | What you accept |
|---|---|---|---|
| Full | Major releases, framework or platform upgrades, changes to shared code or the data model, or when the impact analysis is uncertain | Every automated suite on the full support matrix, plus the full manual pack | The longest cycle; worth it when you cannot say what the change touched |
| Risk-based | Regular releases where the changes and the areas they touch are known | Suites and manual cases for the affected and high-risk areas, plus the critical paths every time | Untouched, low-risk areas are not retested this cycle |
| Smoke | Hotfixes and small, isolated changes under time pressure | The smoke suite on the critical journeys, plus targeted tests around the fix | The most risk; follow it with a wider run in the next cycle |
Flaky tests are the quickest way to lose trust in a regression suite. Google defines a flaky test result as a test that shows both a passing and a failing result with the same code. In 2016 it reported that about 1.5% of all its test runs gave a flaky result and that almost 16% of its tests showed some flakiness. At that rate, Google noted, a project with about 1,000 tests would likely see 15 flaky failures on every release run. People start to dismiss red results, and a real regression gets dismissed with them. Martin Fowler recommends moving non-deterministic tests into a quarantine, out of the main pipeline, with a limit on how many tests it holds or how long a test can stay there. Phase 4 follows that pattern: one re-run to classify each failure, then quarantine with an owner and a fix date.
The impact analysis, the risk ratings and the chosen scope sit in the first two phases, with the product owner’s agreement recorded against them. When a regression reaches production, you can see what was tested, what was left out and who agreed to it.
Exit criteria are set before testing starts. If they are not met, the fix and re-run steps appear. The QA lead’s sign-off is an approval step only they can complete, and it halts the checklist, so the follow-up tasks wait until the decision is recorded.
Start a checklist for each release candidate, or put it on a recurring schedule for a fixed release train. Due dates count back from the planned release date, and the Reports Grid shows which cycles are falling behind before release day.
Due dates count back from the planned release date entered on the first task, so moving the release moves the whole cycle. CheckFlow’s recurring checklist software can open a new cycle on the same day of every sprint.
Regression testing is one part of shipping safely. The QA Testing Checklist covers the full test lifecycle for new work, the Code Review Checklist catches problems before they merge, the Feature Release Process Checklist holds the go/no-go, and the Production Deployment & Rollback Checklist runs the deploy. Defects found during the cycle can be worked through the Bug Tracking & Resolution Checklist.
QA Testing Checklist
User Acceptance Testing (UAT) Checklist
Software Release Management Checklist
Feature Release Process Checklist
Bug Tracking & Resolution Checklist
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
One regression cycle has eight parts: change impact analysis (what changed and what it touches, rated for risk), the scope and test selection with exit criteria set in advance, an environment and test data that match production, the automated run with flaky tests separated from real failures, manual regression for areas without automation, defect logging and retest, a QA sign-off against the exit criteria, and suite maintenance afterwards. The last part is the one most often skipped: every defect that got through should become a new test.
Confirmation testing, often called retesting, is done after a defect is fixed to confirm that the failure it caused does not come back. Regression testing checks everything else. The ISTQB glossary defines it as change-related testing to detect whether defects have been introduced or uncovered in unchanged areas of the software. A cycle needs both: Phase 6 confirms each fix with the original steps, then re-runs the tests around it, because a fix in shared code can break something that was working.
Start from the change, not from the suite. List what changed since the last release, map each change to the features and modules it touches, including through shared code, and rate each area by how likely it is to break and how much harm a failure would do. Add the areas where defects reached production recently. High-risk areas and the critical user journeys go into every run; lower-risk areas are added as time allows. Write the reason for the scope down so it can be checked if something slips through.
Run a full regression when you cannot say with confidence what a change touched: major releases, framework or platform upgrades, changes to shared libraries or the data model, and the first release after a long gap. A risk-based run suits regular releases where the impact analysis is clear. Keep smoke-only runs for hotfixes and small, isolated changes under time pressure, and follow them with a wider run in the next cycle so the areas you skipped are not skipped twice.
Separate them from real failures, then quarantine them. Google defines a flaky result as a test that both passes and fails with the same code, and reported in 2016 that almost 16% of its tests showed some flakiness. Re-run a failing test once: if it passes, it is flaky; if it fails again, treat it as a real failure until it is explained. Martin Fowler recommends moving flaky tests out of the main pipeline into a quarantine with a limit on its size or on how long a test can stay, so each one gets an owner and a fix.
Mostly, because the same checks run every release and a manual pack grows with every feature. Automate stable, repeated checks of business rules, APIs and critical journeys. Keep people for what automation does poorly: areas with no automation yet, exploratory testing of the highest-risk changes, visual and usability checks, and real round trips through third-party integrations. Automation needs upkeep too. Retire tests for removed features, fix or delete quarantined tests, and add a test for every defect that got past the suite.
The QA Testing Checklist covers the full test lifecycle for new work: test planning, writing test cases from the specification, setting up environments, every test type, defect management and sign-off. This checklist is the part you repeat for every release candidate: deciding what to retest from what changed, running the regression suites against the build that will ship, and keeping the suite trustworthy. Many teams run the QA testing checklist once per feature and this one once per release.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
14-day free trial, no credit cardFull refund in your first 30 daysUS or EU hosting
