>_ Smoke Testing Checklist

Short answer

A Smoke Testing Checklist is a short list of critical checks that a team runs before a release, after deployment, or before deeper testing starts. Its goal is to quickly confirm that the product is working at a basic level: the app opens, the user can log in, the core flow works, forms can be submitted, payments or orders work, transactional emails are sent, analytics collects events, and there are no obvious production issues.

Smoke testing does not replace regression testing, release QA, or full testing. It is a fast check to answer one simple question: is the product alive and stable enough to continue?

The main idea is: a smoke test should be short, critical, and repeatable. If the checklist becomes too large, it turns into a regression checklist and loses its purpose. In practice, a smoke test usually includes 5-15 critical checks, not every item from the full list.

When to use a Smoke Testing Checklist

Use a smoke testing checklist whenever you need to quickly confirm that a product, build, or release is in a working state.

For example:

• after deploying a new build to staging;
• before starting full QA;
• before releasing to production;
• immediately after a production deployment;
• after a hotfix;
• after a configuration change;
• after environment variable changes;
• after a data migration;
• after changes in payment, email, analytics, or integrations;
• after rollback;
• after an incident or suspicion that something is broken;
• before handing a build to QA, PM, or a client.

Smoke testing is especially useful as a gate. If the smoke test fails, there is usually no point in starting deeper testing. The team should first fix the basic stability issue.

Quick Smoke Testing Checklist

If you need a minimal smoke test, check that:

• the app or website opens;
• main pages load;
• the user can log in and log out;
• the main user flow works;
• the key form can be submitted;
• data is saved and displayed;
• checkout or payment works, if applicable;
• email or notification is sent, if applicable;
• main CTA buttons and links work;
• there are no critical console errors;
• there are no obvious errors in logs or monitoring;
• the production domain works after release.

This is not full QA. It is a minimal set of checks that helps the team quickly understand whether they can continue or need to stop the release.

Track this checklist in qa::checklist

You can use this guide as a manual smoke testing 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.

Full Smoke Testing Checklist

1. Define the goal of the smoke test

Before starting smoke testing, it is important to understand what exactly you are checking and why.

A smoke test can be different depending on the context:

• build smoke test - to check that a new build on staging works at all;
• pre-release smoke test - to check critical scenarios before release;
• regression smoke test - to quickly confirm that changes did not break the most important existing scenarios;
• production smoke test - to check production after deployment;
• hotfix smoke test - to quickly check the fix and key related areas.

Check that:

• the environment being tested is clear;
• the product version being tested is clear;
• the release changes are known;
• critical scenarios are defined;
• areas outside this smoke test are clear;
• the person responsible for the pass / fail decision is known;
• the team knows what to do if the smoke test fails.

The main question for this part is: what must work for the team to move forward?

2. Prepare the environment and test data

A smoke test should be fast, so the environment and test data should be ready in advance.

Check that:

• the required environment is available;
• the latest build has been deployed;
• the product version matches the expected version;
• a test user is available;
• a test user with the required role is available;
• data for the main scenario is available;
• access to the admin panel is available, if needed;
• access to a test email inbox or mail service is available;
• a test payment method is available, if payment is being checked;
• access to analytics, logs, or monitoring is available, if included in the check;
• feature flags are configured correctly;
• test integrations are connected, if needed.

A smoke test should not stop because there is no account, no test data, or nobody knows where to check the email. These things should be prepared before testing starts.

3. Check that the product opens

Start with the most basic check: the product should open and load the main pages.

Check that:

• the website or app opens;
• the homepage or start page loads;
• the dashboard opens, if there is one;
• main public pages are available;
• main private pages are available after login;
• there is no blank screen;
• there is no endless loader;
• there is no obvious 500 error page;
• there are no incorrect redirects;
• the product does not unexpectedly redirect to staging, an old domain, or localhost;
• the page loads fast enough for a basic check.

