>_ Release QA Checklist

Short answer

A release QA checklist is a list of checks that a team goes through before shipping a new version of a product. It helps make sure that core user flows work, critical bugs are fixed, the UI is stable, data is saved correctly, and the release is safe to deliver to users.

This checklist is especially useful before releasing a web product, SaaS platform, e-commerce website, internal tool, or any feature where a defect can affect users, payments, data, reports, or business processes.

A release checklist does not replace full testing. It helps the team quickly review the highest-risk areas before release and avoid missing basic but important checks.

Quick release QA checklist

Use this quick checklist when you need a short pre-release review:

• review the release scope;
• check the main user flow;
• verify login, logout, and access permissions;
• test forms and validation;
• check UI, layout, and mobile behavior;
• verify data, statuses, exports, and reports;
• test integrations and notifications;
• verify fixed bugs with a focused sanity test;
• run a regression smoke check;
• complete a short post-release check.

Track this checklist in qa::checklist

You can use this guide as a manual release checklist, or track it in qa::checklist as a QA project. Split checks by module, mark each item as pass, fail, or pending, add comments, and export the final result to CSV.

When to use a Release QA Checklist

Use this checklist before every release if the product has changes that may affect users or business logic.

For example:

• a new feature was added;
• an existing user flow was changed;
• bugs were fixed;
• form logic, payments, orders, registration, or authentication were updated;
• roles, permissions, or statuses were changed;
• the frontend was updated;
• integrations or transactional emails were changed;
• the release affects the mobile version;
• there is a risk that fixing one area may have broken a related flow.

For small changes, you can use a shorter version of the checklist. For larger releases, it can be used as a base for full release testing or user acceptance testing when business sign-off is needed.

Full Release QA Checklist

1. Checks before testing starts

Before starting the final release check, make sure you understand what has changed.

Check that:

• there is a task description or release notes;
• it is clear which features are included in the release;
• it is clear which bugs were fixed;
• the potentially affected product areas are known;
• there is a staging or test environment;
• the latest changes have been deployed;
• there are no unfinished tasks that should not be included in the release;
• you have access to the required roles and test accounts;
• test data is prepared.

If the change description is incomplete, it is better to clarify the details before starting final QA. Otherwise, there is a risk of checking only the obvious part of the task and missing a related scenario.

2. Core functionality check

Start with the main user flow. This is the scenario that the product or feature exists to support.

For example:

• the user signs up;
• logs in;
• creates an object;
• edits data;
• submits a form;
• places an order;
• completes a payment;
• receives confirmation;
• sees the result in their account;
• exports a report;
• receives an email or notification.

Check that:

• the main flow works from beginning to end;
• the user sees the expected result;
• data is saved correctly;
• data does not disappear after page refresh;
• statuses change correctly;
• buttons, links, and forms work;
• there are no blocking errors;
• there are no unexpected redirects;
• the user does not end up in an empty or broken state.

The main question for this part is: can the user complete the key action without help from the team?

3. Authentication and access check

Authentication checks may look basic, but this is where critical defects are often missed: a user may see someone else's data, access a page they should not access, or be blocked from an area they should be able to use.

Check that:

• the user can log in;
• the user can log out;
• the session does not break after page refresh;
• unauthenticated users cannot access private pages;
• a user with one role cannot access functionality intended for another role;
• direct URLs do not open pages without the required permissions;
• after logout, private pages are no longer available;
• expired sessions are handled clearly;
• the user sees correct error messages after entering an invalid login or password.

If the product has different roles, test the release under every important role. For example: admin, manager, regular user, guest.

4. Forms and validation check

Forms often do not break completely. Instead, they break partially: a field accepts an invalid value, an error appears in the wrong place, data is saved in the wrong format, or frontend and backend validation behave differently.

Check that:

• required fields are actually required;
• optional fields can be left empty;
• minimum and maximum values work correctly;
• text length limits are enforced;
• email, phone, URL, and other formats are validated correctly;
• errors are shown next to the correct fields;
• error messages are clear to the user;
• the form cannot be submitted with invalid data;
• the form can be submitted successfully with valid data;
• entered data is not lost after an error;
• after successful submission, the user sees a clear result.

