Smoke testing is a fast check that confirms whether a new software build is stable enough for deeper testing. A smoke test covers critical functions such as app launch, login, navigation and one primary user flow. If one of these basic checks fails, the build goes back to development before the QA team spends time on broader testing.

TL;DR - Smoke Testing

• Smoke testing = a quick build health check — it confirms that the application's most important functions work after a build or deployment.
• Smoke tests are broad but shallow — they touch critical paths without testing every condition or edge case.
• Smoke testing and sanity testing have different jobs — smoke testing checks the whole build at a basic level, while sanity testing focuses on a specific change.
• Regression testing goes deeper — it checks that recent changes haven't broken existing behavior.
• Automated smoke testing fits naturally into CI/CD — stable critical paths can run after every relevant deployment.
• A failed smoke test usually means stop — fix the blocker before spending time on a larger test suite.

Smoke vs sanity vs regression testing

The easiest way to remember the difference is simple: smoke testing asks “Is the build usable?”, sanity testing asks “Does the changed area work?” and regression testing asks “Did the latest change break something that worked before?”

What is smoke testing?

Smoke testing is a preliminary software testing method used to check if the most important parts of a new build work well enough for further testing.

It is also known as build verification testing (BVT) because the goal is to verify the basic health of a build before a testing team commits time to detailed functional, integration or regression testing.

A smoke test does not try to cover every feature, input and edge case. Instead, it touches the functions that would make further testing pointless if they were broken.

For a typical web application, a smoke test might confirm that:

• The application loads without a critical error
• The login page opens
• Authentication works
• The main navigation responds
• Critical pages load
• One core user workflow can be completed
• Important API-backed data appears

Imagine a project management platform where users cannot sign in after the latest deployment.

The QA team could still have hundreds of prepared test cases for task filters, notifications, permissions and reports. None of them matter yet because testers cannot get into the product.

That is where smoke testing earns its place in the software testing process. It gives the team a fast go/no-go decision.

If the smoke tests pass, deeper testing can continue. If a critical smoke test fails, the build goes back to development.

Why smoke testing is called "smoke" testing

The name comes from hardware testing. Engineers would power up a new device and look for smoke, sparks or another obvious sign of catastrophic failure. If nothing burned, deeper testing could begin. Software teams adopted the same metaphor. A smoke test checks that a new build has no obvious critical failure before anyone invests time in detailed testing.

Why is smoke testing important?

A broken build can waste a surprising amount of testing time.

Without an initial smoke test, QA engineers may begin executing detailed cases only to discover that authentication is unavailable, an important API is down or the application's primary dashboard does not load.

Smoke testing moves that discovery to the beginning of the process.

The main benefits include:

• Faster feedback: teams find blockers shortly after a build or deployment.
• Less wasted QA time: testers avoid detailed testing on an obviously unstable build.
• Clearer release decisions: a smoke test suite provides a simple pass/fail signal.
• Earlier defect detection: major problems surface closer to the change that caused them.
• Good automation potential: critical paths tend to be repeatable and suitable for automated testing.

A smoke test does not need to find every problem.

It needs to find the problems large enough to make further testing a bad use of time.

Smoke testing vs sanity testing

Smoke testing and sanity testing are easy to confuse because both provide fast feedback and both tend to happen before more exhaustive testing.

The difference is what each test is trying to prove.

Smoke testing checks the general stability of a build. It touches several important areas of the product without exploring them deeply.

Sanity testing checks a specific area after a focused change. A sanity test usually follows a bug fix, small feature update or another limited modification.

Consider a SaaS application where developers have fixed an issue with password reset.

A smoke test for the new build might check:

• The application loads
• Users can log in
• The dashboard opens
• Main navigation works
• A primary user workflow remains available

A sanity test for the same build may focus entirely on password reset:

• The user can request a reset
• The reset email is triggered
• The reset URL opens
• A new password can be saved
• The new password works during login

The sanity test can pass even when an unrelated critical feature is broken.

Likewise, a passing smoke test does not prove that every detail of the password-reset fix works correctly.

That is why smoke testing and sanity testing complement each other rather than compete.

