Key takeaways
- Sanity testing is a fast spot-check after a small fix. Twenty minutes, not four hours. If yours takes four hours it's not sanity anymore.
- On mobile you have to cover install path, cold start, deep links, and permission state. Web QA checklists skip all of that.
- Manual sanity gets skipped when release is late. Every time. If you can't automate it in a way that survives UI changes, you'll ship without running it.
Sanity testing is a fast, targeted check you run after a small code change to confirm fix works and didn't break anything obvious next to it. Nothing more. If your address autocomplete broke on iOS and someone patched it at 4:45pm, you don't run 400 test cases before 6pm release. You run five. Maybe six.
Here's annoying thing. Most teams call this sanity but don't run it that way. Their "sanity pass" ballooned into some 80-case manual gauntlet that eats an afternoon. That's not sanity. That's a shitty regression subset that isn't tracked properly and everyone pretends is fine.
Let me back up.
What it is (short version)
Sanity testing is a subset of regression. Narrow scope. Deep on one thing.
You patched a bug. You changed a copy string. You bumped a config value. Now you want to know if specific thing you touched works, and if things immediately adjacent to it still work. That's whole job.
The ISTQB glossary frames it as a targeted subset of tests, run after a change, that decides whether build is worth further testing. Fine. That's textbook version.
The version that actually matters for your Monday morning is this. After every fix, ask one question. Can I verify this in under an hour without opening a dozen tabs and setting up test data from scratch. If yes, sanity. If no, don't call it sanity. Call it what it is. Targeted regression.
Sanity testing vs smoke testing
These get confused constantly. Which is dumb because they answer different questions.
Smoke asks: is build even usable. Does APK install. Does app open without a crash. Does login work. Can I get past home screen. That's smoke. It runs first, on any new build, before anyone else touches it.
Sanity runs after smoke passed. Build is fine. You just changed one specific thing and you want to prove that specific thing works. That's it.
If you want deeper split between two, our smoke vs sanity breakdown has more on where each fits in a release cycle.
When to run sanity testing
Three questions. All yes, run it.
Did you change one specific thing. Bug fix. One screen. One config value. One copy string. Yes means yes. If "one thing" was a refactor that also touched three other modules, that's a no.
Is build stable. Smoke green. Login works. App doesn't crash on cold start. If smoke is red, don't waste your afternoon on sanity, that's wrong problem to be solving.
Do you have less than an hour before ship. This is part that trips people up. Sanity is fundamentally a time-budget test. If you had time for full regression you'd run full regression. You're running sanity because you don't.
Real cases from last couple of years:
- Address autocomplete stopped returning results on iOS 17.4. Backend patch. Sanity scope: address entry, checkout, one deep link that lands on address entry. 22 minutes on a physical Pixel 8 and an iPhone 15.
- Push notification permission prompt firing twice on first launch. Sanity scope: fresh install, first launch, permission flow. Not even login. 12 minutes.
- Payment method dropdown showing expired cards. UI-only fix, no backend touch. Sanity scope: card list, add card, remove card, one full checkout. 30 minutes.
Payment-adjacent fixes are classic case. Our in-app purchase testing guide breaks down what should be in that pass by store and platform. Receipt state alone catches a surprising number of shipped bugs. If you want broader mobile scope by tier, mobile app testing checklist has sanity sitting right between smoke and regression on same list.
The mobile stuff web QA doesn't have to think about
Web sanity is easy. Reload page. Click button. See if thing works. Done.
Mobile has five extra surfaces where same fix can break, and if you don't test them, you'll ship "works on my device" bugs. Which are worst kind. Because tester will insist it was fine.
Install path. Fresh install vs OTA upgrade from previous version. Different code paths entirely. I've watched more than one fix pass fresh case and blow up on upgrade because local Room migration didn't get memo. Or Core Data threw NSInvalidArgumentException because a field went nullable in v3.2.1 and migration didn't handle it.
State transitions. Cold start. Warm start. Background 30 seconds and foreground. Background 4 hours and foreground. If your fix touched anything cached, you need both cold cache and stale cache paths.
Deep link entry. If fixed screen is reachable via URL scheme or universal link, launch it that way. About half time behavior is different from launching via app icon. That's not a made-up number. That's from actually checking on ten different apps over about a year.
Notification tap. Same idea. Tap push from a locked screen. Then from an unlocked screen. Then from notification center. Three paths, three states, sometimes three different bugs.
Permission states. Granted. Denied. Granted-then-revoked mid-flow. On Android specifically that last one is where teams get burned, because app doesn't handle SecurityException properly and just crashes. iOS is slightly nicer about this but not much.
Skip these and you're testing a mobile app like it's a web app. Users find your gaps in Play Store reviews.
When you should not run sanity
This is section every other post skips.
If change touched more than one module, it's not sanity anymore. Run a proper regression subset. Stop calling everything sanity because it makes you feel busy.
If smoke failed, don't run sanity. You're stacking checks on a broken build. Fix build first.
If full regression is going to finish before you'd be done with sanity, skip sanity. Doing both is duplicated work.
If fix is behind a feature flag that's off in production, there's nothing to verify. No user hits that code path. Skip it.
If your "sanity" scope has 200 test cases, you don't have a sanity suite. You have a shadow regression suite you've been calling sanity because "sanity" sounds lighter than "targeted regression before release." Cut it. Name it correctly.
That last one is most common trap and honestly one that does most damage. Sanity creeps. A team starts with 5 checks after every fix. Then one fix broke something adjacent that wasn't in scope, so they add checks for adjacent stuff. Then adjacent-to-adjacent. Six months in "quick sanity pass before release" means four hours of two people clicking through flows. Nobody decided this. It just happened. And now it's untracked, unmaintained, un-automatable because half steps live in someone's head.
If any of that sounds like your team, cut suite back to actual sanity. Move rest into regression where it belongs. Nobody will thank you but release cycle will get better.
Where mobile sanity testing keeps failing
Four things I see across teams, over and over.
The scope creep thing, above. Solvable if leadership will let you call it out.
Wrong device, wrong OS. Team runs sanity on a Pixel 8 with Android 14 because that's what's on desk. Fix ships. Turns out it broke on Android 12, and Android 12 is 40% of user base. This happens more than it should.
No documented scope in ticket. "Sanity for payment fix" is not scope. Scope is "checkout on Wi-Fi and 4G, saved card flow, Apple Pay on iOS, order confirmation email." Written down. In ticket. Before tester picks up build.
Manual pass under time pressure. This is one that actually matters. Every team I've worked with eventually hits a release cadence where manual sanity stops fitting schedule. What happens next is either you automate it or you skip it and hope. Skipping is worse.
Automating sanity on mobile is where wheels come off for a lot of teams. Appium, XCUITest, Espresso are all selector-based. Locators break every time design team ships new copy or renames an accessibility ID or restyles a button. Your sanity suite that was green Wednesday is red Thursday morning. Nobody wrote a new bug. The UI just moved 12px. Now team is either updating locators or arguing about whether failure is real. Both are bad ways to spend a morning.
Making it work at scale
For teams shipping weekly or faster this is where story usually ends. Sanity gets skipped because manual doesn't scale. Automated flakes. The ROI on either is bad.
We built Drizz partly for this. Instead of locators you write tests in plain English. Tap "Add to cart". Validate "Order placed" is visible. Vision AI reads screen way a person does. When payment module gets patched and confirmation screen gets a new gradient background and button label changes from "Pay" to "Confirm payment" in same sprint, test still runs. Nothing to update. No locators to fix.
Here's what workflow shift looks like on a payment fix.
Before: Fix lands at 4pm. QA lead grabs a Pixel 8 and an iPhone 15 from drawer. Runs through install, login, add card, checkout, verify receipt. Repeats on second device. About 40 minutes. Files two bugs from Android run because a copy string didn't get localized. Release goes at 6:15pm. Fifteen minutes late. Nobody's happy.
After: Same fix, same 4pm. Payment sanity suite kicks off on both devices in parallel through CI. Six minutes. Two failures come back with video and log artifacts attached. QA lead reviews, files same two bugs, hits merge. Release goes at 5:20pm.
That's not magic. Nobody's inventing time. All that changed is manual bottleneck moved out of critical path. The suite still runs. The failures still surface. QA still triages. Just faster and without three engineers staring at their phones.
Sanity testing was always supposed to be lightweight. The manual overhead on mobile made it feel heavy. Take that overhead away and practice does what textbook always said it would.
FAQ
What is sanity testing in mobile QA?
A narrow spot-check that verifies a recent bug fix or small change works, without running full regression.
When should you run sanity testing?
On a stable build after a specific, isolated fix, when full regression won't finish before release window.
When should you skip sanity testing?
Skip when change touched multiple modules, smoke is failing, or regression is already scheduled to run.
What's difference between sanity and smoke testing?
Smoke asks if build is usable. Sanity asks if a specific fix worked. Smoke first, sanity after.
How long should sanity testing take?
Under an hour. If your sanity pass takes longer, it stopped being sanity somewhere along way.
Is sanity testing usually automated?
For fast-shipping mobile teams, it has to be. Manual sanity gets skipped under deadline pressure every single time.
