In this guide
A smoke test answers one question: is this build worth anyone's time? It is a fast gate, not a full test. If one check fails, stop, fix and make a new build. Do not send a build to testers that crashes on launch.
Run it on one real device, on the build file you are about to share (not a debug run from your IDE).
Template (copy and paste)
SMOKE TEST: <app name> build <number> Date: <date>
Device / OS: <device, version> Tester: <name>
Stop at the first failure.
[ ] 1. Installs cleanly (fresh install, not an update)
[ ] 2. Launches without a crash or a blank screen
[ ] 3. Version and build number shown are the expected ones
[ ] 4. Main screen loads with real or test data
[ ] 5. Sign-up or login works (test account)
[ ] 6. The one core action works end to end: <name it>
[ ] 7. Data survives closing and reopening the app
[ ] 8. Back navigation and app switching do not break the screen
[ ] 9. Offline: the app opens and shows a sensible message, no crash
[ ] 10. Release build points at the right backend / config (not test or local)
Result: PASS / FAIL (item: __ )
Notes:
Why these ten, and how to check
- Fresh install. Updates hide install problems. Check: uninstall first.
- Launch. Crashes on start are the most common build-breaking error. Check: launch twice, once cold.
- Version and build number. Catches sending the wrong file. Check: compare with your notes.
- Main screen. Empty or broken data layers show here first. Check: wait for loading to finish.
- Sign-up or login. Most testers can't proceed without it. Check: use a prepared test account.
- One core action. Proves the product's reason to exist still works. Check: name it in the template and do it once.
- Persistence. Storage bugs are costly. Check: force-close, reopen, look for your data.
- Navigation. A broken back stack frustrates at once. Check: back, Home, return.
- Offline. Real users lose signal. Check: airplane mode, then launch.
- Config. Shipping with a test server address is a classic. Check: look at the environment indicator or log, or make one request you can verify.
Example (illustrative)
SMOKE TEST: Example Notes App build 87 Date: 2026-11-04
Device / OS: Mid-range phone, Android 13 Tester: Sam
[x] 1 [x] 2 [x] 3 [x] 4 [x] 5
[ ] 6. Core action: create and save a note -> FAIL: save button does nothing
Result: FAIL (item 6). Build not shared.
How to adapt it
- Replace item 6 with your core action, and add one line if there is a second must-have (a purchase, for example).
- Keep it at ten items. If it grows past five minutes, move extras to the regression list.
- Automate later, if at all. A manual run is enough until you build often.
Related
- Hub: Mobile app testing checklist hub
- Exploratory testing charter template
- Bug severity and priority matrix
Build passes? Start free to get private, structured feedback on it.