Mobile App Testing Checklist

QA teams that ship mobile apps without a structured checklist miss defects that users find first. A mobile app testing checklist defines every verification step a QA team runs before release. The checklist spans 12 categories: functionality, performance, security, usability, accessibility, compatibility, and 6 more. This guide covers 12 checklist categories with specific items and pass/fail criteria for each.

What this checklist covers: 12 testing categories with 150+ items. Includes performance thresholds, WCAG 2.1 AA requirements, OWASP Mobile Top 10, and a downloadable template.

What Is a Mobile App Testing Checklist?

A mobile app testing checklist is a structured document listing every verification a QA team runs before release. A mobile app testing checklist organizes test activities by category: functional, non-functional, and platform-specific. The most important attribute is traceability. Each checklist item maps to a requirement, a test case, and a pass/fail result.

Ericsson’s Mobility Report (Q1 2026) counts 7.58 billion smartphone subscriptions worldwide. Each subscription represents a device with a specific OS version, screen size, and hardware configuration. Testing mobile apps across this fragmented landscape requires systematic coverage. The checklist provides that system.

A complete mobile app testing checklist contains 12 categories. The first 7 cover standard testing types. The remaining 5 cover scenarios most QA teams skip.

What Does the Functionality Testing Checklist Cover?

The functionality testing checklist verifies that every user flow, input field, error state, and business rule produces the expected result. Functionality testing confirms that the app does what the specification says. Failed functionality checks are the highest-severity defects.

What User Flows Does Functionality Testing Verify?

Functionality testing verifies every user flow from entry point to completion.

• Registration and login: Sign up, sign in, social login, OTP verification, forgot password, session persistence.
• Core transaction: The primary action the app exists for (order placement, booking, payment, data submission).
• Navigation: Every menu item, tab, back button, deep link, and breadcrumb reaches the correct destination.
• Search: Search returns relevant results, handles empty queries, shows “no results” state.
• Logout: Session terminates, tokens clear, re-authentication required on return.
• Onboarding: First-time user flow completes without confusion or dead ends.

What Input and Form Validations Does Functionality Testing Check?

Every input field requires validation for valid entries, invalid entries, boundary values, and empty submissions.

• Required fields: Submission blocked with clear error message when required fields are empty.
• Field length: Minimum and maximum character limits enforced.
• Data types: Email fields reject non-email formats, phone fields reject alphabetic characters, date fields reject invalid dates.
• Special characters: Fields handle emojis, Unicode, HTML tags, and SQL injection strings without breaking.
• Clipboard: Copy, paste, and cut work in all text fields.
• Keyboard: Correct keyboard type appears (numeric for phone, email for email, default for text).
• Error messages: Every invalid input produces a specific, actionable error message (not “Invalid input”).

What Does the Accessibility Testing Checklist Cover?

The accessibility testing checklist verifies WCAG 2.1 AA compliance for users with visual, motor, auditory, and cognitive disabilities. The World Health Organization estimates 1.3 billion people (16% of the global population) experience significant disability (WHO, 2024). Inaccessible apps exclude this user base.

What WCAG 2.1 AA Requirements Apply to Mobile Apps?

WCAG 2.1 AA defines 4 principles: perceivable, operable, understandable, and robust.

• Color contrast: 4.5:1 minimum ratio for standard text, 3:1 for large text (18px+ bold or 24px+ regular).
• Text resizing: Content remains readable when system font size increases to 200%.
• Touch targets: Minimum 44×44 CSS pixels for all interactive elements.
• Motion: Animations respect the “reduce motion” system setting.
• Orientation: App supports both portrait and landscape unless one orientation is essential.
• Timing: No time limits on user input unless essential (session timeouts warn before expiring).
• Labels: Every form input has a visible label and an associated accessible name.

What Screen Reader and Assistive Technology Checks Are Required?

Test with VoiceOver (iOS) and TalkBack (Android) to verify that every screen element is announced correctly.

• Focus order: Screen reader traverses elements in logical reading order, top to bottom, left to right.
• Headings: Screen reader identifies heading hierarchy (H1, H2, H3) for navigation.
• Images: Decorative images are hidden from screen readers, informative images have alt text.
• Buttons: Every button announces its label and state (enabled, disabled, selected).
• Dynamic content: Screen reader announces live updates (loading states, success/error messages, counters).
• Gestures: All multi-finger gestures have a single-finger alternative.
• Haptic feedback: Touch interactions provide tactile response alongside visual feedback.

