Key takeaways
- Boundary testing on mobile is not just input field validation. Device class, OS version, storage, network state, and permission transitions are all boundaries where mobile apps break.
- Web QA has three boundaries to worry about. Mobile has ten. If your boundary testing plan looks like a web plan with "run on iOS and Android" bolted on, you're covering maybe 30% of surface.
- The failures at these boundaries usually don't show up in staging. They show up in production, on your worst-supported device, when a real user has 500MB of free storage and one bar of 3G. That's point.
Boundary testing on mobile means checking how app behaves at limits of its inputs, its runtime environment, and its supported device matrix. Not just "what happens when user enters 256 characters in a field." Also: what happens on smallest phone you support, on oldest OS you claim to support, with storage nearly full, on a spotty connection, after permissions get revoked mid-flow.
Web QA barely thinks about most of these because web abstracts them away. Mobile can't.
Here's what actually breaks in production, why, and what to test.
What is boundary testing (fast version)
Boundary testing is a technique where you deliberately push app to edge of its accepted inputs, states, or environments and see what happens. The idea is old and simple. Bugs cluster at boundaries. The middle of a range usually works. The edges usually don't.
Classic boundary value analysis focused on numeric inputs. A field accepts 1 to 100. You test 0, 1, 100, 101. If any of them break, you found a boundary bug. Simple.
Classic input boundaries are one slice of boundary testing. Device and OS boundaries are mobile-specific slice, and they're what this post is about. If you want full BVA and equivalence partitioning refresher, that link has it.
The mobile boundary categories web QA doesn't have
Six categories. Each one hides bugs. Each one shows up in production reviews as one-star complaints if you skip it.
Device boundaries
Your minimum supported device is your smallest boundary. If you claim Android 10 and above, you also implicitly claim Samsung Galaxy A03 with 2GB of RAM, and someone's phone that's been running for 47 days without a restart. That's your boundary. Test there.
The opposite end. Largest tablet you support. Widest screen. Highest DPI. Some layouts break on iPhone 15 Pro Max because they were designed on a 14 and padding math falls apart at 6.7 inches.
Foldables are their own thing. Continuity between folded and unfolded states. Multi-window mode on Android tablets. Split view on iPad. Each transition is a boundary. Your test at maximum layout probably passes. The transition from folded to unfolded is where OnConfigurationChanged handling breaks and you lose state.
Real cases from apps we've watched:
- A fitness app dropped a workout mid-session when user unfolded a Z Fold. The activity recreated. The workout state wasn't marshaled through bundle. The user tried to sync a broken session to Strava.
- A ticket booking app rendered seat picker off-screen on iPhone SE 3rd gen because layout assumed a minimum height of 750pt.
Device fragmentation forces a broader take on boundary testing than most web QA teams need. Every device app runs on is a boundary in some category, and you can't cover them all without a strategy for which ones matter.
OS version boundaries
You support Android 10 through 14. That's five major versions. Each has its own permission model, its own background execution rules, its own JobScheduler quirks. Test minimum. Test newest. Test one in middle for good measure.
iOS is easier because Apple deprecates old versions faster, but you still have iOS 15 to iOS 18. Same principle.
The trap here is what changed at each boundary. Android 13 introduced granular media permissions. Android 14 tightened background broadcasts. iOS 17 changed universal link behavior for certain domains. Your app might have gotten a fix for one boundary that broke behavior on another. Regression at boundaries, not middle. Google's Android testing documentation has specific behavior changes at each API level if you need exhaustive list.
Real devices expose boundary testing gaps that emulators quietly hide. An emulator running Android 10 is not same as a Samsung Galaxy A13 running Samsung's fork of Android 10 with Samsung Keyboard and Samsung Push. The API level is same. The behavior isn't.
Storage and memory boundaries
This is one everyone skips.
Free storage on device. Test at 100GB free, 5GB free, 500MB free, 50MB free. Below 500MB is where apps start failing in interesting ways. Uploads fail silently. Cached images don't persist. Room writes throw SQLiteFullException. Core Data raises NSFileWriteOutOfSpaceError.
Available memory. Test with your app as only foreground process. Then test with 20 other apps in memory competing for RAM. The Android LMKD kills your background service. Your ViewModel loses state. Your test suite that ran green on a fresh emulator dies on a real Pixel 4a with 15 Chrome tabs open.
Cache size limits. If your app caches aggressively, what happens when cache hits its ceiling. Does eviction work. Does app crash on cold start because a required cached asset was evicted. This is where CDN fallback that only works when primary asset is missing gets exercised.
Network state boundaries
Fast Wi-Fi to no Wi-Fi. Wi-Fi to 4G handoff mid-upload. 4G to 3G. LTE to Edge (yes, that still happens). Airplane mode toggle mid-request.
The transitions are boundary. Your test on a stable connection passes. Your test on no connection probably passes because you have an offline banner. Your test where connection dropped exactly during "Pay now" tap is where double-charge bug lives.
Also boundaries: slow but not lost connection. A 3G connection with 400ms latency and 80% packet loss is worse than no connection because app thinks it's online but every request times out. Your Retrofit calls throw SocketTimeoutException. Your test suite probably didn't cover that specific state.
Battery and thermal boundaries
Low Power Mode on iOS kicks in at 20%. Behavior changes. Background refresh stops. Some animations disable. The user opens your app while their phone is at 15% and half your polish is gone.
Android's Battery Saver has similar effects and worse variability across OEMs. Samsung's Ultra Power Saving Mode disables most background activity. If your app relies on periodic sync to look up-to-date, it looks broken.
Thermal throttling. When CPU throttles at 80°C, your onboarding animation drops from 60fps to 20fps. It looks like your app is broken. It's actually your app doing exactly what OS is telling it to do. Users don't care.
Data volume boundaries
Zero. One. Many. Too many.
An empty state on home screen for a new user. Does it render or does ListView crash trying to bind to null. Test at zero items.
One item. Does "You have 1 items" grammar look stupid. Does swipe-to-dismiss work with just one card. Does pagination logic assume more than one page.
Many. 100 items. 1000 items. Does FlatList lag. Does RecyclerView leak. Does infinite scroll actually work past page 20.
Too many. What's your ceiling. If a user has 10,000 saved recipes, does app OOM on startup because you're loading everything into memory. Set an explicit ceiling and test right below and right above it.
Session and permission boundaries
Permission granted at install. User grants location during onboarding. Everything works. Two months later they revoke it from Settings. They come back to app. Boundary crossed. Does app crash. Does it prompt again. Does it silently fail. All three are shipped bugs we've seen.
Session tokens expiring mid-flow. You start checkout with a valid token. Payment takes 8 seconds. Token expires during payment. The 401 comes back. What do you do. Retry silently? Force re-login? Lose cart? All three answers are correct for different apps. Whatever answer, test it, because if you don't decide, framework will decide for you and it'll be wrong one.
Upgrade from an old version. Someone had your app installed since 2023. They open it after 8 months and it's now v6.4. The Room migration path from v2.1 to v6.4 has to actually work. On a device with 500MB free. On Android 10. All at once. Test compound boundary, not isolated ones.
Which boundaries to actually prioritize
You can't test all of these thoroughly. Nobody has that many devices, that much CI time, or that many QA hours.
Prioritize by:
- Where users are. Look at your analytics. Your P95 device is what matters. Not newest Pixel. The device 95% of your users have or worse. That's floor.
- Where risk is. Payments and auth are boundaries that cost real money when they break. Test those hardest.
- What changed. If v6.4 rewrote storage layer, test storage boundaries this release, not layout boundaries.
A reasonable release checklist might be: min-supported device × min-supported OS × three network conditions × two storage states, on payment and login flows only. That's 24 test runs. Do it well and skip other 200 boundary combos that would slow you down for marginal coverage.
Where automated boundary testing fails
Boundary tests multiply flakiness problem because they're already running on edge conditions where app itself is less stable.
Selector-based frameworks (Appium, XCUITest, Espresso) add their own layer of edge failure. Your test runs on a Pixel 4a with 500MB free. The device is slow. The animation takes 400ms longer than it did on M2 Mac emulator. Your Appium wait times out. Your test reports a boundary failure. There's no boundary failure. The device is just slow. You spend an afternoon debugging what turns out to be explicitlyWait(5).until(...) needing to be explicitlyWait(15).until(...).
Multiply that by every boundary condition you're actually testing. Add cross-device runs. Add flaky selectors on top of flaky boundaries. Your regression suite is 62% pass rate and nobody trusts what it's actually catching.
What works for mobile boundary testing at scale
Drizz's Vision AI reads screen way a person would. When test runs on a Pixel 4a with animation taking longer, Vision AI waits until it actually sees confirmation text on screen. Adaptive wait, based on what's rendered. Not a hardcoded timer. Not a locator waiting for an accessibility ID that might be delayed.
Same test. Same plain English. Tap "Pay now". Validate "Order confirmed" is visible. Runs on your fastest device and your slowest device, on Android 10 and 14, on a device with plenty of storage and a device with 400MB free. The test doesn't need per-device tuning because it's not synchronized to selectors or fixed timers.
Concrete before-and-after on "checkout with 400MB free storage on a Pixel 4a running Android 11" boundary case.
Before, on Appium: Test runs 40% of time because animation takes longer than explicit wait, throws NoSuchElementException, and reruns don't help because timing is inconsistent. Team disables low-storage boundary test after two sprints. Silently. Then a shipped bug shows up in Play Store reviews: "app crashes when I try to pay."
After, on Drizz: Same test, plain English. Runs on real devices in CI. Adaptive wait handles slow render. Pass rate 96%. The 4% failures are real product bugs, not timing bugs.
That's actual value at boundary testing scale. The framework stops being an obstacle to what you're actually trying to test.
FAQ
What is boundary testing in mobile?
Testing how app behaves at edges of inputs, devices, OS versions, storage, network, and permissions.
How is mobile boundary testing different from web?
Mobile adds device class, OS version, storage, memory, battery, and permission boundaries. Web only really has input and browser boundaries.
What are most common boundary bugs in mobile apps?
Storage-full failures, session token expiry mid-flow, permission revocation, low-memory OOM crashes, and layout breakage on smallest supported device.
Should boundary tests run on emulators or real devices?
Real devices for anything involving storage, memory, network, or battery. Emulators hide too many hardware-specific behaviors.
How do I prioritize which boundaries to test?
Start with your P95 device, minimum OS, and highest-risk flows like payment and login. Skip rest.
Can boundary tests be automated?
Yes, but selector-based frameworks flake at boundary conditions because timing shifts. Vision-based tools handle timing variance better.
