•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
This is a working checklist, not a testing theory article. It covers 8 categories and 50 items that apply to any iOS or Android app. Use it before every release to catch failures your users will find if you don't.
According to JetBrains 2024 Developer Ecosystem Survey, 43% of mobile developers cite testing as their top productivity bottleneck. Most of that friction comes from not knowing what to test, not from testing itself. This checklist fixes that.
Every item on this checklist maps back to a workflow we automate inside our mobile app testing platform, so pre-release runs stay under an hour.
Each item is a pass/fail check. If you can't answer "yes" to an item, it's a gap in your coverage.
Does app do what it's supposed to do?
What teams miss most: The Android back button. iOS doesn't have one, so teams that test on iPhone first often forget that Android users rely on hardware/gesture back navigation. If your app doesn't handle it, users get stuck.
Does app look right and feel right?
What teams miss most: Keyboard behavior. On Android, soft keyboard pushes content up. On iOS, it overlays content. If your login form's "Submit" button sits behind keyboard, half your users can't tap it.
Is app fast enough on real hardware?
What teams miss most: Testing on mid-range devices. Your flagship phone with 12GB RAM hides performance problems that a $200 phone with 3GB RAM exposes instantly. The JetBrains survey confirms that device fragmentation is #2 mobile testing challenge after flakiness.
Is user data protected?
What teams miss most: Logging sensitive data. Developers add console.log(userToken) during debugging, forget to remove it, and token shows up in production crash reports. Always grep your codebase for logged tokens before release.
Does app work across devices your users actually have?
What teams miss most: OEM-specific rendering. Samsung's One UI adds rounded corners and modified navigation gestures. Xiaomi's MIUI changes notification behavior. A button that's tappable on a Pixel might be partially hidden on a Samsung because of OEM's status bar height difference.
One mobile team we work with found that 23% of their test failures came from device-specific rendering differences, not code changes. They caught zero of these on emulators.
Does app handle real-world network conditions?
What teams miss most: The transition from connected to disconnected. Most teams test "offline mode" by turning Wi-Fi off before opening app. But real-world scenario is losing connection mid-flow: user starts a checkout, walks into an elevator, and payment API call times out halfway through.
Does app install, update, and uninstall cleanly?
What teams miss most: Upgrade testing. Your v2.3 works perfectly on a fresh install. But a user upgrading from v2.1 hits a database migration bug that corrupts their saved data. Always test upgrade path from at least 2 previous versions.
Can everyone use app?
What teams miss most: System font scaling. When a user sets their phone to 200% text size (common for users with low vision), does your app's layout still work? Or do labels overflow their containers and overlap with other elements?
Running 50 checks manually before every release takes days. Automating them takes same checks down to hours, and you can run them on every build instead of just before release.
The items in categories 1 (functional), 2 (UI), and 5 (compatibility) are most automatable. They're user-visible actions on screen: tap this, verify that, check this text is visible, confirm this layout works.
Drizz lets you turn each checklist item into a plain English test:
The Vision AI engine runs each test on real Android and iOS devices across multiple manufacturers and OS versions. One test covers item 1 and item 5 simultaneously because it runs on Samsung, Pixel, Xiaomi, and iPhones in a single batch.
The built-in popup agent handles unpredictable system dialogs (permissions, update prompts, "rate this app") that block manual testers and crash scripted automation. Adaptive wait logic detects screen state changes instead of using hardcoded timers, so tests don't flake on slower devices.
Teams using this approach report going from 15 tests authored per month (with Appium scripts) to 200 per month (with plain English). One team covered their entire regression suite in under a week. Another went from 30% of sprint time on testing to about 10%, with tests self-healing when UI changed between releases.
The checklist tells you what to test. Automation tells you how often you can afford to test it. The answer should be "every build."
A mobile app testing checklist is a structured list of items to verify before releasing an iOS or Android app. It typically covers functional testing, UI/UX testing, performance, security, device compatibility, network handling, installation/update behavior, and accessibility. The checklist ensures consistent coverage across releases and prevents teams from missing common failure points.
At minimum, test on 3 Android manufacturers (Samsung, Pixel, and one other like Xiaomi or OnePlus), 2 iOS versions (current and previous), and 2 screen sizes per platform. This covers major rendering differences and OS-specific behaviors. Teams with larger user bases should expand to 8-12 devices based on their analytics data showing which devices their users actually have.
Yes. Functional, UI, and compatibility items (roughly 60-70% of a typical checklist) can be automated with end-to-end test automation. Security and accessibility items are partially automatable (HTTPS checks, contrast ratio scans). Performance testing requires specialized tools (Android Profiler, Xcode Instruments). Some items like "does this feel intuitive?" still require human judgment.
Keyboard behavior (keyboard covering input fields differently on iOS vs Android), OEM-specific rendering differences (Samsung vs Pixel vs Xiaomi), and upgrade path testing (upgrading from v2.1 to v2.3 instead of only testing fresh installs). These three cause more post-release bug reports than any other category.
Both serve different purposes. Emulators are fast for development-time checks. Real devices catch hardware specific issues: GPU rendering differences, thermal throttling, touch responsiveness, battery drain, and OEM skin behaviors that emulators don't simulate. For release quality testing, always include real devices.
Run full checklist before every release. Run automated subset (functional + compatibility items) on every CI build. The goal is to catch regressions within hours of introduction, not days before release when fixing them is expensive.
Related Content:
How to do mobile app testing | Test scenario examples | Test case template | Book a demo
©Drizz 2026 • All Rights Reserved