What Does the Performance Testing Checklist Cover?

The performance testing checklist measures launch time, response time, battery drain, memory usage, and CPU load. Slow apps lose users. Google reports that 53% of mobile visits end when load time exceeds 3 seconds (Google, 2018).

What Performance Thresholds Apply to Mobile Apps?

Set measurable thresholds before testing. Verify each metric against these baselines.

What Tools Measure Mobile App Performance?

Android and iOS each provide built-in profiling tools. Third-party tools add crash reporting and real-user monitoring.

• Android Profiler: CPU, memory, network, and energy monitoring in Android Studio.
• Xcode Instruments: Time Profiler, Allocations, Energy Log, Network for iOS.
• Firebase Performance Monitoring: Real-user metrics for startup time, network latency, screen rendering.
• Firebase Crashlytics: Crash reporting with stack traces and affected device data.
• Charles Proxy / Proxyman: Network traffic inspection, throttling simulation.

What Does the Security Testing Checklist Cover?

The security testing checklist identifies vulnerabilities based on the OWASP Mobile Top 10. A single security breach exposes the organization to regulatory penalties under GDPR, PCI DSS, and regional data protection laws.

What OWASP Mobile Top 10 Risks Apply to Mobile Apps?

The OWASP Mobile Top 10 (2024) defines the most critical security risks for mobile applications.

• Improper credential usage: Hardcoded API keys, embedded secrets in app bundle.
• Inadequate supply chain security: Unverified third-party SDKs and dependencies.
• Insecure authentication: Weak password policies, missing multi-factor authentication.
• Insufficient input/output validation: SQL injection, XSS through WebView.
• Insecure communication: HTTP endpoints, missing certificate pinning, unencrypted data transmission.
• Inadequate privacy controls: Excessive data collection, missing consent mechanisms.
• Insufficient binary protection: No code obfuscation, no tamper detection.
• Security misconfiguration: Debug mode enabled, verbose error messages in production.
• Insecure data storage: Sensitive data in SharedPreferences, UserDefaults, or local SQLite without encryption.
• Insufficient cryptography: Weak algorithms (MD5, SHA1), hardcoded encryption keys.

What Data Storage and Transmission Checks Are Required?

Every piece of sensitive data must be encrypted at rest and in transit.

• Local storage: No credentials, tokens, or PII stored in plaintext (SharedPreferences, UserDefaults, local DB).
• Keychain/Keystore: Sensitive tokens stored in iOS Keychain or Android Keystore.
• TLS: All network calls use HTTPS with TLS 1.2 or higher.
• Certificate pinning: App validates server certificate against a known pin.
• Clipboard: Sensitive fields (password, OTP) block clipboard copy.
• Screenshots: Sensitive screens prevent screenshots and screen recording (FLAG_SECURE on Android).
• Logs: No sensitive data appears in system logs (adb logcat, Console.app).

What Does the Compatibility Testing Checklist Cover?

The compatibility testing checklist verifies consistent behavior across OS versions, screen sizes, and manufacturers. Android fragmentation is the primary challenge. Google’s Android distribution dashboard reports active devices across 6+ major OS versions simultaneously.

How Do QA Teams Select Target Devices for Compatibility Testing?

Select the 8-10 device and OS combinations that represent 90%+ of your target audience traffic.

• Analytics data: Export device and OS data from Firebase, Mixpanel, or Google Analytics.
• OS versions: Test the 3 most recent Android versions and 2 most recent iOS versions.
• Screen sizes: Test at least one device per category: small (5″), medium (6.1″), large (6.7″), tablet (10″+).
• Manufacturers: Include Samsung, Xiaomi, and Google Pixel for Android (different OEM skins affect rendering).
• Chipsets: Include one low-end device (2GB RAM, budget SoC) to catch performance issues.

What UI Elements Break Across Screen Sizes and Resolutions?

Text truncation, button overlap, image cropping, and layout overflow are the 4 most common UI breaks.

• Text truncation: Long strings (translated text, user names) clip or overflow containers.
• Button overlap: Action buttons overlap on smaller screens or with larger system font sizes.
• Image scaling: Images pixelate on high-density screens or stretch on non-standard aspect ratios.
• Notch and cutout: Content hidden behind camera notch, punch hole, or Dynamic Island.
• Navigation bar: Android gesture navigation bar overlaps bottom UI elements.
• Foldable devices: App handles fold/unfold transitions, split-screen mode, and flex mode.

