--- title: "QA Release Checklist: 12 Steps Before Every Release" description: "A 12-step QA release checklist with an owner and a piece of evidence for each step, and a clear answer to who owns the checklist: engineering or QA." canonical: "https://momentic.ai/blog/qa-release-checklist" last-updated: "2026-09-25T01:27:41Z" --- # QA Release Checklist: 12 Steps Before Every Release URL: https://momentic.ai/blog/qa-release-checklist [blog](/blog) [/ resources](/blog/category/resources) / qa-release-checklist Resources A 12-step QA release checklist with an owner and a piece of evidence for each step, and a clear answer to who owns the checklist: engineering or QA. Wei-Wei Wu CEO, Momentic ## TL;DR - Engineering owns the release checklist as a delivery process. QA owns the measurable exit criteria that determine whether the build can ship. - **Freeze and build gate.** Freeze scope, then confirm the release build and version. - **Test gate.** Run CI regression and release-candidate smoke tests. Verify critical user paths, supported browsers and devices, accessibility, performance, error baselines, data migrations, and rollback readiness. - **Sign-off and monitor gate.** Check release notes and feature flags, record engineering and product approval, then monitor the production deploy. - Close every step with named ownership and binary evidence, such as a green CI run, a matching build hash, or telemetry inside an approved threshold. ## Why release checklists fail without clear ownership and evidence A QA release checklist becomes a box-ticking exercise when nobody controls each gate and no evidence defines completion. “Regression testing complete” leaves room for judgment. “CI run 1842 passed the agreed suite with zero unresolved blockers” gives the owner a binary result that another person can verify. Entry and exit criteria serve different purposes. [Entry criteria](https://www.enov8.com/blog/release-entry-exit-criteria-explained/) determine whether a build can enter release validation. Exit criteria determine whether the candidate has met the agreed conditions for deployment. A frozen scope and identified build can serve as entry criteria. Passing test reports, approved waivers, and rollback evidence can serve as exit criteria. A valid criterion must produce a measurable pass or fail result tied to a requirement or known risk. One named person must own the decision. [Release criteria assigned to a committee](https://rexblack.com/resources/writing/exit-and-release-criteria) often lack an accountable approver. For example, an engineering lead can approve a documented waiver for a blocker, while the checklist records the mitigation and supporting test result. Apply two questions to every step that follows. Who owns the gate, and what artifact proves it passed? CI results, build hashes, test reports, monitoring baselines, and logged approvals create an auditable release record. A checked box without comparable evidence does not establish release readiness. ## The 12-step QA release checklist Follow these steps in order. Each detailed step names an owner and the evidence required to close it. 1. Freeze the scope. 2. Confirm the build and version. 3. Run the regression suite in CI. 4. Run smoke tests on the release candidate. 5. Check critical user paths end to end. 6. Test the supported browsers and devices. 7. Check accessibility and performance basics. 8. Review error logs and monitoring baselines. 9. Verify data migrations and rollback readiness. 10. Check release notes and feature flags. 11. Get sign-off from engineering and product. 12. Monitor the application after deployment. ### 1. Freeze the scope Release testing needs a fixed target. If commits or tickets enter the release after testing starts, existing results describe an earlier candidate. QA must rerun every check affected by the added change. The engineering lead owns the scope freeze and approves exceptions. An emergency addition should create a new scope lock, identify affected tests, and trigger those tests again. Product or QA may request an exception, but neither should add work without engineering approval. A written, timestamped scope lock closes this step. Use a frozen ticket list, a tagged commit range, or both. The evidence should name the release and its owner. These details make the gate [measurable, traceable, and owned](https://rexblack.com/resources/writing/exit-and-release-criteria). An issue tracker and Git provide the required record. ### 2. Confirm the build and version Engineering should close this gate only when the release candidate has an immutable identifier. For a web app, use a commit SHA, container digest, or version tag. For a mobile app, record the version and build number. Match that identifier across the CI artifact, deployment record, and runtime version endpoint. Artifact confusion produces “it worked in staging” incidents when QA tests one build but engineering deploys another. The same check must confirm that the previous artifact remains available for rollback. Deployment guidance recommends verifying the [rollback artifact before production](https://octopus.com/devops/software-deployments/deployment-checklist/). Evidence consists of the deployed build hash or version tag, the matching QA record, and the verified rollback artifact. ### 3. Run the regression suite in CI Engineering should make the regression suite a required CI gate rather than a manual release task. Run fast unit tests on every commit. Pull requests can add integration tests and targeted regression coverage, while the release candidate should run the full required regression suite. [CircleCI recommends this staged sequence](https://circleci.com/blog/regression-testing-and-how-to-automate-it-with-ci/) because fast checks reject obvious defects before slower tests consume CI capacity. Engineering owns the pipeline configuration and failure reporting. QA owns coverage decisions. QA should map tests to supported behavior, critical user paths, and previous production regressions. Failed gating tests should block the release unless a named owner documents and approves an exception. Flaky tests need quarantine and repair rather than repeated reruns until CI turns green. A green CI run closes this checklist step only when the configured pass threshold is met and no required test remains unresolved. Store the commit SHA, build identifier, test report, and approved exceptions with the release record. [Momentic](https://momentic.ai) can cover browser-based regression checks through end-to-end tests written as plain-English steps in YAML. Engineers run those tests through the CLI in CI alongside unit and integration suites. ### 4. Run smoke tests on the release candidate QA should keep the smoke suite broad, shallow, and focused on whether the release candidate deserves further testing. Keep smoke coverage focused on failures that would make the product unusable or reveal a build or deployment fault. Put deeper scenarios and narrower edge cases in the regression suite. Run smoke tests after CI deploys the actual release candidate to staging. Local development cannot expose staging-specific problems such as missing environment variables, incorrect configuration, or failed migrations. QA owns this gate, and a passing CI run provides the evidence. Keep the smoke suite small and fast so it runs on every release candidate in a few minutes. The recorded run should identify the release candidate build and show that every check passed within the agreed time budget. ### 5. Check the critical user paths end to end Critical user paths require scenario-level checks because smoke tests only confirm that the release candidate supports basic interaction. QA should exercise complete journeys whose failure would block revenue or generate support tickets. For example, checkout coverage should verify a successful purchase and a declined payment with retry behavior. QA owns this step, and a path matrix provides the closing evidence. Each scenario should identify its starting state, expected outcome, and binary pass or fail result against the release candidate. Existing end-to-end suites can cover known paths. [Momentic](https://momentic.ai) also provides Mo, an autonomous QA agent that explores a build and reports bugs without a pre-written test suite. Mo can find unexpected behavior outside defined scenarios, but exploratory bug discovery does not replace regression coverage for known critical paths. ### 6. Test on the real browsers and devices you support Define the browser and device matrix from your support policy, then use production analytics to prioritize the supported combinations your customers use most. Include older supported versions even when usage is low. QA owns this gate and should run the release candidate on each supported combination. Use physical devices for hardware-dependent behavior such as cameras, biometrics, and mobile keyboards. Cloud device labs can cover broader browser and OS combinations. Close the step only when a documented matrix records a pass for every required combination or links an approved exception to a known defect. ### 7. Check accessibility and performance basics Engineering should gate each release on repeatable accessibility and performance checks. Use axe or a similar scanner to detect common accessibility problems, and add keyboard tests for critical interactions. Lighthouse can measure lab performance in a consistent test environment, but it does not replace production Core Web Vitals data or load testing. Set pass thresholds before release testing begins. Run lab performance checks in a consistent environment so results remain comparable between builds. The release closes this step when CI produces an accessibility and performance report that meets every threshold. Failed checks should block the build under the principle that [automatable release criteria belong in CI](https://rexblack.com/resources/writing/exit-and-release-criteria). These checks do not replace a full accessibility audit or production performance monitoring. Automated scanners cannot assess every interaction or determine whether an experience makes sense with assistive technology. They provide a consistent minimum gate that catches common regressions before deployment. ### 8. Review error logs and monitoring baselines Engineering should establish production health before approving a release. Functional tests exercise known paths, but logs can expose recurring failures in scheduled jobs or third-party callbacks. Review application logs and error-tracking dashboards for unexplained exceptions before the release candidate ships. Engineering owns this step and should record error rate and latency over a defined, representative window. [Post-deploy monitoring should compare those metrics against the pre-deploy baseline](https://octopus.com/devops/software-deployments/deployment-checklist/), which helps separate existing noise from release-related regressions. An APM or error-tracking tool covers the review. A timestamped dashboard snapshot with documented thresholds closes the step. ### 9. Verify data migrations and rollback readiness Engineering owns the migration and rollback gate. Before deployment, engineering should create a timestamped backup, verify that it can be restored, snapshot the database state, run the migration against staging data, validate data integrity, and execute the rollback script. [Testing rollback procedures in staging](https://octopus.com/devops/software-deployments/deployment-checklist/) exposes broken scripts, long-running locks, and application compatibility problems before production data is involved. A written runbook cannot prove that the recovery path works. Engineering should keep the previous application artifact available and test the order of recovery operations. For a destructive migration, the runbook may specify a forward fix or verified backup restoration instead of a schema rollback. The gate closes when the release record identifies the migration owner, shows a successful staging rehearsal, and documents a tested recovery method with an approved migration window. If the migration exceeds that window or fails an integrity check, the CI/CD pipeline should pause the rollout and invoke the documented response rather than automatically terminating a database operation. ### 10. Check release notes and feature flags Release notes should match the frozen scope and describe what users will encounter. Flag configuration should record which features are enabled, which audience receives them, and the planned rollout percentage. A progressive rollout limits initial exposure while engineering watches error rates and performance. If a flagged feature causes problems, a kill switch in the feature flag can disable it without a new deploy. Product owns the release notes, and engineering owns the production flag configuration. Product confirms the release notes and target audience, while engineering verifies each production flag state. Close the step when the notes match the shipped scope and the flag dashboard shows the approved rollout percentage. ### 11. Get sign-off from engineering and product Sign-off should record two named decisions against pre-agreed exit criteria. The engineering lead confirms technical readiness, including CI results, migration safety, rollback readiness, and monitoring. The product owner confirms that the release matches the approved scope and that any known product risks are acceptable. Each criterion should produce a binary result and trace back to a requirement or documented risk. [Release criteria also need a named owner](https://rexblack.com/resources/writing/exit-and-release-criteria), since a group approval can leave the final decision unclear. A passive Slack thread or meeting attendance does not close this step. Record both approvals in the release ticket or deployment record. Link each approval to the evidence reviewed, and document any exception as a written waiver with a named approver and mitigation. The step closes when the engineering lead and product owner have separately approved their assigned criteria. ### 12. Monitor after the deploy Engineering on-call owns the release until production behavior remains stable for a defined observation window. Immediately after deployment, the on-call engineer should run smoke tests and health checks against production. A failed critical flow or health check should stop the rollout or trigger the documented rollback path. Ongoing monitoring compares production behavior with the baseline captured before release. Track error rate and latency, along with relevant infrastructure and business metrics. Define thresholds and the observation window before deployment so responders do not reinterpret noisy results under pressure. Every minute of downtime costs revenue and trust, so define the rollback criteria before the deploy and validate fast. Close the release only after the post-deploy smoke suite passes and error rate and latency stay inside their agreed baselines for the full window. Save test results and monitoring dashboards as evidence. ## Who should own the release checklist: engineering or QA Engineering should own the release checklist as a process artifact. Engineering controls the delivery systems and production deployment. The engineering owner keeps the checklist current, assigns each step, and attaches its evidence to the release record. QA should own the exit criteria that define the quality bar. [Entry criteria determine whether release work can begin, while exit criteria determine whether the release can be considered complete](https://www.enov8.com/blog/release-entry-exit-criteria-explained/). Before release work starts, QA defines the required coverage and pass thresholds, including which unresolved defects require a waiver. Each criterion should be measurable, binary, traceable to a requirement or risk, and assigned to [one named owner](https://rexblack.com/resources/writing/exit-and-release-criteria). Reversing the split separates the checklist from the people operating the release. QA may then carry responsibility for deploy mechanics that engineering controls. Giving engineering sole control over exit criteria creates a different conflict because the group shipping the change can lower its own quality bar under schedule pressure. Shared committee ownership also weakens accountability. A release thread full of approvals does not identify who accepted a failed criterion or waived a defect. Name one engineering owner for the checklist and one QA owner for each quality gate. Record any waiver with its approver, affected risk, and mitigation. ## Checklist steps, owners, and evidence at a glance Each gate closes only when its named owner provides binary evidence. | Step | Owner | Evidence that closes it | Tool/mechanism | | --- | --- | --- | --- | | Freeze scope | Engineering | Timestamped scope lock | Tickets | | Confirm build | Engineering | Matching hash and tag | CI artifact | | Run regression | Engineering | Required CI suites pass | CI test runners; Momentic CLI for browser E2E tests | | Run smoke tests | QA | Release candidate passes | Smoke suite | | Check critical paths | QA | Every defined scenario passes | E2E tests; Mo for supplemental exploration | | Test supported devices | QA | Matrix passes | Device lab | | Check accessibility and performance | Engineering | Thresholds pass | Automated scans | | Review logs | Engineering | Baseline recorded | Monitoring | | Verify migration and recovery | Engineering | Migration and recovery method tested | Staging drill | | Check notes and flags | Product and engineering | Scope and flag states match | Flag manager | | Get sign-off | Engineering and product | Named approvals logged | Release record | | Monitor deploy | Engineering on-call | Smoke pass and metrics within baseline | Alerts | ## FAQ **What is the difference between entry and exit criteria?** [Entry criteria](https://www.enov8.com/blog/release-entry-exit-criteria-explained/) define what must be true before release work begins. Exit criteria define the evidence required before you declare the release complete. **How large should a smoke suite be?** Keep the suite broad, shallow and fast, so it runs on every release candidate in a few minutes. Move deeper scenarios into the regression suite. **What should you do when a checklist step fails right before release?** Stop the release and fix the failure. A named approver may accept a documented waiver after the responsible owner tests a mitigation and records the remaining risk. Quietly skipping the step invalidates the gate. **Can automation replace a release checklist entirely?** Automation can run tests, enforce thresholds, and collect evidence. Humans still need to define risks, approve exceptions, and assess exploratory findings or subjective usability problems that [resist full automation](https://circleci.com/blog/regression-testing-and-how-to-automate-it-with-ci/). ## Conclusion Use the checklist as part of the release record rather than as a separate document. Engineering should maintain the process, while QA defines the exit criteria and verifies that each quality gate has evidence. If releases repeatedly stall or require last-minute waivers, review the ownership and criteria before adding more steps. ## QA release checklist Who should own the release checklist, engineering or QA? Engineering owns the checklist as a delivery process and runs the release. QA owns the exit criteria and the evidence that closes each test step. One named owner per step, not a shared committee. What is the difference between entry and exit criteria? Entry criteria define what must be true before release work begins. Exit criteria define the evidence you need before you declare the release complete. How large should a smoke suite be? Keep the suite broad, shallow and fast, so it runs on every release candidate in a few minutes. Move deeper scenarios into the regression suite. What should you do when a checklist step fails right before release? Stop the release and fix the failure. A named approver may accept a documented waiver after the owner tests a mitigation and records the remaining risk. Never skip the step quietly. Can automation replace a release checklist entirely? Automation can run tests, enforce thresholds and collect evidence. People still define the risks, approve exceptions and judge exploratory findings and usability problems. Still have additional questions? ## Keep reading. [Resources Best Visual Regression Testing Tools: 10 Compared for 2026 Ten visual regression testing tools compared for 2026: Applitools, Percy, Chromatic, BackstopJS, Argos, Storybook test runner, Playwright toHaveScreenshot, Lost Pixel, Meticulous and Momentic, with pricing model, CI integration and diffing method for each. Wei-Wei Wu 12 min read](/blog/best-visual-regression-testing-tools)[Resources Best Puppeteer Alternatives for Browser Automation Compare the best Puppeteer alternatives for browser automation, E2E testing, and web scraping. Explore Playwright, Selenium, Cypress, Momentic, and more. Wei-Wei Wu 8 min read](/blog/puppeteer-alternatives)[Resources Best Qodex Alternatives for UI Testing Compare the best Qodex alternatives for UI testing, including Momentic, QA Wolf, mabl, Testim, and more. Explore AI-powered testing, self-healing locators, and web and mobile support. Wei-Wei Wu 8 min read](/blog/qodex-alternatives) ## Close the feedback loop. Point Momentic at your app. Free to start, no credit card. [Try for free](https://app.momentic.ai/signup) [Contact sales](/sales)