Recovery Testing: How Mobile Apps handle Crashes

Takeaways:

• Google's Android Vitals flags apps with a user-perceived crash rate above 1.09% as having "bad behavior," reducing their discoverability on Play Store. Recovery testing validates that when crashes or interruptions do happen, app recovers without losing data or breaking user's flow.
• The Luciq 2025 Mobile App Stability Outlook puts median crash-free session rate at 99.95%. Even at that level, remaining 0.05% means thousands of users per day hitting failures in high-traffic apps. What app does after failure is what recovery testing measures.
• Recovery testing overlaps with performance testing (how does app recover under load?), compatibility testing (does recovery work same on a Pixel 8 and a Galaxy S22?), and regression testing (did last deploy break a recovery path that used to work?). It's not a standalone activity.

Recovery testing checks whether a mobile app returns to a usable state after a crash, interruption, or resource failure. It doesn't prevent crashes. It validates what happens next.

Why recovery testing matters more on mobile than on web

Web apps recover by reloading a page. The browser handles session persistence, cookies survive, and URL usually brings user back to where they were. Mobile apps don't have that safety net.

When a mobile app crashes, OS terminates process. Everything in memory disappears. The app has to restore itself from whatever it persisted to disk before crash. If it didn't save anything, user starts over. That means:

• Unsaved form data is gone (checkout fields, draft messages, multi-step wizards)
• In-flight API requests have no callback waiting for their response
• Navigation state resets to home screen or last saved state
• Authenticated sessions may or may not survive, depending on token storage
• Downloaded content (offline maps, cached media) may need re-fetching

On top of that, mobile apps face interruptions that web apps don't:

• Incoming phone calls that push app to background
• The OS killing app to reclaim memory (low memory kills, or LMKs)
• Network transitions (Wi-Fi to cellular, connectivity loss)
• Battery death mid-transaction
• Device storage filling up during a download or cache write
• Push notifications that trigger navigation while a flow is active

Recovery testing is discipline of triggering each of these scenarios and verifying that app comes back gracefully. Not just "doesn't crash again," but "preserves user's progress and data."

Seven recovery scenarios every mobile app should be tested against

Each scenario below represents a real failure mode that users encounter. For each one, recovery testing answers: what does app do after this happens, and is that behavior acceptable?

1. App crash during a transaction

The app crashes while user is mid-checkout, mid-transfer, or mid-booking. When user reopens app:

• Does transaction resume from where it left off, or does user start over?
• If payment was submitted before crash, does app show confirmation or does it allow a duplicate submission?
• Is cart or order state still intact?

Good recovery: app detects incomplete transaction, shows last known state, and either resumes or clearly explains what happened. Bad recovery: user sees a blank checkout screen and has no idea whether they were charged.

2. OS kills app in background

Android aggressively kills background apps to reclaim memory, especially on devices with 3-4 GB of RAM. Google's Android Vitals tracks Low Memory Kills (LMKs) as a separate quality metric. When user switches back to app:

• Does app restore screen they were on, or does it restart from home screen?
• Are form fields still populated?
• Is scroll position preserved in a long list or feed?

This scenario matters because users don't know app was killed. From their perspective, they tapped away and came back. If app restarts from scratch, user perceives a bug, not a memory management event.

3. Network loss during an API call

The user initiates an action (loading a product page, submitting a form, syncing data) and network drops mid-request. Recovery testing checks:

• Does app show a clear error message, or does it hang indefinitely?
• Does app retry request automatically when connectivity returns?
• If request was a write operation (placing an order, sending a message), does app queue it for retry or force user to repeat action?
• Is there a timeout that prevents app from waiting forever?

For apps used in transit (ride-sharing, delivery, fitness tracking), network drops are not edge cases. They're expected behavior. Recovery from network loss should be smooth, not exceptional.

4. Battery death mid-session

The device shuts down because battery is depleted. The user charges phone and reopens app. Recovery testing checks:

• Does app restore user's session, or does it require re-authentication?
• If user was mid-flow (filling a form, writing a message), is their progress saved?
• Does app handle cold start gracefully, including any data migration or sync that needs to happen on launch?

This scenario is similar to OS kill scenario, but harder to automate because it involves actual power loss. Real-device testing is required to validate this accurately.

5. Storage full during a write operation

The app tries to save data (caching images, downloading content, writing to a local database) and device storage is full. Recovery testing checks:

• Does app display a clear message about insufficient storage?
• Does partial write get cleaned up, or does it leave corrupted data on disk?
• Can app continue operating with limited or no local storage, or does it crash?
• After user frees up space, does app resume normally without requiring a reinstall?