What Does the Usability Testing Checklist Cover?

The usability testing checklist evaluates how easily real users complete tasks without confusion, errors, or abandonment. Usability testing uses human observation. Functional testing asks “does it work?” Usability testing asks “can a real person figure it out?”

What Navigation and Layout Checks Does Usability Testing Include?

Navigation checks verify that users reach any screen within 3 taps from the home screen.

• Information architecture: Menu labels match user mental models (test with card sorting or tree testing).
• Back navigation: Back button and swipe-back gesture return to the previous screen, not a random ancestor.
• Empty states: Screens with no data show helpful guidance (not blank white screens).
• Loading states: Every action that takes more than 300ms shows a loading indicator.
• Error recovery: Error screens provide a clear action (retry, go back, contact support).
• Onboarding: First-time users complete the core task without external help.

What Visual and Interaction Checks Does Usability Testing Include?

Visual checks verify consistency in typography, spacing, color, and interactive element behavior.

• Font consistency: No more than 2 font families across the app.
• Color usage: Status colors are consistent (red for error, green for success, yellow for warning).
• Touch feedback: Every tappable element shows a visual response (ripple, highlight, state change).
• Scroll behavior: Long lists scroll smoothly at 60 FPS without jank.
• Keyboard: Keyboard does not overlap input fields, screen scrolls to keep the active field visible.
• Form flow: “Next” button on keyboard advances to the next field, “Done” dismisses the keyboard.

What Does the Network Condition Testing Checklist Cover?

The network condition testing checklist verifies app behavior across 2G, 3G, 4G, 5G, WiFi, offline mode, and network transitions. Users switch between networks constantly. A food delivery app that crashes during a WiFi-to-4G handoff loses the order.

How Do QA Teams Simulate Network Conditions?

Android and iOS provide built-in network throttling. Third-party proxies offer more granular control.

• Android: ADB commands (adb shell settings put global captive_portal_mode 0) and Network Link Conditioner.
• iOS: Settings > Developer > Network Link Conditioner (requires Developer mode enabled).
• Charles Proxy: Throttle to custom bandwidth, latency, and packet loss percentages.
• Airplane mode: Toggle during active data transfer to test offline fallback.

What App Behaviors Do Teams Verify Under Poor Connectivity?

The app must handle network loss without crashing, losing data, or showing blank screens.

• Offline mode: App displays cached content or a clear offline message.
• Data sync: Pending actions queue locally and sync when connectivity returns.
• Timeout handling: API calls that exceed the timeout show a retry option (not an infinite spinner).
• Partial load: Images and content load progressively (not all-or-nothing).
• Network switch: App recovers when switching from WiFi to mobile data mid-session.
• Low bandwidth: App degrades gracefully on 2G (lower image quality, deferred non-essential loads).

What Does the Push Notification Testing Checklist Cover?

The push notification testing checklist verifies delivery, display, routing, permission handling, and behavior across foreground, background, and killed app states.

• Permission prompt: App requests notification permission at a contextually appropriate moment (not on first launch).
• Delivery: Notifications arrive on both Android (FCM) and iOS (APNs) within 5 seconds.
• Foreground: Notification displays as an in-app banner (not a system notification) when the app is active.
• Background: Notification appears in the system tray with correct title, body, and icon.
• Killed state: Notification arrives even when the app is force-closed.
• Tap action: Tapping the notification opens the correct screen (deep link routing works).
• Badge count: App icon badge updates with unread notification count.
• Grouped notifications: Multiple notifications from the same channel stack correctly.
• Do Not Disturb: App respects the system DND setting.
• Opt-out: Users can disable notifications per category from within the app.

What Does the Interrupt Testing Checklist Cover?

The interrupt testing checklist verifies that the app preserves state and resumes correctly when external events occur during use.

• Incoming call: App pauses, call completes, app resumes at the same state.
• SMS/message: Notification banner appears without disrupting the active workflow.
• Alarm: Alarm fires, user dismisses it, app resumes without data loss.
• Low battery warning: System alert appears, app continues functioning after dismissal.
• Charging cable: Plugging and unplugging the charger does not restart the app or lose state.
• Headphone plug/unplug: Audio-playing apps handle the output switch without crashing.
• Orientation change: Rotating the device mid-form does not clear entered data.
• Split screen: App handles multi-window mode on Android without layout breaks.
• System dialog: Permission prompts, system updates, and other OS dialogs do not corrupt app state.
• Memory pressure: OS kills the background app, user returns, app restores the previous state.