Also check boundary values: minimum value, maximum value, empty field, too-long text, special characters, and spaces at the beginning or end of a string.

5. UI and layout check

Before release, make sure that the interface not only works but also looks stable enough for users.

Check that:

• main pages are not visually broken;
• buttons, fields, and blocks do not overlap;
• text is not cut off;
• long names and values are displayed properly;
• empty states are clear;
• loading states are shown correctly;
• error states do not look like broken pages;
• modals open and close correctly;
• dropdowns, tabs, filters, and pagination work;
• there are no obvious spacing, font, or responsiveness issues.

Pay special attention to pages that users will see immediately after release: dashboard, checkout, onboarding, profile, settings, reports, and product pages.

6. Mobile version check

Even if the product is mostly desktop-first, the mobile version should not be ignored completely. A user may open a link from their phone, check a status, make a payment, fill out a form, or show a page to someone else.

Check that:

• main pages open on a mobile screen;
• content does not go outside the screen;
• buttons are easy to tap;
• forms are usable;
• the menu opens and closes;
• sticky elements do not cover important content;
• tables, cards, or lists are readable;
• modals fit on the screen;
• horizontal scrolling appears only where it is actually needed;
• the key user flow can be completed on a phone.

For a final smoke test, it is usually enough to check several key screens in a mobile viewport. For a mobile-heavy product, deeper testing is required.

7. Data check

Many release bugs are not about a broken button. They are about data being saved, displayed, or updated incorrectly.

Check that:

• created data appears in the right place;
• edited data updates correctly;
• deleted data is no longer displayed;
• data is not duplicated;
• amounts, statuses, dates, and counters are calculated correctly;
• filters show the correct results;
• sorting works as expected;
• search finds the right objects;
• exports contain up-to-date data;
• imports, if available, handle valid and invalid files;
• reports match the data shown in the interface.

If the product works with money, orders, metrics, invoices, or analytics, this part should not be checked "by eye." It is better to compare the result with expected values.

8. Integration check

If the release affects external services, payment systems, email, CRM, analytics, APIs, or webhooks, check not only the interface but also whether data is actually transferred.

Check that:

• data is sent to the external service;
• the external service returns the expected response;
• integration errors are handled clearly;
• the user does not see a technical error without explanation;
• retry logic works, if it is expected;
• webhooks are sent;
• emails or notifications are delivered;
• tracking events are sent to analytics;
• payments, if available, end with the correct status;
• failed payments or declined statuses are handled correctly.

For integrations, it is especially important to test both successful and failed scenarios. Testing only the happy path is often not enough.

9. Error handling and edge cases

Before release, make sure the product does not fall apart when the user or an external system behaves in a non-ideal way.

Check that:

• the user sees a clear error message after entering invalid data;
• the user cannot accidentally submit a form twice with a double click;
• slow internet does not break the flow;
• refreshing the page does not create duplicates;
• empty lists are displayed correctly;
• there is no endless loader;
• 404 and 500 pages look acceptable;
• the user can recover after an error;
• the system does not save partially incorrect data;
• backend validation does not conflict with frontend validation.

Edge cases do not always need to be checked fully before every release, but they are required for critical areas.

10. Fixed bugs check

If the release includes bug fixes, each fixed bug should be verified separately.

Check that:

• the original bug no longer reproduces;
• the fix works in the exact scenario where the issue happened;
• similar scenarios are not broken;
• the fix did not create a new defect nearby;
• the bug status is closed only after actual verification.

A good practice is to check not only that "the bug disappeared," but also that "the scenario now works as expected for the user."

11. Regression smoke check

After checking the new changes, run a short regression smoke check across the main product areas.

Check:

• login / logout;
• homepage or dashboard;
• main user flow;
• creating and editing a key object;
• deleting or canceling an action, if applicable;
• search, filters, or navigation;
• email / notifications, if they are critical;
• payment or checkout, if the product involves money;
• main roles and access permissions;
• mobile view for key screens.