For a deeper comparison, read Smoke Testing vs Sanity Testing.

Smoke testing vs regression testing

Smoke testing and regression testing differ mainly in scope, depth and timing.

A smoke test checks a small selection of critical functionality and answers one immediate question: is the application stable enough for more testing?

Regression testing checks that functionality which worked before still works after software changes.

Take an ecommerce application.

A smoke test after a deployment may verify that:

• The storefront opens
• Customers can sign in
• A product page loads
• A product can be added to the cart
• Checkout can be reached

A regression suite may go much further and check:

• Search and filtering
• Product variants
• Discount codes
• Saved addresses
• Shipping calculations
• Tax rules
• Failed payments
• Successful payments
• Order confirmation
• Order history
• Account settings

That difference explains why smoke tests usually run in minutes while a large regression suite may take much longer.

Passing a smoke test does not mean the application is bug-free.

It means the build has passed its first health check and is ready for deeper verification.

Read Smoke Testing vs Regression Testing for a deeper comparison.

How smoke and sanity testing work together

Smoke and sanity testing work well as two separate gates.

Imagine a new build has just reached staging.

1. Deploy the build. The new version becomes available in the test environment.
2. Run smoke tests. Check application launch, authentication, navigation and the main business-critical flows.
3. Stop if smoke testing fails. A critical failure means the build is not ready for detailed QA.
4. Run sanity testing. If the smoke tests pass, check the feature or bug fix included in the release.
5. Continue with broader testing. The team can move into regression, integration, acceptance or other testing.

The sequence prevents two common problems.

First, the team does not waste time investigating details in a fundamentally broken build.

Second, a focused sanity test is not mistaken for a complete build health check.

A practical flow looks like:

New build → smoke test → sanity test → regression testing → release decision

Smoke testing example: a 90-second web app check

Here is a concrete smoke testing example.

The entire smoke test takes around 90 seconds.

1. 0–10 seconds: Open the application.
   Confirm that the homepage loads instead of returning a blank screen, fatal error or server error.
2. 10–20 seconds: Open the login screen.
   Confirm that the email and password fields appear and the page is usable.
3. 20–35 seconds: Log in.
   Use a prepared test account and confirm that valid credentials are accepted.
4. 35–50 seconds: Check the dashboard.
   Confirm that the dashboard loads and the main navigation is visible.
5. 50–65 seconds: Open the projects area.
   Navigate to the product's primary workspace or project view.
6. 65–80 seconds: Perform one core action.
   Create a basic task and confirm that it appears in the project.
7. 80–90 seconds: Log out.
   Confirm that the session ends and the application returns to its public authentication state.

The decision rule matters more than the timer.

If step three fails because users cannot log in, the team does not continue testing reports, notifications and project settings just to collect more failures.

The build has already failed its smoke test.

Playwright smoke test example

Developers can automate the same type of check with Playwright.

Install Playwright with npm:

npm init playwright@latest

Then create a small smoke test:

import { test, expect } from '@playwright/test'; test('smoke: Demo SaaS entry points', async ({ page }) => { await page.goto('https://demo-saas.bugbug.io/'); await expect(page).toHaveURL(/demo-saas/); await page.getByRole('link', { name: /log in/i }).first().click(); await expect(page).toHaveURL(/sign-in/); await expect(page.locator('input[type="email"]')).toBeVisible(); await page.goto('https://demo-saas.bugbug.io/sign-up'); await expect(page).toHaveURL(/sign-up/); await expect(page.locator('form')).toBeVisible(); });

The example uses BugBug's public Demo SaaS application and keeps the test deliberately small.

A production smoke suite may also include authenticated flows, but the same rule applies: focus on the handful of actions that determine if a build deserves deeper testing.

You can create a similar smoke test in Cypress or another browser automation framework.

Smoke test checklist for a web application

A reusable smoke test checklist helps teams keep the first layer of testing focused.

• Does the application load without a fatal error?
• Does the login page open?
• Can a valid user log in?
• Does the primary dashboard or home screen load?
• Does the main navigation work?
• Can the user reach the application's most important feature?
• Can one critical record be created or viewed?
• Can the most important form be submitted?
• Does critical API-backed data appear?
• Can a business-critical transaction start or complete?
• Can the user log out?

