What is Smoke Testing?
Smoke testing covers the major functions of software but none in depth. The result of this test determines whether to proceed with further testing. If the smoke test passes, continue with detailed testing. If it fails, halt further tests and request a new build with the required fixes.
The term originates from hardware testing—if you power on a device and smoke comes out, you know something is fundamentally wrong without needing detailed diagnostics.
Goals of smoke testing
- Detect critical defects early — catch fundamental failures before investing in comprehensive testing
- Verify build stability — ensure the build is testable before assigning it to the full QA team
- Demonstrate core functionality — confirm that primary features work at a basic level
- Save testing resources — avoid wasting time on broken builds that need to go back to development
What smoke tests cover
Smoke tests typically verify:
- Application launch — does the software start without crashing?
- Critical user paths — can users complete core workflows?
- Key integrations — do essential external connections work?
- Database connectivity — can the application read and write data?
- Authentication — can users log in?
Smoke testing vs other testing types
| Smoke Testing | Regression Testing |
|---|---|
| Shallow, breadth-first | Deep, comprehensive |
| Run on every build | Run before releases |
| Minutes to complete | Hours to days |
| Verifies testability | Verifies correctness |
Smoke testing in CI/CD
Modern development practices automate smoke testing as part of continuous integration. When code is committed:
- The build system compiles the application
- Smoke tests run automatically
- If smoke tests pass, detailed testing begins
- If smoke tests fail, the build is rejected immediately
This fast feedback loop prevents broken builds from wasting QA resources and keeps the main branch in a deployable state.
See also: Regression Testing, Integration Testing, Continuous Integration