What is smoke testing?

Smoke testing is a quick check of the most important parts of a new build, such as starting the app, logging in and completing the main journeys, to decide whether the build is stable enough for further testing. It is sometimes called build verification testing.

What is sanity testing?

Sanity testing is a short, focused check after a bug fix or small change. It confirms that the fix works and that nothing right next to it broke, without re-running the whole test suite.

What is the difference between smoke and sanity testing?

Smoke testing is broad and shallow: it looks at the most important features of a new build. Sanity testing is narrow and a little deeper: it looks only at a specific change and what surrounds it. Smoke usually comes first on a new build; sanity follows fixes.

How is smoke testing different from regression testing?

Smoke testing takes minutes and only checks that the build is usable. Regression testing is much wider and checks that everything that worked before still works. A build that fails smoke testing doesn’t go on to regression testing.

How long does a smoke test take?

It depends on your product, but a good smoke suite is deliberately short. Automated smoke suites usually finish in minutes, and manual checklists are designed to be run quickly. We agree the target with you and keep the suite lean.

Should smoke tests be manual or automated?

Both have a place. Stable, repeatable checks are best automated in your pipeline, so they run on every build. Fast-changing screens, new features and visual checks are often better done by a person with a short checklist.

Can you add smoke tests to our CI/CD pipeline?

Yes. We write smoke suites in tools such as Playwright, Selenium, Cypress, Appium and Postman with Newman, and run them in GitHub Actions, Jenkins or your own CI so a broken build is stopped automatically.

Do you test in production?

Yes, carefully. After a release we run safe, agreed checks in production using test accounts, and avoid anything that would affect real customers or data.

Can you smoke test mobile builds before store submission?

Yes. We install TestFlight and Google Play testing-track builds on real devices and check install, update, first launch, login, permissions and key journeys before you submit.

What is in a go / no-go report?

A short summary of what was checked, what passed and failed, any open issues with their impact, and a clear recommendation: go, go with known issues, or no-go.

Can you cover releases outside our working hours?

Yes. We plan release windows with you in advance, including evenings, weekends and other time zones, and stay in touch with your on-call engineers during the release.

What do you need from us to start?

Access to a test environment, test accounts, your release process and a short walkthrough of the journeys that matter most. If you already have checklists or automated tests, we start from those.

Can smoke testing replace full testing?

No. Smoke and sanity testing catch the biggest problems quickly, but they are not designed to find every bug. They work best alongside regression, functional and exploratory testing.

How do we get started?

Book a call or send the form on this page. We start with a free one-week proof of concept: we agree your critical paths, write the first smoke checklist and run it on your next builds.

Smoke & Sanity Testing Services

Before anyone spends a day testing a new build, or a customer sees a hotfix, someone should check that the basics still work.

We run that check for you. Smoke tests on every new build, sanity checks after every fix and safe post-deployment checks in production, manual, automated in your pipeline or both, with a clear go or no-go each time.

Get in touch Build your smoke suite

Every build, every fix
Manual or automated
Go / no-go reports
Free one-week POC

What we do

Build verificationEvery build Sanity checksAfter every fix Post-deployment checksLive Automated smoke suitesOn every commit Manual smoke checklistsHuman eyes Mobile store build checksiOS & Android API smoke checksBehind the screens Release go / no-go reportsClear decisions Out-of-hours and time-zone coverWhen you release

[ Why smoke & sanity testing ]

The cheapest bug is the one you catch in the first ten minutes

A missing setting, a failed migration or one bad merge can break login for everyone. If nobody checks, testers lose a day before they notice, or customers notice first. Smoke and sanity testing are short, deliberate checks that answer one question quickly: is this build, fix or release safe to go further? They don’t replace full testing. They make sure full testing starts on something worth testing.

Need wider coverage too? See manual testing and regression testing →

Broken builds stopped early

Minutes of checking can save a day of wasted testing or an embarrassing release.

Fixes you can trust

Every fix checked, along with the things right next to it.

Confident releases

A clear go or no-go based on evidence, not gut feeling.

Fits your release rhythm

Manual, automated or both, run whenever and wherever you release.

[ What we test ]

Nine ways we keep builds and releases safe

From the first build in QA to the minutes after a production release. Each one lists what we check, when you need it and the problem it prevents.

Build verification (smoke) on every new build

Every build

A short, fixed set of checks on the most important parts of your product, run as soon as a new build lands, so nobody wastes a day testing something that was broken from the start.

What we check

The app or site loads, installs and starts without errors
Login, main navigation and key pages work
Your most important journeys complete on the happy path
No crashes, blank screens or failed core API calls

When you need it

On every build that reaches QA or staging.

The problem it preventsA full test cycle wasted on a broken build

Sanity checks after bug fixes and hotfixes

After every fix

A focused check that a fix really works, and that it hasn’t broken the screens, data or rules right next to it.

What we check

The reported bug retested with the original steps
Nearby screens, fields and business rules checked
Data and permissions touched by the change
A clear “fixed” or “reopen” with evidence

When you need it

After each fix, and before any hotfix goes to production.

