In Part 1, we covered the foundational elements of mobile UX testing — platform guidelines, typography, touch targets, and loading states. Those details form the baseline of a competent mobile application. In this second installment, we move into territory that separates polished apps from the rest: animation testing, error handling, deep linking, push notifications, and data persistence.
Animation Testing: The Mechanics of Perceived Quality#
Animation and transitions play a vital role in perceived performance. They guide user attention, communicate state changes, and provide continuity between screens. When done well, they are invisible. When done poorly, they make an app feel broken.
Timing and Frame Rate#
Most platform guidelines recommend durations in the range of 200 to 300 milliseconds for simple transitions such as button state changes or screen slides. Anything beyond 500 milliseconds starts to feel like the interface is making the user wait.
Timing alone is not enough. Mobile devices target 60 frames per second for UI rendering, giving the system roughly 16 milliseconds to produce each frame. When an animation causes the main thread to block — due to layout recalculations or excessive view hierarchy complexity — frames get dropped, producing visible stuttering known as "jank."
Animation testing must happen on real devices, particularly older hardware. A transition that runs smoothly on a current flagship phone may stutter on a device that is two or three years old. Key areas to validate include:
- Entry and exit transitions between screens — verify consistency in both directions.
- Scroll-driven animations such as collapsing headers. Test with rapid, aggressive scrolling.
- Interruption handling. Does a new animation triggered before the current one completes cause visual glitches?
- Reduced motion settings. Both iOS and Android allow users to request reduced motion. Your app should respect this preference and remain fully functional with animations disabled.
Use Xcode Instruments on iOS and Android Studio Profiler on Android to measure frame rates during animations. These tools show exactly where frames are being dropped and why.
Error Handling: Designing for Failure#
Error handling is where many apps fall short. Network errors, server errors, validation errors — each requires a distinct, clear response. Generic messages like "Something went wrong" frustrate users because they offer no guidance on what happened or what to do next.
Categories of Errors and How to Test Them#
Network errors. Simulate complete loss of connectivity, intermittent connections, and extremely slow connections. A complete disconnect should show an offline state clearly. An intermittent connection might cause partial data loads, which often result in broken UI states that are harder to detect.
Server errors. The app should handle HTTP 4xx and 5xx responses gracefully. A 401 should redirect to authentication, not display a raw error. A 500 should show a user-friendly message with a retry option. Test what happens when the server returns malformed JSON — many apps crash because they parse responses without defensive checks.
Validation errors. Form validation should happen inline, field by field. Test edge cases: maximum length inputs, special characters, emoji in text fields, pasted content, and autofill from password managers.
Timeout handling. When a request takes too long, the user should see a clear message and an option to retry — not an infinitely spinning loader. Test that orphaned background requests do not persist after the user navigates away.
The best error messages follow a simple structure: what happened, why, and what the user can do about it. "Unable to load your feed. Check your internet connection and try again." is far more useful than "Error."
Deep Linking and Universal Links#
Deep linking allows users to share a URL that opens directly to a specific screen within your app. Universal links on iOS and App Links on Android route web URLs to in-app content without a redirect prompt. For apps with shareable content, deep linking is essential.
Test links from SMS, email, WhatsApp, social media (where URLs may be wrapped in redirects or opened in in-app browsers), QR codes, and browser-to-app handoff.
Authentication state introduces additional complexity. If a deep link points to protected content and the user is not logged in, the app should prompt for authentication and then redirect to the originally requested content — not dump the user on the home screen after login. This redirect-after-authentication flow is a common failure point. Also verify behavior for malformed URLs, deleted content, and unexpected query parameters.
Push Notifications: Beyond Basic Delivery#
Push notification testing is often done superficially — teams verify that a notification arrives and call it done. In practice, push notifications involve complex behaviors that require thorough validation.
Permission and Delivery#
Both iOS and Android require explicit user permission. On iOS, the system permission dialog appears only once — if denied, the app must direct users to Settings. On Android 13 and later, apps must request the POST_NOTIFICATIONS runtime permission explicitly. Test the full permission lifecycle: initial request, denial, and the "don't ask again" state.
Test notification delivery across all app states: foreground, background, and terminated. Behavior differs significantly. In the foreground, notifications may be silently received — the app must decide whether to show an in-app banner. When terminated, tapping a notification triggers a cold start, and the app must handle the navigation payload during initialization.
Notification Actions and Deep Links#
Rich push notifications may include action buttons, images, or expandable content. Test that each action triggers the correct behavior. A common bug is that a notification deep link works when the app is in the background but fails on a cold start because the navigation stack is not yet initialized when the link payload is processed. Test notification grouping as well — Android notification channels and iOS thread identifiers should be organized logically.
Data Persistence: Protecting What Users Care About#
Data persistence testing ensures that user data survives app updates, OS updates, device restarts, and storage pressure.
App updates. Locally stored data — preferences, drafts, authentication tokens — should remain intact after updates. If the data model changes between versions, the app needs a migration path. Test by installing the previous version, populating it with data, then updating and verifying everything is preserved.
Force-close during writes. If the app is killed during a write operation, partially written files can corrupt local databases. Transactional writes protect against this, but the protection must be tested.
Storage pressure. When device storage is nearly full, write operations may fail silently. Test that your app detects low storage and informs the user.
Sync conflicts. If the app syncs data between devices or with a server, test what happens when the same record is modified on two devices simultaneously. The app should have a defined conflict resolution strategy — and it must be tested with real concurrent edits.
Connecting the Dots#
The details covered here — animation testing, error handling, deep linking, push notifications, and data persistence — represent the middle layer of mobile quality. Each area requires deliberate test planning and real-device testing that goes beyond happy-path coverage.
In Part 3, we conclude the series with accessibility compliance, localization beyond translation, platform-specific behavior, and memory management — the final details that complete a professional mobile testing strategy.