What is Smoke Testing? (And How to Automate It Effectively)

In Agile development, speed is everything.

A good test strategy for Agile teams includes an efficient smoke testing plan to shorten feedback loops and enable faster iterations.

What is Smoke Testing and Why is it Important?

The term "smoke test" actually came from shipbuilding: before launching a new vessel, shipbuilders would pump smoke into the hull to check for leaks. If smoke seeped out, the ship was clearly not ready for the sea.

In the context of software engineering, smoke testing serves the same purpose — to check if a build sea-worthy — in other words, minimally viable — before the next stages of testing.

Smoke testing is a set of critical checks that testers run before deeper testing, such as User Acceptance Testing (UAT).

The goal is to fail fast — catching obvious defects in core functionality before investing more time and resources into extensive testing.

By detecting major issues early, teams can shorten test cycles and give developers feedback as soon as possible, so they can begin fixing bugs right away. This increases overall efficiency and prevents wasted effort on unstable builds.

Smoke testing is also called “build verification test” because it verifies that the build is stable enough for further testing.

What should you include in a Smoke Testing Suite?

Your smoke test suite should only include core, business-critical functionality.

For example, in an e-commerce site, smoke tests might cover:

• View product listing
• View product page
• Add item to cart
• Completing checkout

What should you exclude from smoke testing? Non-critical user journeys such as:

• Resetting password
• Updating user profile

While these are important, they can wait until later stages of testing, such as UAT or regression testing.

Keep your smoke test suite minimal and lean, so it delivers fast feedback to developers.

When and how often should smoke testing be run?

Smoke testing should be done frequently and as early as possible:

• Manual:
  • On every update to staging or production environments
• CI/CD Pipeline:
  • On new pull requests to a staging or production branch
  • On new commits to production branch
• Scheduled Cron Job:
  • Daily or even hourly for production environments

For teams that want to be Agile, the most effective approach is to run automated smoke tests on every pull request. This prevents wasted time on manual reviews for builds that are already broken. This practice is part of a “shift-left” testing strategy—moving testing to the earliest stages of the software development life cycle (SDLC) to deliver faster feedback.

Smoke testing can also be scheduled for production (live environments) to run daily or even hourly, ensuring systems remain stable. This helps to catch downtime that may not be caused by software bugs, but due to infrastructure, network, or third party service outages.

How to automate smoke testing with UI-licious

When planning a smoke test suite, it’s tempting to rely only on API-level tests because they’re fast and lightweight — but API tests alone are not enough.

The purpose of smoke testing is to ensure that the build is minimally viable — in other words, that all critical user journeys actually work end-to-end. Even if your APIs respond correctly, issues in the UI (like broken forms, missing buttons, or layout shifts) can still block users from completing essential tasks.

That’s why end-to-end UI tests should be part of your smoke testing strategy. They give you confidence that the entire system — from frontend to backend — works together in the way users expect.

With UI-licious, it is easy to setup smoke testing for critical user journeys - whether you're building an e-commerce platform or a SaaS product.

Our low-code test framework allows you to define automated UI tests using plain syntax (I.goTo, I.click, I.fill, I.see) and target elements using human-facing labels, instead of complex and unstable CSS or XPATH selectors. This makes your smoke tests readable and easy for your team to understand and maintain.

Here’s an example of a simple login test for the startup news site Hacker News:

// Login to hackernews
I.goTo("https://news.ycombinator.com/")
I.click("login")

// Fill login form and submit
I.see("Login")
I.fill("username", "PlayfulScribe")
I.fill("password", "PlayfulScribePwd")
I.click("login")

// Redirected back to news feed, verify username is displayed
I.amAt("https://news.ycombinator.com/news")
I.see("PlayfulScribe")

You can run the test directly on our integrated cross browser testing grid, with screenshots automatically captured at every step to show you exactly what your users see:

Once you have written the scripts for your smoke test suite, you can setup scheduled jobs to run tests to monitor production environments on a daily or even hourly basis, and configure alerts to notify your team when any test fails.

You can also integrate the tests into your CI pipeline to run automatically on pull requests using our Command Line Interface.

Just like shipbuilders once used smoke to ensure their vessels were watertight, smoke testing helps Agile teams confirm their builds are stable and minimally viable before sailing into longer test cycles.

By automating smoke tests with UI-licious, you can shift left, accelerate feedback, and move fast without breaking things — so your team can truly ship with confidence.

FAQs about Smoke Testing

How is smoke testing different from regression testing?

Smoke tests are small and fast, focusing on critical functionality. Regression tests are large and comprehensive, checking that all existing features still work after changes.

Can smoke testing be done manually?

Yes, especially in small projects. But as systems grow, automating smoke tests is more reliable and saves time.

How long should smoke tests take?

A smoke test suite should run in just a few minutes. If it takes too long, it’s too large and should be trimmed down.

Who does smoke testing?

Both developers and testers can run smoke tests. Developers often run automated smoke tests before handing builds over to QA.