This scenario also overlaps with security testing: if app writes sensitive data to disk during recovery, does it encrypt that data? Crash recovery shouldn't create a security hole.

6. Interrupted update or migration

The app is updating its local database schema or migrating data between versions. The process is interrupted by a crash, a force close, or a network drop. Recovery testing checks:

• Does app detect incomplete migration on next launch?
• Does it resume migration, roll back to previous state, or fail gracefully?
• Is user's data intact after interruption?

Database migration failures are one of hardest bugs to reproduce and one of most damaging to users. A corrupted local database can render app unusable until user clears data or reinstalls, which means losing any locally stored content.

7. Force close and immediate relaunch

The user force-closes app (swipe away from recent apps list, or through device settings) and immediately reopens it. Recovery testing checks:

• Does app launch cleanly, or does it enter a crash loop from partially initialized state?
• Are background tasks (syncs, uploads, downloads) properly cancelled and restarted?
• Does app's notification state reset correctly?

Force close is different from a crash because OS sends a different signal. Apps that handle crash recovery but not force-close recovery can behave unpredictably after a user-initiated termination.

How recovery testing connects to other test types

Recovery testing doesn't live in isolation. It overlaps with several other testing disciplines, and understanding these connections helps QA teams plan coverage without duplicating effort.

Regression testing is closest neighbor. Every time a developer changes crash handling, state persistence, or error recovery logic, recovery paths need retesting. Teams that run automated regression testing should include recovery scenarios in their regression suite to catch regressions in crash handling before they reach production.

Performance testing overlaps because some recovery failures only appear under load. An app that recovers cleanly from a network drop during normal usage might fail under high traffic when retry queue grows faster than server can process it.

Compatibility testing matters because recovery behavior varies across devices and OS versions. Android's memory management differs between manufacturers (Samsung, Pixel, Xiaomi). An app that recovers correctly on a Pixel 8 might lose state on a Samsung Galaxy A14 with tighter memory constraints. Testing recovery across multiple device configurations catches these device-specific failures.

Usability testing enters when recovery is technically correct but confusing to user. An app that shows a generic "Something went wrong" message after a network failure has technically recovered, but user doesn't know what happened or what to do next. Good recovery includes clear communication.

Automating recovery testing with Drizz

Some recovery scenarios require manual intervention (battery death, storage manipulation), but several can be automated on real devices. Drizz supports test patterns needed for recovery validation on Android and iOS.

A test for crash recovery during checkout:

Tap on "Add to Cart"
Tap on "Proceed to Checkout"
Type "4111111111111111" in "Card Number"
Force close app
Relaunch app
Validate "Checkout" screen is visible
Validate "Card Number" contains "4111"

A test for network loss recovery:

Tap on "Search"
Type "running shoes" in search field
Disable network
Validate error message is visible
Enable network
Tap on "Retry"
Validate search results are visible

‍

A test for background kill recovery:

Tap on "Settings"
Scroll down until "Notification Preferences"
Toggle "Email Notifications" on
Background app
Wait 30 seconds
Foreground app
Validate "Notification Preferences" is visible
Validate "Email Notifications" is toggled on

Each test uses Drizz's Vision AI to find elements visually, so UI changes don't break recovery validation. The adaptive wait logic handles variable load times after restarts and reconnections, which is where flaky timing typically derails recovery tests in other frameworks.

Drizz Cloud distributes these tests across real device configurations (different Android versions, different manufacturers, different screen sizes). That covers compatibility testing dimension of recovery: same recovery scenario might pass on Android 15 and fail on Android 13, and you need both results.

For teams building a mobile app testing practice that includes recovery testing, Drizz provides real-device execution environment needed to validate recovery behavior accurately. Emulators miss memory pressure, storage constraints, and network variability that trigger real recovery failures.

FAQ

What is recovery testing in software testing?

Testing whether an application returns to a functional state after a crash, interruption, or resource failure without data loss.

How is recovery testing different from regression testing?

Recovery testing checks behavior after failures. Regression testing checks that existing functionality still works after code changes. They overlap.

What recovery scenarios should mobile apps be tested for?

App crashes, OS background kills, network loss, battery death, storage full, interrupted migrations, and force close with relaunch.

Can recovery testing be automated?

Partially. Crash recovery, network loss, and backgrounding can be automated on real devices. Battery and storage tests need manual setup.

Why does Google penalize apps with high crash rates?

Apps with user-perceived crash rates above 1.09% get reduced discoverability on Play Store through Android Vitals bad behavior thresholds.

Does recovery testing overlap with performance testing?

Yes. Some recovery failures only appear under load, when retry queues overwhelm server or memory is already constrained.

‍