If the product does not open or the main page does not load, the smoke test should immediately be considered failed. In this case, there is no point in checking deeper scenarios.

4. Check login, logout, and session

Login is one of the most important smoke scenarios for any product with accounts. If the user cannot log in, most other checks lose their value.

Check that:

• the user can open the login page;
• the user can log in with valid credentials;
• the user lands on the correct page after login;
• the user can log out;
• private pages are not available after logout;
• the session remains active after page refresh;
• expired session is handled clearly, if this is in scope;
• an incorrect password shows a clear error;
• login does not redirect to the wrong environment or an old URL.

For a smoke test, it is usually enough to check one main user account. If roles are critical for the product, add a short check for key roles, such as admin and regular user.

5. Check the main user flow

The main smoke check is to confirm that the user can complete the key action in the product.

For example:

• sign up;
• create an object;
• submit a request;
• place an order;
• complete a payment;
• create a project;
• add a user;
• upload a file;
• generate a report;
• complete onboarding;
• receive confirmation.

Check that:

• the main flow works from beginning to end;
• the user sees the expected result;
• buttons and links in the flow work;
• the form or action can be submitted;
• data is saved;
• the status changes correctly;
• the user does not end up in a broken state;
• the result does not disappear after refresh;
• there are no blocking errors;
• there are no unexpected redirects.

The main question is: can the user complete the most important action in the product right now?

6. Check key forms

Forms are often part of smoke testing because they handle registrations, requests, orders, settings, and important user actions.

Check that:

• the form opens;
• required fields work;
• the form cannot be submitted empty if fields are required;
• valid data can be submitted;
• the user sees a confirmation message;
• data appears in the right place;
• the error is clear if data is invalid;
• entered data is not lost after an error, if expected;
• repeated submit does not create obvious duplicates;
• the form does not break the page after submission.

For a smoke test, you do not need to check all form edge cases. But it is important to confirm that the main submission scenario works and the user gets a clear result.

7. Check data and action results

A smoke test should check not only that "the button was clicked," but also that the expected result appeared after the action.

Check that:

• created data is displayed;
• edited data is updated;
• the status changed;
• the amount or counter updated;
• the object appeared in the list;
• the object is still available after page refresh;
• data was not duplicated;
• data did not disappear;
• the result is visible in the admin panel, if important;
• the result matches what the user did.

For example, if the smoke test includes form submission, seeing a "Thank you" message is not always enough. If it is critical for the product, make sure the request actually arrived in email, CRM, database, or admin panel.

8. Check checkout, payment, or order flow, if applicable

If the product involves payments, orders, subscriptions, or bookings, payment flow should be part of smoke testing.

Check that:

• the user can open checkout;
• the price is displayed correctly;
• cart or order summary is displayed;
• required fields are validated;
• test payment is successful;
• failed payment is handled clearly, if this is in scope;
• successful payment shows confirmation;
• the order appears in the system;
• payment status is correct;
• confirmation email is sent;
• subscription status is correct, if there is a subscription;
• the user does not receive a successful order after failed payment.

For a smoke test, teams usually check one successful payment path. But if payment is a critical area of the product, add at least one basic failed or declined scenario.

9. Check emails and notifications

Emails and notifications often break silently: the interface shows success, but the user receives nothing.

Check that:

• email after signup is delivered;
• email after form submission is delivered;
• confirmation email after order or payment is delivered;
• notification is sent, if it is critical;
• links in the email work;
• the email does not contain test copy;
• the email does not contain staging links;
• the email is sent to the correct user;
• internal notification is sent to the team, if needed;
• notification is not sent multiple times without a reason.

For smoke testing, it is enough to check the most important emails. For example: signup confirmation, password reset, order confirmation, or lead notification.

10. Check main links and navigation

A smoke test should not turn into a full link check, but the main user paths should be verified.

Check that:

• main navigation works;
• the logo leads to the correct page;
• main CTA buttons work;
• links to signup, login, pricing, checkout, or contact are correct;
• footer links work for important pages;
• back or cancel actions work, if they exist;
• direct URL opens the correct page;
• there are no links to staging, localhost, or old domains;
• important pages do not return 404 errors.

Navigation is especially important to check after changes in layout, header, routing, domain, CMS, or frontend.

11. Check UI sanity

Smoke testing should not be full visual QA, but obvious visual breakages should be caught immediately.

Check that:

• main pages do not look broken;
• text is not cut off in critical places;
• buttons are visible;
• forms are accessible;
• modals open;
• dropdowns or menus work;
• loading state does not get stuck;
• empty state looks acceptable;
• error state does not look like a broken page;
• there are no obvious layout issues after deployment.

Smoke UI sanity is especially important after frontend changes, redesigns, component updates, or CSS changes.

12. Check mobile sanity

Even a short smoke test should include at least one mobile viewport if users may access the product from a phone.

Check that:

• the key page opens on mobile;
• the mobile menu works;
• the main CTA is visible;
• buttons are easy to tap;
• the form is accessible;
• content does not go outside the screen;
• there is no unexpected horizontal scrolling;
• the modal fits on the screen;
• sticky elements do not cover a button or form;
• the main flow can be started or completed on a phone.

For smoke testing, you do not need to check every device. But if mobile traffic matters, one short mobile sanity check can catch very expensive mistakes.

13. Check main integrations

If the product depends on external systems, the smoke test should include at least a short check of key integrations.

Check that:

• CRM receives the request;
• payment provider returns the correct status;
• email provider sends the email;
• webhook is sent;
• external API responds;
• data is transferred in the correct format;
• integration error does not break the entire user scenario;
• the user sees a clear message when there is a problem;
• internal alert is sent, if needed.

You do not have to check every integration in every smoke test. But if the release affects payment, email, CRM, API, or webhooks, these areas should be included.

14. Check analytics and tracking

Analytics is often forgotten during smoke testing, but it is an important part of launch, release, and production checks.

Check that:

• page view is sent;
• signup event is sent, if there is signup;
• form submit event is sent, if there are forms;
• checkout or purchase event is sent, if there is payment;
• CTA click event is sent, if it is critical;
• events are not duplicated;
• events have correct names;
• UTM parameters are not lost;
• analytics script loads;
• cookie consent does not block tracking unexpectedly;
• production events are sent to the correct analytics property.

If the release is related to marketing, paid traffic, an SEO landing page, or funnel analytics, tracking should be part of the smoke test, not something to check later.

15. Check console errors, network, and logs

A smoke test should include a quick technical sanity check, especially after a frontend or production deployment.

Check that:

• there are no critical console errors;
• there are no failed API requests in the key flow;
• there are no unexpected 500 responses;
• there are no broken assets;
• there are no mixed content warnings;
• there are no CORS errors;
• there are no authentication errors in the normal scenario;
• logs do not show a sudden increase in errors;
• monitoring does not show a critical incident;
• error tracking does not receive many new errors.

Not every console warning is a blocker. But critical errors, failed API calls, broken assets, payment errors, auth errors, and a sudden increase in production errors should stop the release or require immediate investigation.

Regression Smoke Test Checklist

16. Check affected areas after changes

A Regression Smoke Test Checklist is useful when the team wants to quickly confirm that changes did not break the most important existing scenarios.

Check:

• what changed in the release;
• which areas may have been affected;
• the main flow of the changed area;
• related scenarios;
• old critical flow;
• login / logout;
• main roles and permissions;
• key forms;
• data and statuses;
• emails or notifications;
• integrations, if related to the change;
• mobile sanity for the changed area;
• critical console errors.

A regression smoke test does not replace full regression testing. It helps quickly catch obvious breakage after a change.

17. Check fixed bugs and nearby scenarios

If the smoke test is performed after a bug fix, check not only the fix itself but also nearby scenarios.

Check that:

• the original bug no longer reproduces;
• the fix works in the main scenario;
• a similar scenario is not broken;
• old data is displayed correctly;
• new data is created correctly;
• the error no longer appears;
• the user sees the correct result;
• the fix did not break a nearby flow.

For example, if a form submission bug was fixed, a short regression smoke test may include: successful form submission, validation error, receiving an email, seeing the request in the admin panel, and confirming there is no duplicate submit.

Production Smoke Test Checklist

18. Check production immediately after deployment

A Production Smoke Test Checklist is used after release to make sure the real environment works for users.

Check that:

• production domain opens;
• SSL certificate works;
• HTTP redirects to HTTPS;
• www / non-www versions go where they should;
• main pages are available;
• login works;
• main user flow works;
• forms can be submitted;
• checkout or payment works, if applicable;
• emails or notifications are sent;
• data is saved;
• analytics receives events;
• there are no links to staging;
• feature flags are configured correctly;
• there is no test content;
• there is no sudden increase in errors in logs or monitoring.

A production smoke test should be short and safe. Its goal is to confirm that real users can complete key actions after deployment.

19. Check production configuration

Some bugs appear only in production because of environment settings, domains, integrations, or access configuration.

Check that:

• environment variables are configured correctly;
• API endpoints point to production, if needed;
• payment provider is configured in the correct mode;
• email sender is configured correctly;
• analytics property is correct;
• feature flags are enabled or disabled as planned;
• permissions work in production;
• admin panel is available only to the right people;
• staging data has not appeared in production;
• test users, test banners, or debug messages are not visible to users;
• robots.txt and noindex are configured correctly, if this is a public website.

Production smoke testing often catches configuration issues, not code bugs. That is why it cannot be fully replaced by staging checks.

20. Make a pass / fail decision

A smoke test should end with a clear result.

Document:

• whether the smoke test passed or failed;
• which environment was tested;
• which version was tested;
• which critical scenarios were checked;
• which scenarios were not checked;
• which bugs were found;
• whether there are blocker or critical issues;
• whether full QA can continue;
• whether the release can go out;
• whether rollback, hotfix, or additional testing is needed.

Smoke testing should not end with "seems fine." The team should clearly understand whether the product passed the minimum critical check and whether it is safe to move forward.

Common mistakes

1. Making the smoke test too large

If the smoke checklist becomes huge, the team stops running it quickly. Smoke testing should check only critical scenarios. Everything else belongs to regression testing, release QA, or a full test pass.

2. Checking only the homepage

An open homepage does not mean the product works. A smoke test should include login, core flow, forms, data, and other business-critical scenarios.

3. Not checking production after release

Staging may work perfectly, but production can break because of domain settings, environment variables, email provider, payment configuration, feature flags, or permissions.

4. Ignoring console errors and failed API requests

The interface may look fine while API requests, analytics events, payment calls, or integrations fail in the background. A quick technical sanity check helps catch these problems.

5. Not checking emails and notifications

A user may successfully complete an action in the interface but never receive a confirmation email, password reset email, order confirmation, or internal notification. For many products, this is a critical bug.

6. Treating smoke testing as a replacement for regression testing

Smoke testing answers the question: "is the product basically alive?" Regression testing answers the question: "did the changes break existing scenarios?" These are different levels of testing.

7. Not documenting pass / fail

If the smoke test result is not documented, the team does not clearly understand whether QA can continue, whether the release can go out, or whether production is stable.

8. Testing only the happy path without technical signals

Smoke testing is usually focused on the happy path, but it should still include technical signals: console errors, failed network requests, logs, monitoring, and production sanity.

FAQ

What is a Smoke Testing Checklist?

A Smoke Testing Checklist is a short list of critical checks that helps quickly confirm whether a product works after a build, deploy, hotfix, or release.

It usually includes login, core flow, forms, payments, emails, analytics, console errors, and production sanity.

How is smoke testing different from regression testing?