You do not need every item for every application.

A good smoke test checklist is the shortest set of checks that can reliably tell your team when a build is not ready for further testing.

Real-world scenarios: how smoke testing plays out

Smoke testing becomes especially useful when a team needs fast feedback after a software change.

Here are three situations where that matters.

New feature release: preventing critical issues from reaching production

Scenario: Your SaaS platform has just added a new Team Analytics dashboard with charts, filters and new navigation.

The feature has passed unit testing and the build is now available in staging.

A smoke test verifies that:

• The application launches
• Authentication still works
• The dashboard loads
• Charts render
• Main navigation works
• No blocker prevents users from reaching the new feature

Suppose the analytics dashboard itself works, but the latest deployment has broken the application's global navigation.

That is enough to fail the smoke test.

There is little value in testing chart filters, export options and visualization settings while a critical navigation path is broken.

A smoke test does not need to explain everything wrong with a build.

It needs to tell the team when the build is not worth testing further.

Hotfix deployment: verifying stability after a bug fix

Scenario: A production issue prevents some customers from completing checkout. Developers prepare a hotfix and deploy it to staging.

The team naturally wants to test the payment fix, but first it needs a quick signal that the rushed change did not damage another critical path.

A smoke test may cover:

• Login
• Product selection
• Cart access
• Checkout
• Payment confirmation
• Order history

Once the overall flow passes, a focused sanity test can inspect the payment change in more detail.

That is a practical example of smoke and sanity testing working together.

Smoke testing checks the overall stability of the build. Sanity testing checks the specific area that changed.

Continuous integration: catching bugs early in the development process

Instead of waiting for someone to manually open the application, an automated smoke testing suite runs immediately.

It checks that:

• The app loads
• Authentication works
• The dashboard is available
• A user can open the primary workflow
• Critical API-backed screens return data

If the smoke tests pass, the pipeline continues.

If they fail, the team gets feedback close to the code change that caused the problem.

That becomes especially useful when teams deploy several times per day.

A repetitive manual check can quickly turn into a bottleneck. A small automated smoke suite can provide the same first signal after every relevant build.

What's included in a typical smoke test?

There is no universal smoke test template.

The critical path of a banking application looks different from the critical path of a project management platform, ecommerce store or analytics product.

Still, useful smoke tests tend to have several characteristics in common.

They cover critical functionality

A smoke test should focus on functionality whose failure would make the application unusable or make further testing inefficient.

Authentication is a common example.

If testers cannot enter the application, most test cases for logged-in functionality become impossible to execute.

They stay shallow

Smoke tests confirm that functionality basically works; they do not explore every possible variation.

For checkout, a smoke test may use one known product, one valid address and one supported payment path.

Testing multiple payment methods, invalid coupons, unusual tax combinations, network failures and edge cases belongs in deeper functional or regression testing.

They produce a clear result

A smoke suite should tell the team what happens next. If it passes, continue. If a critical smoke test fails, investigate the build first.

They use predictable test data

Unstable data can turn a useful smoke suite into a source of false failures.

A test may fail because an account expired, someone deleted a required record or an external dependency returned unexpected data.

Use stable test accounts and reusable test data where possible.

They run quickly

Speed is part of the point.

A small web application may have a smoke suite that runs in 90 seconds. A larger product may need several minutes.

If the suite regularly runs for hours, it has probably expanded beyond smoke testing.

Who performs smoke testing?

Smoke testing can be performed by different people depending on team size and development process.

• In a small startup: a QA engineer, developer or product manager may run a smoke test manually.
• In a growing SaaS team: repeatable smoke tests are often automated after staging deployments.
• In a larger engineering organization: smoke tests commonly run inside CI/CD pipelines.
• Without a dedicated QA team: developers can still maintain a small critical-path checklist.

The job title matters less than consistency.

The team should have a repeatable definition of what the application must do before more detailed testing begins.

Even a non-technical teammate can run a simple manual smoke test with a clear test plan.