The problem it preventsA hotfix that fixes one bug and creates two more

Post-deployment checks in production

Live

Safe, read-mostly checks in production straight after a release, using test accounts, so you know the release worked for real users.

What we check

Health checks, key pages and logins on the live site or app
Test-account journeys that don’t affect real customers
Payments in test mode or agreed small transactions
Error rates and monitoring dashboards after the release

When you need it

Straight after every production release, and after infrastructure changes.

The problem it preventsA release that passed staging but fails in production

Automated smoke suites in CI/CD

On every commit

View service

Your smoke checks written as fast automated tests that run in your pipeline, so a broken build is stopped before anyone sees it.

What we check

Smoke suite in Playwright, Selenium, Cypress or Appium
API smoke checks with Postman and Newman
Runs in GitHub Actions, Jenkins or your CI on every build
Clear pass or fail with screenshots and logs

When you need it

When you release often and want fast, repeatable checks.

The problem it preventsBroken builds reaching QA, staging or customers

Manual smoke checklists

Human eyes

A short, written checklist your team or ours can run in minutes, for the parts that are hard to automate or change too often.

What we check

Checklists built from your critical journeys
Plain steps anyone on the team can follow
Kept short, current and reviewed each release
Results recorded in your test management tool

When you need it

For new products, fast-changing UI and anything not yet automated.

The problem it preventsDifferent people checking different things on each build

Smoke tests for mobile store builds

iOS & Android

View service

Quick checks on the exact build you are about to submit to the App Store or Google Play, on real devices.

What we check

TestFlight and Play testing-track builds installed on real devices
Install, update over the previous version and first launch
Login, permissions, push notifications and key journeys
Crash-free start-up on older and newer devices

When you need it

Before every store submission and staged rollout.

The problem it preventsSubmitting a build that crashes on launch

API smoke checks

Behind the screens

View service

A handful of fast calls that confirm your core APIs are up, secure and returning the right shape of data.

What we check

Health endpoints and core read and write calls
Authentication and token refresh
Status codes and response structure
Key third-party integrations reachable

When you need it

On every deploy of a service, and before UI testing starts.

The problem it preventsEvery screen failing because one service is down

Release go / no-go reports

Clear decisions

A one-page summary after each smoke or sanity run that tells you, in plain words, whether to go ahead.

What we check

Pass, fail and blocked checks at a glance
Open issues with severity and impact
A clear go, go with known issues, or no-go recommendation
Shared in Slack, email or your release ticket

When you need it

Before every release decision.

The problem it preventsReleasing on gut feeling, or holding a release with no clear reason

Out-of-hours and time-zone cover

When you release

Testers available when your releases actually happen, including evenings, weekends and other time zones, agreed in advance.

What we check

Release windows planned with you ahead of time
Smoke and post-deploy checks during the window
Direct line to your on-call engineers
Hand-over notes for the next team

When you need it

For night-time or weekend releases, and teams spread across time zones.

The problem it preventsReleases going out with nobody checking them

[ Smoke vs sanity vs regression ]

Three checks, three different questions

They are often confused. Here is how they differ, and what a go / no-go report looks like at the end.

	Question it answers	Scope	When	Typical time
Smoke testing	Is this build stable enough to test?	Broad and shallow: the most important features	Every new build	Minutes
Sanity testing	Did this fix or small change work?	Narrow and deeper: the change and what is next to it	After fixes and hotfixes	Minutes to an hour
Regression testing	Did anything that worked before break?	Broad and deep: everything that matters	Before a release	Hours to days

Sample go / no-go reportGo with known issue

Release: Web app 4.12.0 · production
Smoke: 24 of 25 checks passed
Failed: Export to PDF times out for large reports
Impact: Medium · workaround: export as CSV
Sanity: 3 of 3 fixes verified
Post-deploy: Errors and response times normal

Example only. Real reports go to your release channel.

[ How we work ]

Six steps to a smoke suite that stays short and useful

You decide what “critical” means. We turn it into checks that run on every build and a report you can act on.

Step 1 of 6
Find your critical paths

The journeys that, if broken, stop users or revenue, agreed with your team.

You getCritical path list
Step 2 of 6
Write the checks

Short smoke and sanity checklists, with test accounts and data ready.

You getSmoke checklistSanity scope
Step 3 of 6
Automate what repeats

Stable checks moved into your pipeline; the rest stay manual.

You getAutomated smoke suite
Step 4 of 6
Run on every build

Smoke on each new build, sanity after each fix, post-deploy after each release.

You getRun results in your tools
Step 5 of 6
Report go or no-go

A short, clear summary to the people making the release call.

You getGo / no-go report
Step 6 of 6
Keep it lean

Checks reviewed every few releases so the suite stays short and useful.

You getUpdated checklist

Free one-week POCWe agree your critical paths, write the first smoke checklist and run it on your next builds.
Turnaround agreed up frontWe agree how quickly results are needed for each build and release window, in writing.
Safe in productionTest accounts and agreed checks only. Nothing that touches real customers or data.

[ Tools ]