Library Automation/ Experience-Based/ Smoke Testing
Foundational · All Levels

Smoke Testing

A quick pass to confirm the build is worth testing. Walk the most critical paths — load, navigate, submit. If smoke fails, stop and send the build back.

Grad Junior Senior Test Lead

What it is

Smoke testing is a shallow, wide test pass that checks whether the most critical functions of a build work at all. The name comes from hardware: plug in the circuit, see if it smokes. If it does, don’t do any more testing — go back and fix it.

The goal isn’t thorough testing — it’s a fast decision: is this build good enough to test? If smoke passes, deeper testing begins. If smoke fails, the build is returned immediately.

What to cover in a smoke test

  • Application launches and loads without errors
  • Core navigation works (menus, links, page transitions)
  • Primary user journeys complete end-to-end (login, main action, logout)
  • Critical integrations respond (database connects, APIs return data)
  • No crash-level errors in the browser console or server logs

Time target: 15–30 minutes maximum. If your smoke test takes longer, it’s too broad.

Real-world NZ Example: Trade Me

Imagine you're testing the latest build of the Trade Me iOS app. A smoke test suite would include:

  • Does the app open to the Home screen?
  • Can I search for "Tent"?
  • Does the "Watchlist" load my saved items?
  • Does the "Sell" button open the listing flow?
You don't test the complex auction bidding logic or international shipping calculations here — just the "vital signs."

Smoke testing in CI/CD

In modern pipelines, smoke tests are automated and run on every deployment. They gate whether a build proceeds to further testing or gets rolled back automatically. A failing smoke in CI/CD means the deploy is blocked — no human decision required.

As a tester, you should be able to identify which tests belong in the smoke suite: high value, fast to run, deterministic.

Smoke vs sanity testing

Smoke vs sanity: key differences
DimensionSmoke TestSanity Test
ScopeWide — covers the whole application shallowlyNarrow — focuses on a specific changed area
DepthShallow — happy paths onlyModerate — verifies specific functionality
When runAfter every build deploymentAfter a specific bug fix or change
GoalIs the build worth testing?Did the fix actually work?
Scripted?Usually (stable script, rerun each build)Often ad hoc (targeted at the fix)

What smoke testing doesn't cover

Smoke testing is deliberately shallow. It does not:

  • Test edge cases, error states, or boundary values
  • Validate business rules or complex logic
  • Test performance, security, or accessibility
  • Confirm all features work correctly

Common mistake: treating a passed smoke test as proof the application is ready to release. Smoke tests only confirm the build is stable enough to test further — not that it’s production-ready.

Practice this technique: Try Grad Practice 01 — Typos & wording, Grad Practice 05 — Navigation & footer.

Try It — Build a smoke test suite

A new NZ council rates portal has just been deployed to the test environment. You have 20 minutes for a smoke test before the team begins deeper testing. Which of the following tests belong in your smoke suite? Tick all that apply.