What Does the Localization Testing Checklist Cover?

The localization testing checklist verifies that the app renders correctly in every supported language, region, and cultural context.

• Text expansion: German and Finnish translations are 30-40% longer than English. UI accommodates expanded text without truncation.
• RTL layout: Arabic, Hebrew, and Urdu content mirrors the layout (navigation, icons, progress bars flip direction).
• Date format: Dates follow regional conventions (MM/DD/YYYY in US, DD/MM/YYYY in EU and India, YYYY/MM/DD in Japan).
• Currency: Currency symbols, decimal separators (comma vs period), and thousand separators render correctly.
• Number format: Phone numbers, postal codes, and ID formats match regional patterns.
• Images and icons: No culturally inappropriate imagery (hand gestures, religious symbols, color meanings vary by culture).
• Sorting: Alphabetical sorting follows locale-specific collation rules.
• Hardcoded strings: No English strings remain in non-English builds.

What Does the Dark Mode Testing Checklist Cover?

The dark mode testing checklist verifies correct rendering in both light and dark color schemes.

• System toggle: App follows the system-level dark mode setting automatically.
• In-app toggle: App provides its own light/dark/system toggle that overrides the system setting.
• Text readability: All text maintains WCAG contrast ratios in both modes.
• Images: Logos and illustrations remain visible (dark logos on dark backgrounds disappear).
• Maps and charts: Third-party components (Google Maps, chart libraries) adapt to dark mode.
• Status bar and navigation bar: System bars match the app’s color scheme.
• Splash screen: Launch screen matches the current mode (no white flash in dark mode).
• Email and WebView: Embedded web content and HTML emails render in the correct mode.
• Live switching: Toggling dark mode while the app is active does not crash or reset state.

What Does the App Update and Migration Testing Checklist Cover?

The app update and migration testing checklist verifies that user data, preferences, and sessions survive version upgrades.

• Data persistence: All user data (profile, settings, saved content) remains intact after updating from v(n) to v(n+1).
• Database migration: Schema changes (new columns, renamed tables) execute without data loss.
• Token validity: Auth tokens remain valid after update (user does not need to re-login).
• Cache: Stale cache from the old version does not cause display errors in the new version.
• Skip version: User updating from v1 to v3 (skipping v2) receives all cumulative migrations.
• Force update: App blocks usage on unsupported old versions with a clear update prompt.
• Rollback: User downgrading to an older version does not crash (graceful degradation or data wipe warning).
• First launch after update: No duplicate onboarding, no reset preferences, no permission re-prompts.

The 12 checklists above cover the full scope of mobile app testing from functionality through version migration. The sections below provide a downloadable template and common mistakes to avoid.

How Do Teams Use a Mobile App Testing Checklist Template?

A checklist template organizes all 12 categories into one spreadsheet. Columns track test item, priority, status, device, OS version, and tester.

The template structure:

Customize the template per project. Add rows for app-specific features (payment flows, chat, maps, camera). Remove rows for features the app does not include (localization rows for single-language apps).

What Are Common Mistakes QA Teams Make with Mobile App Testing Checklists?

Five common mistakes: testing only on the latest OS, skipping interrupts, ignoring offline, trusting emulators, and stale checklists.

Testing only on the latest OS version. Users do not all run the latest OS. Android users on version 12 and 13 still represent a significant share. An app that works on Android 15 but crashes on Android 13 loses that segment.

Skipping interrupt testing. Calls, alarms, and system dialogs happen during real usage. Most QA teams test features in isolation without interruptions. This misses state corruption bugs that only appear during multi-tasking.

Ignoring offline and poor connectivity states. Apps tested only on WiFi pass every performance check. The same app on a 3G connection in a subway shows loading failures, timeout errors, and data loss. Network condition testing catches these.

Treating emulator results as final. Emulators simulate software behavior. They do not replicate hardware-specific issues: GPS accuracy, camera quality, sensor calibration, battery drain, and thermal throttling. Real devices are the final validation step. Teams that run emulators and simulators for early testing and real devices for final validation get the best coverage.

Never updating the checklist. A checklist written in 2022 does not cover dark mode, foldable devices, Dynamic Island, or Android 14+ predictive back gestures. Update the checklist every quarter to match OS and device landscape changes.

For teams that need end-to-end testing by dedicated QA engineers, specialist partners manage the checklist, execution, and reporting across devices.