Manual vs automated smoke testing

Smoke tests can be manual or automated.

Manual smoke testing makes sense when releases are infrequent, workflows change often or a team is still deciding which checks belong in the smoke suite.

A tester can open the application, follow a small checklist and report if the build is ready for further QA.

Automated smoke testing becomes more attractive when the same checks happen frequently.

If someone manually checks login, dashboard access and project creation after several deployments every day, that flow is a strong candidate for automation.

Many teams use both.

They automate predictable critical paths and keep manual testing available when a release needs additional human inspection.

Automated smoke testing

Automated smoke testing runs a predefined set of critical health checks automatically after a build, merge or deployment.

It is a practical place to start with test automation because smoke tests tend to be short, repeatable, business-critical and executed frequently.

Good candidates for automated smoke tests include:

• Opening the application
• Logging in with a test account
• Loading the primary dashboard
• Checking main navigation
• Opening a key workspace
• Creating one basic record
• Submitting an important form
• Checking one critical transaction

The important part is keeping the smoke suite small.

Do not automate an entire regression suite and rename it “smoke testing.”

Once dozens of edge cases and secondary workflows enter the suite, execution becomes slower and failures become harder to interpret.

Teams can automate smoke tests with code-first frameworks such as Playwright or Cypress, or with browser automation tools such as BugBug.

For a broader look at the process, see the Guide to Automated Smoke Testing.

How to automate a smoke test in BugBug

BugBug lets teams record browser interactions and save them as repeatable automated tests.

A basic setup looks like this:

1. Create a project. Add the web application you want to test.
2. Record a critical flow. For example: login → dashboard → create task.
3. Add assertions. Check the pages, elements or results that determine if the build is usable.
4. Save the test. Give it a clear name such as Smoke – Login and Main Workflow.
5. Create a smoke suite. Group only the tests needed for the initial build health check.
6. Run it after deployments. Execute the same checks whenever a relevant build becomes available.
7. Maintain it. Update smoke tests when critical user journeys change.

For a full walkthrough, see Smoke Testing with BugBug.

Running smoke tests in CI/CD

Automated smoke tests become even more useful when nobody needs to remember to launch them manually.

A typical CI/CD flow looks like this:

1. A developer merges code.
2. The application is built.
3. The new build is deployed to a testing environment.
4. The smoke test suite runs.
5. The pipeline checks the result.
6. A passing suite allows the next stage to continue.
7. A failed suite stops the process for investigation.

BugBug provides a CLI for triggering tests from continuous integration and delivery workflows.

See the BugBug CLI documentation for setup instructions.

Teams using GitHub can also use the BugBug GitHub integration.

The release rule can stay simple:

• Smoke tests pass → continue
• Smoke tests fail → stop and investigate

That turns smoke testing into a real quality gate rather than another report someone has to remember to open.

When to run smoke tests

Smoke tests make the most sense after a change that could affect the basic stability of an application.

• [ ] After a new build. This is the classic use case. Before QA begins detailed testing, run the smoke suite and check if the build is testable.
• [ ] After deployment to staging. A build can work locally and fail after deployment because of configuration, routing, missing services or environment-specific problems. A staging smoke test catches those issues quickly.
• [ ] After a hotfix. Hotfixes often happen under time pressure. A quick smoke test can show that the fix did not damage another critical application path before the release moves ahead.
• [ ] After a major merge. When several changes enter the main branch, smoke testing provides early feedback about integration problems.
• [ ] Before regression testing. Regression suites can be expensive to run. There is little reason to launch hundreds of regression tests if a short smoke suite already shows that authentication is broken.
• [ ] Before acceptance testing. Stakeholders and acceptance testers should not receive an obviously broken build. A smoke test provides a fast gate first.
• [ ] After infrastructure or environment changes. Application code is not the only source of failure. Changes to databases, authentication providers, APIs, hosting or configuration can also break critical workflows.
• [ ] After a production deployment. Some teams also run a carefully selected production smoke test after release to check that their most important public paths remain available. Production smoke tests should use safe scenarios that do not damage real customer data or create unwanted transactions.