The goal of smoke regression is not to retest the whole product. The goal is to quickly confirm that the release did not break the most important areas.

12. Final pre-release check

Before the release goes to production, check the organizational and technical details.

Check that:

• all critical bugs are fixed or explicitly accepted as known issues;
• there are no blocker or critical defects;
• the team understands what exactly is being released;
• release notes or a changelog are ready, if needed;
• migrations, if any, are ready and tested;
• feature flags are configured correctly;
• the rollback plan is clear to the team;
• monitoring or logs are available;
• responsible people know about the release;
• final QA approval is given explicitly.

The final check is not about bureaucracy. It helps the team avoid shipping changes based only on assumptions.

13. Post-release check

After deployment to production, run a short check in the real environment.

Check that:

• production opens;
• the user can log in;
• the key flow works;
• new changes are available;
• there are no obvious console errors;
• there is no sudden increase in errors in logs or monitoring;
• integrations work;
• emails / notifications are sent;
• payments or orders, if available, work correctly;
• users are not reporting widespread issues.

A post-release check should usually be short. Its purpose is to quickly catch issues that may appear only after production deployment.

Common mistakes

1. Checking only the new feature

The new feature may work, but an existing flow may be broken. Before release, it is important to check not only what was added, but also what the change may have affected.

2. Not checking roles and permissions

If the product has different roles, the same scenario may work differently for different users. Testing only with an admin account often misses real user problems.

3. Testing only the happy path

The happy path shows that the flow works under ideal conditions. But users enter invalid data, refresh pages, click twice, lose internet connection, and open products from mobile devices.

4. Not verifying data

If the interface shows an amount, status, report, or export, it should be compared with the expected result. "Looks about right" is a poor criterion for release testing.

5. Forgetting the production check

Staging can differ from production. Even if everything worked before release, it is still worth running a short check in the real environment after deployment.

6. Making the checklist too large

If a release checklist turns into a huge test plan, the team stops using it. It is better to have a short required checklist and additional sections for more complex releases.

FAQ

What is a Release QA Checklist?

A Release QA Checklist is a list of final checks before shipping a new version of a product. It helps make sure that key flows work, critical bugs are fixed, data is saved correctly, and the release is safe to deliver to users.

How is a release checklist different from a test plan?

A test plan describes the overall testing approach: scope, risks, environments, testing types, roles, and strategy. A release checklist is a practical list of specific checks to complete before release.

In simple terms: a test plan answers "how we test," while a release checklist answers "what we need to check before shipping."

Do you need to complete the full checklist before every release?

Not always. For a small change, you can use a shorter version. For a major release, it is better to go through the full checklist and add checks related to the specific feature.

Who should use a Release QA Checklist?

A release checklist is usually used by a QA Engineer. But it is also useful for a Product Manager, Founder, Project Manager, or developer if the team does not have a dedicated QA.

In a small team, a release checklist helps avoid keeping all checks in someone's head and reduces the risk of missing important scenarios.

Can one checklist be used for all releases?

One base checklist can be used as a template, but it should be adapted to the type of release. For example, a release with payments requires additional payment flow checks, while a release with roles requires deeper access testing.

What should be included in a release checklist?

At minimum, include:

• the main user flow;
• authentication and access;
• forms and validation;
• UI and mobile checks;
• data and statuses;
• integrations;
• fixed bug verification;
• short regression smoke check;
• post-release check.

How do you know if a release is ready to ship?

A release is ready to ship when:

• key flows work;
• there are no blocker or critical bugs;
• known issues are documented and accepted by the team;
• data is saved and displayed correctly;
• roles and permissions work correctly;
• the team understands the risks;
• there is a plan in case something goes wrong after release.

Create a release checklist

Use this release QA checklist as a starting point for your next release. In qa::checklist, you can create a project, organize checks by module, track pass/fail status, add comments, and export the completed checklist to CSV.