Smoke Testing: Sanity Checks for Deployments and Releases

Smoke testing is a rapid verification process that checks whether the most critical functions of an application work before investing time in deeper testing, acting as a gatekeeper for deployments and releases.

What You'll Learn

In this tutorial, you'll learn smoke testing techniques for deployment verification, how to build automated smoke test suites, identify critical paths, and integrate smoke tests into your CI/CD pipeline for instant feedback.

Why This Matters

A deployment that breaks the login page affects every user immediately. Smoke tests catch these show-stopping failures in seconds, before any user sees them. At DodaTech, DodaZIP runs a 12-second smoke suite before every deployment — verifying that file compression, extraction, and the user interface all respond correctly before the release goes live.

Learning Path

flowchart LR
  A[Testing Basics] --> B[Smoke Testing
You are here]
  B --> C[Critical Path Testing]
  B --> D[Build Verification Tests]
  C --> E[CI/CD Pipeline Integration]
  D --> E
  style B fill:#f90,color:#fff

What Smoke Testing Covers

Smoke tests verify the health of an application. They do not test edge cases, validate business logic, or check every button. They answer one question: "Does the application start and respond correctly?"

Core smoke test areas:

• Application starts without errors
• Database connection is working
• Main page loads successfully
• Login and authentication work
• Key API endpoints respond

Build Verification Test (BVT) Example

A BVT is a smoke test run immediately after a build to decide whether the build is good enough for further testing.

# smoke_tests.py
import requests
import sys

BASE_URL = "https://staging.example.com"

def test_homepage_loads():
    response = requests.get(f"{BASE_URL}/", timeout=5)
    assert response.status_code == 200
    assert "Welcome" in response.text
    print("PASS: Homepage loads")

def test_login_page():
    response = requests.get(f"{BASE_URL}/login", timeout=5)
    assert response.status_code == 200
    assert "Sign in" in response.text
    print("PASS: Login page loads")

def test_api_health():
    response = requests.get(f"{BASE_URL}/api/health", timeout=5)
    data = response.json()
    assert data["status"] == "healthy"
    assert data["database"] == "connected"
    print("PASS: API health check")

if __name__ == "__main__":
    tests = [test_homepage_loads, test_login_page, test_api_health]
    for test in tests:
        try:
            test()
        except Exception as e:
            print(f"FAIL: {test.__name__} - {e}")
            sys.exit(1)
    print("All smoke tests passed")

Expected output:

PASS: Homepage loads
PASS: Login page loads
PASS: API health check
All smoke tests passed

Critical Path Smoke Testing

Critical paths are the user workflows that must work for the application to be useful. A smoke test for an e-commerce site might cover:

def test_product_search():
    response = requests.get(
        f"{BASE_URL}/search?q=wireless+mouse",
        timeout=5
    )
    assert response.status_code == 200
    items = response.json()
    assert len(items) > 0
    print("PASS: Product search returns results")

def test_add_to_cart():
    session = requests.Session()
    session.get(f"{BASE_URL}/products/123")
    response = session.post(
        f"{BASE_URL}/cart/add",
        json={"product_id": 123, "quantity": 1}
    )
    assert response.status_code == 200
    assert response.json()["cart_count"] == 1
    print("PASS: Add to cart works")

def test_checkout_flow():
    session = requests.Session()
    session.post(f"{BASE_URL}/cart/add", json={"product_id": 123, "quantity": 1})
    response = session.post(f"{BASE_URL}/checkout", json={
        "shipping_address": {"street": "123 Main St"},
        "payment_method": "card"
    })
    assert response.status_code == 200
    assert "order_id" in response.json()
    print("PASS: Checkout flow completes")

Expected output:

PASS: Product search returns results
PASS: Add to cart works
PASS: Checkout flow completes

CI/CD Integration

Smoke tests run in the deployment pipeline after the build and before the full regression suite. This saves time by failing fast on broken deployments.

# .github/workflows/deploy.yml
name: Deploy with Smoke Tests
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build application
        run: docker build -t app:${{ github.sha }} .
      - name: Deploy to staging
        run: docker compose up -d
      - name: Run smoke tests
        run: |
          sleep 10  # Wait for app to start
          python smoke_tests.py
      - name: Deploy to production
        if: success()
        run: ./deploy-production.sh

Expected CI pipeline output:

Build application ....................... (pass)
Deploy to staging ....................... (pass)
Run smoke tests ......................... (pass)
Starting full regression suite .......... (skipped - smoke failed)
Deploy to production .................... (pass)

Build vs Smoke vs Sanity Testing

Sample Smoke Test Suite Structure

Common Errors

1. Making Smoke Tests Too Deep

Smoke tests should take seconds, not minutes. If a smoke test takes 30 minutes, it's an integration test. Keep them shallow and fast.

2. Testing Non-Critical Paths

Every smoke test should test a path that would cause a user-facing outage if broken. Testing an admin report generator is not a smoke test.

3. Hardcoding URLs and Credentials

Hardcoded values break when environments change. Use environment variables for URLs, API keys, and test credentials.

4. Not Running Smoke Tests in CI

Manual smoke tests are skipped under deadline pressure. Automate them in the deployment pipeline so they always run.

5. No Rollback on Smoke Test Failure

A smoke test that fails should automatically trigger a rollback. If it just sends an email, the broken deployment stays live.

Practice Questions

1. What is the purpose of a smoke test? To quickly verify that the most critical functions of an application work before investing time in deeper testing. It acts as a gatekeeper for deployments.

2. How is a smoke test different from a regression test? Smoke tests are shallow and fast (5-15 minutes) and test only critical paths. Regression tests are comprehensive and can take hours to verify all functionality.

3. What happens when a smoke test fails in CI? The deployment pipeline should stop, notify the team, and optionally trigger an automatic rollback to the previous version.

4. What is a Build Verification Test (BVT)? A BVT is a smoke test run immediately after a build to decide if the build is good enough for further testing. It's the first gate in the testing pipeline.

5. How do you choose what to include in a smoke test? Include only the paths that would cause a user-facing outage if broken: homepage, login, core API endpoints, database connectivity, and the primary user workflow.

Challenge: Write a smoke test suite for a REST API with five endpoints. Include database connectivity check, authentication flow, and two critical business operations. Make the tests environment-aware using environment variables.

Real-World Task: E-Commerce Deployment Smoke Suite

Build a smoke test suite for an e-commerce application that covers:

1. Homepage loads correctly
2. Product search returns results
3. Cart operations work
4. Checkout initializes
5. Admin login works

Integrate it into a CI/CD pipeline that deploys to a staging environment, runs the smoke tests, and only promotes to production if all pass. Add automatic rollback if any smoke test fails.

FAQ

What's Next

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.