What Is Smoke Testing?

Smoke testing, also known as Build Verification Testing (BVT), is a quick, broad test of the most critical functionality to determine whether a new build is stable enough for further testing. The name comes from hardware testing — when you power on a new circuit board, you first check if smoke comes out. If it does, there is no point testing anything else.

In software, smoke testing answers one question: “Is this build fundamentally broken, or can we proceed with deeper testing?”

A smoke test does not try to find every bug. It does not exercise every feature. It checks that the essential functions work — the application starts, users can log in, the main page loads, core workflows are accessible. If the smoke test fails, the build is rejected and sent back to development. If it passes, QA proceeds with more thorough system and regression testing.

Smoke Testing vs Other Quick Tests

Test TypePurposeScopeWhen
SmokeIs the build stable?Broad but shallowAfter every build
SanityDid the fix work?Narrow and focusedAfter specific changes
RegressionDid anything break?ComprehensiveBefore release

What to Include in a Smoke Test Suite

A smoke test suite should be:

  • Small: 5-20 test cases (not 200)
  • Fast: Complete in under 10 minutes
  • Critical: Cover only the most important functionality
  • Automated: Run without human intervention in CI/CD

Smoke Tests for Web Applications

  1. Application loads — Homepage returns HTTP 200 and renders correctly
  2. Login works — User can authenticate with valid credentials
  3. Main navigation works — All primary menu items are accessible
  4. Core feature 1 — Primary business function works (e.g., search returns results)
  5. Core feature 2 — Secondary business function works (e.g., add to cart succeeds)
  6. Database connectivity — Application can read from and write to the database
  7. Static assets load — CSS, JavaScript, and images load correctly
  8. Error handling — Application shows a proper error page (not a stack trace) for 404

Smoke Tests for Mobile Applications

  1. App launches — Application opens without crashing
  2. Login/Authentication — User can sign in
  3. Main screen loads — Core content is displayed
  4. Navigation — Tab bar / drawer navigation works
  5. Network requests — API calls succeed and data loads
  6. Push notifications — Notification registration is successful
  7. Core action — Primary user action completes (e.g., create a post, place an order)

Smoke Tests for APIs

  1. Health endpoint — GET /health returns 200
  2. Authentication — Valid token returns 200; invalid returns 401
  3. Core GET endpoint — Primary read operation returns expected data structure
  4. Core POST endpoint — Primary write operation creates a resource
  5. Database operations — CRUD operations complete without errors
  6. External integrations — Third-party service connections are alive
  7. Response format — API returns correctly formatted JSON/XML

Smoke Testing in CI/CD

Automated smoke tests are the first quality gate in a CI/CD pipeline:

graph LR CODE[Code Commit] --> BUILD[Build] BUILD --> SMOKE[Smoke Tests] SMOKE -->|Pass| UNIT[Unit Tests] UNIT --> INT[Integration Tests] INT --> DEPLOY_STAGING[Deploy to Staging] DEPLOY_STAGING --> E2E[E2E Tests] SMOKE -->|Fail| REJECT[Reject Build
Notify Developer] style SMOKE fill:#eab308,color:#000 style REJECT fill:#ef4444,color:#000

Benefits of automated smoke tests in CI/CD:

  • Fast feedback: Developers know within minutes if their change broke the build
  • Saves time: Prevents QA from spending hours testing a broken build
  • Gate function: Blocks deployment of unstable builds to test environments
  • Confidence: Team knows every deployed build has basic functionality confirmed

Smoke Test Best Practices

Run smoke tests on every build. Not just nightly — on every commit or at minimum every PR merge.

Keep them fast. If smoke tests take 30 minutes, they lose their value. Under 10 minutes is ideal; under 5 is excellent.

Never skip smoke tests. When pressure to release mounts, smoke tests might seem like a delay. They are not. They are the safety net that prevents deploying a broken build to production.

Maintain them ruthlessly. A failing smoke test must always indicate a real problem. Fix flaky smoke tests immediately or remove them — a smoke test you ignore is worse than no test at all.

Exercise: Create a Smoke Test Checklist for a Web App