How to choose good smoke test cases

The hardest part of smoke testing is often deciding what not to include.

Start with the features that would cause the team to reject a build immediately if they failed.

Ask:

• Can users enter the application?
• Can they authenticate?
• Can they reach the main product area?
• Can they perform the action the product exists to support?
• Are critical dependencies returning data?
• Is anything blocking the next testing phase?

For a CRM, creating or viewing a contact may belong in the smoke suite.

For an ecommerce store, reaching checkout probably matters more.

For an analytics platform, loading a dashboard with data may be critical.

For a booking platform, searching availability and reaching the booking flow may be enough for the first gate..

Common smoke testing mistakes

Smoke testing is simple in theory, but a few mistakes can make it much less useful.

• Making the smoke suite too large. Teams keep adding “just one more test” until a five-minute health check becomes a 90-minute suite. Move secondary workflows, variations and edge cases into regression testing. Protect the speed of the smoke suite.
• Testing only the latest feature. If the team only tests the functionality that changed, the activity is closer to sanity testing. Smoke testing should still touch the overall critical path of the application.
• Testing too many edge cases. A smoke test for login may check one valid account. Testing locked accounts, malformed email addresses, expired sessions, incorrect passwords and multiple authentication error states belongs elsewhere.
• Using unstable test data. Tests based on temporary users, manually prepared records or unpredictable external data can create false failures.. That becomes especially painful in CI/CD because frequent false alarms reduce trust in the test suite.
• Ignoring failed smoke tests. Decide what failure means before automating the suite. If a critical smoke test fails but the release continues exactly as if nothing happened, the test is not acting as a meaningful gate.
• Never updating smoke tests. Products change. A workflow that was critical a year ago may now be secondary, while a newer feature may have become central to the product. Review smoke tests when key user journeys change.
• Treating a pass as complete release confidence. A smoke test has intentionally limited coverage. A passing smoke test does not replace regression testing, security testing, performance testing, integration testing, exploratory testing or acceptance testing. It tells you one thing: the build has passed the first gate.

Don't skip the basics

Smoke testing is not supposed to find every defect.

It has a much simpler job: find out quickly if the build is healthy enough to deserve more testing.

That makes smoke tests useful after new builds, hotfixes, staging deployments and CI/CD releases.

Use smoke testing for the overall health of the build. Use sanity testing for focused changes. Use regression testing when you need broader confidence that existing functionality still works.

And if your team repeats the same critical browser checks after every deployment, automate them.

With BugBug, teams can record critical browser flows, save them as reusable smoke tests and run them again whenever a new build needs a fast health check.

What is smoke testing in software?

Smoke testing is a quick set of tests that checks if the most critical parts of a new software build work before deeper testing begins. It normally covers basic paths such as application launch, authentication, navigation and one primary workflow. A critical failure usually sends the build back for a fix.

How long should smoke tests take?

Smoke tests should finish quickly enough to run frequently. A small suite may take one or two minutes, while a larger web application may need several minutes. If the suite regularly takes hours, it has probably expanded into broader regression testing rather than remaining a focused smoke suite.

How many test cases should a smoke test have?

There is no fixed number. Use the smallest set of test cases that covers the application's critical paths and gives the team a useful go/no-go decision. A simple web application may need fewer than ten checks, while a complex platform may need more.

Can smoke tests be automated?

Yes. Automated smoke testing works especially well for stable, repeatable browser flows such as login, dashboard access and critical user actions. Teams can automate smoke tests with BugBug, Playwright, Cypress and other testing tools and run them automatically after builds or deployments.

What is the difference between smoke testing and regression testing?

Smoke testing is fast and shallow and covers only a small set of critical functions. Regression testing provides much broader coverage and checks that software changes have not broken existing behavior. A smoke suite may run in minutes, while a full regression suite can take considerably longer.

What is the difference between smoke testing and sanity testing?

Smoke testing checks the general stability of a build across several critical functions. Sanity testing focuses on a specific feature or component after a smaller change or bug fix. Teams often run a smoke test first and use a sanity test afterward to verify the area that changed.