Smoke testing is a short check of the product's basic stability. It answers the question: does the product work at a basic level, and can the team move forward?

Regression testing checks existing functionality after changes. It answers the question: did the changes break old scenarios?

In simple terms: smoke testing is a fast critical check, while regression testing is a deeper check of affected areas and existing functionality.

What is a regression smoke test checklist?

A regression smoke test checklist is a shorter version of regression testing. It does not check the whole product. It checks only the most important affected areas, high-risk flows, and critical existing scenarios after changes.

For example, after a checkout change, a regression smoke test may include cart, pricing, promo code, payment, order confirmation, email, and admin order view.

What is a production smoke test checklist?

A production smoke test checklist is a short set of checks after deployment to production. It helps confirm that the real domain, login, core flow, forms, payments, emails, analytics, integrations, and monitoring work after release.

Production smoke testing is especially important because some problems appear only in the real environment: configuration, domain, SSL, feature flags, payment settings, email delivery, or environment variables.

When should smoke testing be done?

Smoke testing should be done:

• after a new build;
• after deployment to staging;
• before full QA;
• before release;
• immediately after production deployment;
• after a hotfix;
• after rollback;
• after configuration changes;
• after changes in payment, email, analytics, or integrations.

How long should a smoke test take?

A smoke test is usually short. For a small product, it may take 5-15 minutes. For a larger product with payment, roles, integrations, or mobile checks, it may take 20-40 minutes.

If the smoke test takes hours, it is probably no longer a smoke test. It may need to be split into a short smoke checklist and a deeper regression checklist.

Who should run a smoke test?

A smoke test is usually run by QA, but it can also be run by a developer, Product Manager, release manager, founder, or support specialist in a small team.

The important part is that the person knows the critical flow, understands what counts as pass or fail, and can quickly escalate blocker issues.

What should be included in a smoke testing checklist?

At minimum, include:

• app or website opens;
• login / logout;
• main user flow;
• key forms;
• data and statuses;
• payment or checkout, if available;
• emails or notifications, if available;
• main links and CTA buttons;
• mobile sanity, if mobile matters;
• analytics and tracking, if important;
• console errors, failed API requests, logs, and monitoring;
• production sanity after release.

Should payment be checked in a smoke test?

Yes, if payment is a critical part of the product. For a smoke test, it is usually enough to check one successful payment path in a safe test mode or through an agreed production process.

If the payment flow is complex or high-risk, it is also worth adding a basic failed or declined payment check.

Should analytics be checked in a smoke test?

Yes, if the team depends on launch data, conversion events, paid traffic, or funnel metrics. At minimum, check page view, signup, form submit, checkout, purchase, or another key conversion event.

Analytics is especially important to check in a production smoke test because tracking may work on staging but send data to the wrong production property, or fail because of cookie consent.

Can smoke testing be automated?

Yes. Smoke testing is a good fit for automation because it is a short and repeatable set of critical checks.

Good candidates for automation include:

• login;
• core user flow;
• form submit;
• checkout happy path;
• API health check;
• basic permissions;
• production availability;
• critical smoke tests after deploy.

But manual smoke testing is still useful after UI changes, new UX, production deployments, complex integrations, and situations where human judgment matters.

How do you know if a smoke test passed?

A smoke test can be considered passed if:

• the product opens;
• the user can log in;
• the main flow works;
• critical forms can be submitted;
• data is saved;
• payment, email, or integrations work, if they are critical;
• there are no blocker or critical bugs;
• there are no critical console errors or failed API requests;
• production does not show a sudden increase in errors;
• the team can continue QA or consider the release stable.

If at least one critical scenario does not work, the smoke test should be considered failed.

Create a smoke testing checklist

Use this smoke testing checklist as a starting point for your next build, release, hotfix, or production deployment. In qa::checklist, you can organize smoke checks by module, track pass/fail status, add comments, and export the completed checklist to CSV.