You are QA Lead for a project management web application (similar to Jira or Asana) with the following features:

  • User authentication (email/password and SSO)
  • Project creation and management
  • Task creation with assignees, due dates, and priorities
  • Kanban board with drag-and-drop
  • File attachments on tasks
  • Notifications (in-app and email)
  • Reporting dashboard with charts
  • Search across projects and tasks

Create a smoke test checklist of 10-15 test cases. For each, specify: test name, steps (brief), and expected result. Prioritize by what would cause the most damage if broken.

HintFocus on the happy path of the most critical workflows. Ask yourself: "If this specific function were broken, would the entire application be unusable?" If yes, it belongs in the smoke test. If it is just annoying but the app still works, it is a regression test item, not a smoke test.
Solution

Priority 1: Application is Alive

  1. Homepage loads

    • Steps: Navigate to application URL
    • Expected: Login page renders, all assets load, HTTP 200

  2. User can log in

    • Steps: Enter valid email/password, click Login
    • Expected: Dashboard loads, user name displayed in header

  3. SSO login works

    • Steps: Click “Sign in with Google”, complete OAuth flow
    • Expected: Dashboard loads, user authenticated

Priority 2: Core Features Work

  1. Create a project

    • Steps: Click “New Project”, enter name “Smoke Test Project”, save
    • Expected: Project created, appears in project list

  2. Create a task

    • Steps: Open project, click “New Task”, enter title, assign to self, set due date, save
    • Expected: Task created, appears on Kanban board in correct column

  3. Kanban board loads and responds

    • Steps: Open Kanban board for a project with existing tasks
    • Expected: Board renders with correct columns and task cards

  4. Search works

    • Steps: Type “Smoke Test” in global search
    • Expected: Results include the project/task just created

Priority 3: Supporting Features

  1. File upload works

    • Steps: Open a task, attach a file, save
    • Expected: File uploads, appears in attachments list

  2. Notifications appear

    • Steps: Assign a task to another user
    • Expected: Notification appears for the assigned user (check in-app notification bell)

  3. Dashboard loads with data

    • Steps: Navigate to Reporting Dashboard
    • Expected: Charts render with data, no blank widgets or errors

  4. User can log out

    • Steps: Click profile menu, click “Log Out”
    • Expected: Redirected to login page, session invalidated

Priority 4: Error Handling

  1. Invalid URL shows 404 page

    • Steps: Navigate to /nonexistent-page
    • Expected: Custom 404 page (not a server error or stack trace)

  2. API returns proper errors

    • Steps: Attempt to access a project that does not exist
    • Expected: “Project not found” message (not a crash)

Total: 13 smoke tests, estimated time: 8-10 minutes (automated), 15-20 minutes (manual)

Smoke Testing Anti-Patterns

Anti-pattern 1: Too many smoke tests. If your smoke suite has 100 tests and takes an hour, it is a regression suite disguised as a smoke test. Keep it under 20.

Anti-pattern 2: Smoke tests that never fail. If your smoke tests have not caught a broken build in a year, they might be testing the wrong things — or they are too trivial. Periodically review what you are testing.

Anti-pattern 3: Manual-only smoke tests. Manual smoke testing is better than nothing, but it is slow and inconsistent. Automate your smoke tests for CI/CD integration.

Anti-pattern 4: Ignoring failures. “Oh, that smoke test always fails on Mondays” is a sign of a deeper problem. Every failure must be investigated.

Pro Tips

Tip 1: Your smoke test is your deployment confidence. If you would not deploy to production after the smoke test passes, the smoke test is incomplete. Add whatever check would give you that confidence.

Tip 2: Smoke tests are not just for QA. Developers should run smoke tests locally before pushing code. This catches broken builds before they reach the CI pipeline.

Tip 3: Include infrastructure checks. The application might work perfectly, but if the database is down, the CDN is misconfigured, or the SSL certificate has expired, nothing works. Include basic infrastructure health checks in your smoke suite.

Key Takeaways

  • Smoke testing is a quick, broad health check to determine if a build is stable
  • Include only the most critical functionality (5-20 tests, under 10 minutes)
  • Automate smoke tests and integrate them into CI/CD as the first quality gate
  • Run smoke tests on every build — they are the safety net against broken deployments
  • Different applications (web, mobile, API) need different smoke test compositions
  • Maintain smoke tests aggressively — flaky or ignored tests are worse than no tests