>_ Mobile Device Testing Checklist

Short answer

A Mobile Device Testing Checklist is a list of checks that helps make sure a website, web app, or native mobile app works correctly on real mobile devices with different screen sizes, OS versions, browsers, hardware capabilities, network conditions, and performance limits.

Mobile device testing does not focus only on product functionality. It focuses on how the product behaves on specific devices: iPhones, Android phones, tablets, small screens, large screens, older devices, low-end Android devices, devices with notches, different pixel densities, real mobile browsers, sensors, camera, location, biometrics, network switching, battery, memory, and performance.

This article does not replace a Mobile App Testing Checklist or a Mobile Web Testing Checklist. It complements them. If mobile app testing answers "does the app work?", and mobile web testing answers "does the website work in a mobile browser?", then mobile device testing answers: "does it work on the real devices real people actually use?"

The main idea is: mobile device testing checks compatibility and stability in real device conditions, not only in an emulator, simulator, or desktop browser viewport.

---

Mobile Device Testing vs Mobile App Testing

Mobile App Testing checks a native iOS or Android application:

• installation;
• launch;
• onboarding;
• login;
• permissions;
• push notifications;
• deep links;
• offline mode;
• app lifecycle;
• crashes;
• App Store / Google Play release.

Mobile Device Testing checks how an app or mobile experience behaves across different devices:

• screen sizes;
• OS versions;
• device models;
• low-end vs high-end devices;
• memory and CPU limits;
• camera and sensors;
• location behavior;
• network switching;
• battery usage;
• device orientation;
• notch and safe areas;
• hardware differences.

In simple terms: mobile app testing checks the application as a product, while mobile device testing checks the application in the real conditions of different devices.

---

Mobile Device Testing vs Mobile Web Testing

Mobile Web Testing checks a website or web app in a mobile browser:

• responsive layout;
• mobile Safari;
• mobile Chrome;
• mobile navigation;
• forms;
• mobile keyboard;
• checkout;
• browser behavior;
• web performance.

Mobile Device Testing checks device-level behavior:

• real device rendering;
• screen density;
• safe areas;
• browser UI impact;
• touch behavior;
• hardware performance;
• network behavior;
• orientation;
• device-specific bugs;
• camera/file upload behavior;
• real-device compatibility.

In simple terms: mobile web testing checks the browser experience, while mobile device testing checks how that experience behaves on specific devices.

---

Mobile Device Testing vs Emulator / Simulator Testing

Emulators and simulators are useful, but they do not replace real devices.

Emulator / simulator testing helps quickly check:

• layout;
• basic flows;
• OS-level behavior;
• screen sizes;
• early development builds;
• repeated test runs.

Real mobile device testing helps find issues that often do not appear in emulators:

• real touch behavior;
• real keyboard behavior;
• real camera access;
• real push notifications;
• real biometrics;
• real battery impact;
• real performance;
• real network switching;
• device-specific crashes;
• manufacturer-specific Android behavior;
• Safari behavior on an actual iPhone;
• device safe areas and notches.

In simple terms: an emulator helps quickly check an idea, while a real device shows how the product behaves in the user's hands.

---

When to use a Mobile Device Testing Checklist

Use this checklist whenever mobile experience is important for the product.

For example:

• a mobile app is launching;
• a mobile web experience is launching;
• a mobile-ready check is needed;
• responsive design changes;
• app navigation changes;
• mobile checkout changes;
• login/signup on mobile changes;
• camera or file upload is added;
• location is added;
• push notifications are added;
• biometric login is added;
• offline mode changes;
• a performance-sensitive screen changes;
• device support policy changes;
• tablet support is added;
• support for older OS versions is added;
• there was a production bug only on a specific device;
• users complain about mobile performance;
• crash reports show a device-specific issue;
• analytics shows high mobile traffic.

For a small UI change, a short real-device smoke test may be enough. For a mobile app release, checkout, auth, payment, camera/location features, offline mode, or production incident, it is better to go through the full mobile device testing checklist.

---

Short Mobile Device Testing Checklist

If you need a minimal mobile device smoke test, check that:

• the product works on a real iPhone;
• the product works on a real Android device;
• small screens do not break the layout;
• large screens do not break the layout;
• latest supported iOS works;
• latest supported Android works;
• older supported OS works, if included in scope;
• mobile Safari works, if this is web;
• mobile Chrome works;
• orientation change does not break the key flow;
• touch interactions are comfortable;
• mobile keyboard does not cover critical fields;
• notch / safe area does not cover UI;
• camera/file upload works, if used;
• location works, if used;
• push notification works, if used;
• biometric login works, if used;
• Wi-Fi and mobile network both work;
• network switching does not break the session;
• slow network shows a clear state;
• app/page does not crash on a real device;
• performance is acceptable on a non-flagship device;
• battery/memory do not show obvious issues;
• production device smoke has passed after release.

This is not full mobile app QA and not full mobile web QA. It is a quick check that shows whether the product is ready for real use on mobile devices.

---

Mobile Device Testing Checklist

1. Define the mobile device testing scope

Before testing starts, understand which devices and conditions actually matter.

Check that:

• mobile app, mobile web, or both are being tested;
• iOS is included in scope;
• Android is included in scope;
• tablets are included in scope;
• supported OS versions are known;
• supported browsers are known;
• critical screen sizes are known;
• user flows that need real-device testing are defined;
• hardware features used by the product are known;
• camera is used, if applicable;
• microphone is used, if applicable;
• location is used, if applicable;
• biometrics are used, if applicable;
• push notifications are used, if applicable;
• offline mode exists, if applicable;
• payments are included, if applicable;
• there are device-specific production complaints;
• the person responsible for pass / fail decision is known.

The main question is: on which real devices should the user be able to complete the key scenario without problems?

---

2. Prepare the device matrix

A device matrix is a list of devices, OS versions, and conditions the team will test.

Check that the matrix covers:

• iPhone;
• Android phone;
• small screen;
• large screen;
• tablet, if supported;
• latest supported iOS;
• older supported iOS, if important;
• latest supported Android;
• older supported Android, if important;
• low-end or mid-range Android device;
• high-end device;
• portrait orientation;
• landscape orientation;
• Wi-Fi;
• mobile network;
• slow or unstable network.

The device matrix does not need to be endless. It is better to choose a few real combinations that cover the main audience and the riskiest scenarios.

---

3. Use analytics and production data to choose devices

If analytics, crash reports, or support tickets are available, the device matrix should reflect real data.

Check:

• which devices generate the most traffic;
• which OS versions are most common;
• which browsers mobile users use;
• which screen sizes appear most often;
• which devices generate the most crashes;
• which devices generate the most support tickets;
• whether there are country- or region-specific device patterns;
• whether a high-value user segment uses specific devices;
• which devices matter for paid traffic;
• which devices matter for conversion.

The team does not need to test every device in the world. But it should test the devices that actually matter for the product.

---

4. Check iPhone devices

iPhone testing is important for mobile web and mobile apps because Safari, iOS permissions, push behavior, safe areas, and gestures have their own specifics.

Check that:

• app or site opens on iPhone;
• layout is correct;
• safe areas are respected;
• notch does not cover content;
• bottom browser UI does not cover CTA;
• mobile Safari works, if this is web;
• iOS keyboard does not break forms;
• iOS autofill works;
• password manager works;
• camera access works, if needed;
• photo library access works, if needed;
• location permission works;
• push notification works, if this is an app;
• biometric login works, if supported;
• orientation change works;
• performance is acceptable.

iPhone testing is especially important for checkout, forms, authentication, product pages, media upload, and payment flows.

---

5. Check Android devices

Android device testing is especially important because of the variety of manufacturers, screen sizes, OS versions, and hardware.

Check that:

• app or site opens on Android;
• mobile Chrome works, if this is web;
• supported Android browser works;
• layout is correct;
• system navigation does not cover CTA;
• keyboard behavior is correct;
• autofill works;
• password manager works;
• camera access works;
• gallery/file picker works;
• location permission works;
• push notification works, if this is an app;
• Android Back button or gesture works;
• orientation change works;
• low-end performance is acceptable;
• there is no device-specific crash.

Android bugs often appear not on flagship devices, but on mid-range or weaker devices.

---

6. Check tablets, if supported

Tablet experience is not just a "large phone" experience.

Check that:

• tablet layout looks intentional;
• app or site is not stretched unnaturally;
• navigation adapts;
• landscape mode works;
• portrait mode works;
• sidebars do not break content;
• modals are not too wide;
• forms remain readable;
• tables and dashboards are usable;
• touch targets are comfortable;
• split-screen mode works, if important;
• keyboard/case usage does not break the flow;
• product does not show phone-only layout without reason.

If tablet support is promised, tablet should be tested as a separate device category.

---

7. Check screen sizes

Different screen sizes can break layout, navigation, forms, and CTAs.

Check:

• small phone screen;
• standard phone screen;
• large phone screen;
• tablet screen;
• narrow viewport;
• wide mobile viewport;
• short viewport height;
• tall viewport height;
• screen with notch;
• screen with rounded corners;
• screen with system navigation bar;
• screen with dynamic browser UI;
• foldable or unusual screen, if included in scope.

The main question is: does the key flow remain usable on both small and large screens?

---

8. Check pixel density and image quality

Images and icons can look different across devices.

Check that:

• images look sharp on high-density screens;
• icons are not blurry;
• logo is not blurry;
• product images are sharp enough;
• thumbnails are readable;
• image crop is correct;
• large images are not too heavy;
• image gallery works;
• videos look acceptable;
• media does not create performance issues;
• fallback image is displayed if image fails to load.

Device testing should consider not only screen size, but also the actual display quality on real hardware.

---

9. Check safe areas, notch, and system UI

Modern devices have notches, rounded corners, home indicators, status bars, and browser UI.

Check that:

• status bar does not cover content;
• notch does not cover title or navigation;
• home indicator does not cover CTA;
• bottom navigation respects system area;
• sticky footer is not under system controls;
• modal does not go outside the safe area;
• full-screen mode works, if used;
• landscape safe area works;
• browser UI does not cover sticky elements;
• important action remains visible.

Safe area bugs often look like "the button exists, but it cannot be tapped."

---

10. Check orientation

The user may rotate the device.

Check that:

• portrait mode works;
• landscape mode works, if supported;
• orientation lock works, if product is portrait-only;
• layout reflows;
• current screen is preserved;
• form data is not lost;
• keyboard behavior remains acceptable;
• modal does not break;
• video/media reacts correctly;
• navigation remains available;
• CTA remains available;
• app or page does not reload without reason;
• there is no crash after rotation.

Even if most users work in portrait mode, landscape may reveal issues with height, modals, and keyboard behavior.

---

11. Check touch interactions

Real touch behavior differs from mouse clicks.

Check that:

• tap works;
• double tap does not create duplicate action;
• long press works, if used;
• swipe works, if used;
• pull to refresh works, if available;
• pinch to zoom works, if supported;
• drag and drop works, if available;
• touch targets are large enough;
• elements are not too close together;
• accidental taps do not happen often;
• scroll does not conflict with swipe;
• carousel does not interfere with vertical scroll;
• gestures have alternative controls if the action is critical.

Touch testing is better done by hand on a real device, not only through an emulator.

---

12. Check mobile keyboard on a real device

Keyboard is one of the main sources of mobile bugs.

Check that:

• keyboard opens for input;
• correct keyboard type opens for email;
• correct keyboard type opens for phone;
• correct keyboard type opens for number;
• correct keyboard type opens for URL;
• keyboard does not cover the active field;
• keyboard does not cover the submit button;
• user can move to the next field;
• form scrolls to the active field;
• landscape keyboard does not break layout;
• autocorrect does not damage email or username;
• one-time code autofill works, if used;
• password manager works;
• address autofill works, if needed.

Mobile keyboard bugs often directly affect signup, login, checkout, and forms.

---

13. Check OS versions

The same app or site can behave differently across OS versions.

Check:

• latest supported iOS;
• older supported iOS;
• latest supported Android;
• older supported Android;
• minimum supported OS;
• permission behavior on each OS;
• push notification behavior;
• background/foreground behavior;
• browser behavior;
• file picker behavior;
• camera behavior;
• location behavior;
• biometric behavior;
• OS-specific crash;
• deprecated behavior, if important.

OS compatibility should be reviewed after major iOS or Android updates.

---

14. Check mobile browsers on devices

For mobile web, browsers should be tested on real devices, not only in desktop responsive mode.

Check:

• Safari on iPhone;
• Chrome on Android;
• supported Android browser;
• supported iOS browser, if different from Safari UI;
• cookies work;
• local storage works;
• session remains;
• redirects work;
• payment redirects work;
• autofill works;
• forms work;
• media works;
• file upload works;
• browser Back works;
• there is no browser-specific layout issue.

Mobile Safari and mobile Chrome often show different issues, especially with forms, sticky elements, cookies, viewport, and redirects.

---

15. Check manufacturer-specific Android behavior

On Android, different manufacturers may manage battery, background activity, permissions, and UI differently.

Check, if relevant:

• Samsung device;
• Google Pixel;
• Xiaomi/Redmi;
• OnePlus;
• Oppo/Vivo;
• Huawei/Honor, if your audience uses them;
• manufacturer keyboard;
• manufacturer battery optimization;
• push delivery behavior;
• background restrictions;
• permission dialogs;
• camera/gallery behavior;
• file picker behavior.

You do not always need to cover every manufacturer. But if production users complain about specific Android devices, add them to the matrix.

---

16. Check low-end and mid-range devices

Performance on a flagship device does not guarantee performance for real users.

Check on a less powerful device:

• app launch;
• page load;
• navigation;
• scrolling;
• forms;
• image-heavy screens;
• product listing;
• checkout;
• search;
• camera upload;
• map/location screen;
• memory usage;
• no freeze;
• no crash;
• no severe input lag.

Low-end testing is especially important for markets where users often use budget Android devices.

---

17. Check memory behavior

Memory issues often appear only on real devices.

Check that:

• app does not crash after long usage;
• app does not crash after viewing many screens;
• image-heavy screens do not cause crashes;
• video/media does not overload memory;
• product listing does not create a memory leak;
• repeated navigation does not degrade performance;
• background/foreground does not create memory issues;
• low-memory system behavior is handled;
• app recovers after OS kills it, if applicable;
• web page does not unexpectedly reload the tab.

Memory testing is especially important for mobile apps, PWAs, image-heavy e-commerce, maps, chat, camera, and video features.

---

18. Check CPU and responsiveness

Check that:

• UI remains responsive;
• scrolling is smooth;
• animation does not lag;
• typing does not lag;
• search input does not freeze;
• filters do not cause freezing;
• checkout does not hang;
• map does not lag critically;
• camera preview works;
• heavy calculations do not block UI;
• repeated interactions do not reduce responsiveness;
• app does not overheat the device.

If the product technically works but the UI feels heavy, users may still perceive it as broken.

---

19. Check battery usage

Battery issues are especially important for apps with location, media, background sync, Bluetooth, or long sessions.

Check that:

• app does not drain battery excessively;
• background activity does not run unnecessarily;
• location tracking stops according to rules;
• camera/microphone do not remain active;
• Bluetooth/NFC does not remain active without reason;
• push/polling is not too frequent;
• sync interval is reasonable;
• video playback does not create unexpected drain;
• app does not keep the screen awake without reason;
• battery impact is acceptable for the key use case.

For short web flows, battery is usually not the main risk. For native apps and long sessions, it matters a lot.

---

20. Check network conditions

Mobile users are rarely on a perfect connection.

Check that:

• Wi-Fi works;
• mobile data works;
• slow network shows a loading state;
• unstable network is handled;
• no-network state is clear;
• airplane mode is handled;
• switching Wi-Fi → mobile data works;
• switching mobile data → Wi-Fi works;
• temporary disconnect does not break the flow;
• retry works;
• form data is not lost;
• checkout/payment is not duplicated;
• app/page does not remain on an endless loader.

Network testing is especially important for login, checkout, payment, search, upload, offline mode, and data sync.

---

21. Check offline behavior

If the product supports offline or partial offline state, check that:

• offline state is displayed;
• cached data is available, if expected;
• unavailable actions are disabled or explained;
• drafts are saved, if supported;
• offline changes are saved locally;
• sync starts after reconnect;
• sync status is clear;
• conflict handling works;
• duplicate records are not created;
• user does not lose data;
• app does not crash without network;
• mobile web shows a clear fallback if offline is not supported.

Offline behavior should not look like a random failure.

---

22. Check camera

If the product uses camera, test it only on real devices.

Check that:

• camera permission is requested;
• user understands why camera is needed;
• allow scenario works;
• deny scenario is handled;
• camera opens;
• front/back camera works, if needed;
• photo capture works;
• video capture works, if needed;
• preview displays correctly;
• captured file is saved;
• upload after capture works;
• photo orientation is correct;
• large image is handled;
• app/page recovers after closing camera.

Camera behavior can differ greatly between iOS, Android, and specific devices.

---

23. Check photo library and file picker

Check that:

• photo permission is requested, if needed;
• limited photo access works, if relevant;
• user can select an image;
• user can select a video, if supported;
• user can select a file;
• unsupported file type is handled;
• large file is handled;
• file name is displayed;
• upload progress is visible;
• upload error is clear;
• selected file is not lost after orientation change;
• denied permission is handled;
• mobile web file input works.

File picker is a common source of device-specific issues.

---

24. Check microphone and audio

If the product uses microphone or audio, check that:

• microphone permission is requested;
• allow scenario works;
• deny scenario is handled;
• recording starts;
• recording stops;
• playback works;
• audio quality is acceptable;
• interruption by call is handled;
• background behavior follows rules;
• microphone indicator appears according to OS;
• app does not record without clear user action;
• uploaded audio is saved;
• error states are clear.

This is important for voice messages, calls, transcription, language learning, telehealth, and support apps.

---

25. Check location and GPS

Location testing should be performed on real devices.

Check that:

• location permission is requested;
• user understands why location is needed;
• allow while using app works;
• always allow works, if required;
• deny scenario is handled;
• approximate location is handled;
• precise location is handled;
• current location is detected;
• map opens;
• location updates work;
• background location follows rules;
• no-location state is handled;
• battery usage is acceptable;
• wrong or outdated location recovery works.

Location features are especially sensitive to permissions, OS versions, and battery settings.

---

26. Check biometrics

If Face ID, Touch ID, or Android biometrics are used, check that:

• biometric setup is detected;
• biometric login can be enabled;
• biometric prompt appears;
• successful biometric auth works;
• failed biometric auth is handled;
• fallback to password works;
• biometric unavailable state is handled;
• device without biometrics is handled;
• logout behavior is clear;
• app does not show sensitive data before auth;
• changing device biometrics follows product rules.

Biometrics are security-sensitive. They should not be tested only in an emulator.

---

27. Check push notifications on real devices

Push notifications almost always require real device testing.

Check that:

• notification permission prompt appears;
• allow scenario works;
• deny scenario is handled;
• push token is registered;
• notification is delivered;
• notification displays correctly;
• tapping notification opens the correct screen;
• notification works when the app is in foreground;
• notification works when the app is in background;
• notification works when the app is closed;
• duplicate notifications are not sent;
• notification preferences are respected;
• OS-level notification settings are handled.

Push testing is especially important for chat, marketplaces, delivery, bookings, reminders, and security alerts.

---

28. Check Bluetooth, NFC, and hardware integrations, if available

If the product uses hardware integrations, this must be part of real-device scope.

Check that:

• Bluetooth permission works;
• device discovery works;
• pairing works;
• connection recovery works;
• disconnect is handled;
• NFC scan works;
• hardware reader works;
• external device errors are handled;
• denied permissions are handled;
• battery impact is acceptable;
• background behavior follows rules;
• logs help debug hardware failures.

These scenarios are almost impossible to test reliably without a real device and hardware.

---

29. Check payments on device

If the mobile flow includes payment, check on real devices:

• mobile checkout opens;
• payment sheet opens;
• wallet option appears, if supported;
• Apple Pay works, if supported;
• Google Pay works, if supported;
• card input works;
• 3DS redirect works;
• return from payment provider works;
• canceled payment is handled;
• failed payment is handled;
• success confirmation works;
• duplicate payment/order is not created;
• mobile keyboard does not block fields.

Payment flows often depend on OS, browser, wallet, redirects, and app lifecycle.

---

30. Check deep links and app links on device

Deep links should be tested on real devices.

Check that:

• link opens the app;
• link opens the correct screen;
• link works when app is installed;
• fallback works when app is not installed;
• unauthenticated user is handled;
• after login, user lands on the intended screen;
• expired link is handled;
• invalid link is handled;
• push notification deep link works;
• email link works;
• web-to-app transition works;
• app-to-web fallback works.

Deep link bugs often appear only on real devices and specific OS versions.

---

31. Check app lifecycle on device

For native apps, check that:

• app launches;
• app goes to background;
• app returns to foreground;
• current state is preserved;
• form data is preserved;
• app handles OS killing the process;
• force close and relaunch work;
• session remains or expires according to rules;
• app handles screen lock/unlock;
• app handles incoming call;
• app handles notification interruption;
• app handles low battery alert;
• app does not create duplicate actions after resume.

App lifecycle cannot be fully checked through static screens.

---

32. Check mobile web lifecycle on device

For mobile web, check that:

• page opens in browser;
• page works after browser tab switch;
• page works after screen lock/unlock;
• page state after backgrounding browser is acceptable;
• form data remains after tab switch;
• checkout works after temporary browser background;
• payment redirect works after returning to browser;
• browser Back behavior works;
• refresh behavior is safe;
• session persists;
• cookies/local storage behavior is correct;
• PWA behavior works, if supported.

Mobile web also has lifecycle risks, especially for checkout, authentication, and forms.

---

33. Check accessibility settings on device

Device-level accessibility settings can change layout and interaction.

Check, if in scope:

• larger text;
• bold text;
• display zoom;
• high contrast;
• reduce motion;
• screen reader basics;
• voice control, if important;
• color filters, if important;
• increased touch duration, if important;
• text is not cut off;
• buttons remain visible;
• critical flow remains usable.

This does not replace an Accessibility Testing Checklist, but it helps catch device-level blockers.

---

34. Check dark mode and theme settings

If the product supports dark mode or depends on system theme, check that:

• light mode works;
• dark mode works;
• system theme detection works;
• switching theme does not break UI;
• text remains readable;
• icons are visible;
• images are acceptable;
• form fields are readable;
• modals are readable;
• notifications are readable;
• email/webview content is readable, if used;
• there is no invisible text.

Dark mode bugs often appear only on a real device with system settings enabled.

---

35. Check localization and region settings on device

Device region settings can affect date, time, currency, keyboard, and language.

Check that:

• app/site language follows expected rules;
• device language is handled;
• region format is handled;
• date format is correct;
• time format is correct;
• currency display is correct;
• decimal separators are correct;
• keyboard language works;
• right-to-left layout works, if supported;
• long translated text does not break layout;
• location/region restrictions are handled.

Localization issues often look like layout bugs or calculation bugs.

---

36. Check sensors and motion, if used

If the product uses device sensors, test on real devices:

• accelerometer;
• gyroscope;
• compass;
• motion permission, if required;
• orientation-based features;
• step/activity tracking, if supported;
• AR behavior, if supported;
• sensor unavailable state;
• wrong sensor readings are handled;
• battery impact is acceptable;
• privacy explanation is clear.

Sensor-based features cannot be tested reliably without a physical device.

---

37. Check QR/barcode scanning, if available

Check that:

• scanner opens;
• camera permission works;
• QR code is recognized;
• barcode is recognized;
• invalid code is handled;
• poor lighting is handled;
• blurry code is handled;
• duplicate scan is handled;
• scan result opens the correct screen;
• offline scan behavior is handled;
• scanner closes correctly;
• there is no crash after scanning.

QR/barcode scanning depends heavily on camera quality, focus, and lighting.

---

38. Check device storage

For mobile apps and PWAs, storage can be critical.

Check that:

• app handles low storage;
• cache does not grow endlessly;
• downloaded files save correctly;
• offline data is stored correctly;
• clearing cache behavior is acceptable;
• reinstall behavior is correct;
• local database migration works;
• storage permission works, if needed;
• sensitive data is not stored insecurely;
• old cached data is not shown incorrectly.

Storage issues often appear after long usage or update.

---

39. Check update and OS upgrade behavior

For native apps, check that:

• app update preserves session;
• app update preserves local data;
• app update migrates local database;
• app update does not break settings;
• app update does not duplicate notifications;
• app works after OS update;
• app handles changed permissions after OS update;
• forced update flow works;
• optional update prompt works;
• old app version behavior is understood.

For mobile web, check that:

• cached assets update;
• service worker update works, if this is a PWA;
• old JS/CSS cache does not break new API;
• browser update does not break critical flow.

---

40. Check PWA / home screen behavior, if available

If mobile web can be installed on the home screen or the product uses PWA features, check that:

• Add to Home Screen works;
• icon is correct;
• app name is correct;
• splash screen is correct;
• standalone mode works;
• navigation works without browser UI;
• offline fallback works, if supported;
• service worker updates;
• push notifications work, if supported;
• storage works;
• deep links open the correct mode;
• uninstall/reinstall behavior is clear.

A PWA can behave closer to an app than a regular website, so device testing is especially useful.

---

41. Check WebView behavior, if the product uses WebView

If a native app opens web content inside a WebView, check that:

• WebView opens;
• authentication state works;
• cookies/session work;
• links open in the correct context;
• external links open correctly;
• file upload works;
• camera permission works;
• payment redirects work;
• back navigation works;
• responsive layout fits WebView;
• there is no mixed content issue;
• performance is acceptable.

WebView often creates a separate layer of bugs between the app and mobile web.

---

42. Run production device smoke after release

After a mobile release, web release, or device-related fix, run production smoke on real devices.

Check that:

• production app/site opens on iPhone;
• production app/site opens on Android;
• login works;
• key flow works;
• form submit works;
• checkout works, if critical;
• payment works safely, if included;
• camera/location/push works, if critical;
• mobile network works;
• slow network is handled;
• there is no crash;
• there is no obvious performance issue;
• analytics/crash reporting receives events;
• there is no staging data;
• there is no test content;
• support team knows where to report device-specific issues.

Production device smoke should be short and safe. Its goal is to confirm that real users on real devices can complete the key flow after release.

---

43. Document the device testing result

After testing, save the result, especially if the bug is device-specific.

Document:

• device model;
• OS version;
• browser/app version;
• screen size, if important;
• network type;
• orientation;
• tested flow;
• result;
• issue ID, if a bug was found;
• screenshot/video;
• logs/crash report, if available;
• reproduction stability;
• workaround, if available;
• pass/fail decision.

A device-specific bug without exact device information is very difficult to reproduce quickly.

---

Common mistakes

1. Relying only on emulator or simulator

Simulator is useful, but it does not show the full picture: real camera, push, biometrics, performance, network switching, battery, and manufacturer-specific behavior.

2. Testing only one flagship device

The product may work perfectly on a new iPhone and break on a mid-range Android or older OS.

3. Not using analytics for the device matrix

If the team tests "favorite" devices instead of the devices customers actually use, device coverage will be weak.

4. Ignoring low-end Android

Many performance, memory, and scrolling issues appear on less powerful devices.

5. Not testing mobile network

Wi-Fi testing is not enough. Mobile users face unstable networks, switching, timeouts, and offline states.

6. Not testing OS versions

OS-specific permissions, browser behavior, push notifications, and background rules can differ between versions.

7. Not testing hardware features on real devices

Camera, microphone, location, biometrics, NFC, Bluetooth, and sensors cannot be tested reliably with mock data only.

8. Not documenting device details in bug reports

"Does not work on Android" is a poor bug report. Model, OS version, app/browser version, network, and exact steps are needed.

9. Not checking orientation and safe areas

Notch, home indicator, system navigation, and landscape mode can cover critical CTAs or content.

10. Not running production device smoke

Staging may work, but production may differ because of build, CDN, API, push settings, payment configuration, analytics, cache, or feature flags.

---

FAQ

What is a Mobile Device Testing Checklist?

A Mobile Device Testing Checklist is a list of checks for testing a product on real mobile devices.

It helps verify device matrix, OS versions, screen sizes, real browsers, hardware features, sensors, network conditions, performance, memory, battery, orientation, and device-specific compatibility.

How is mobile device testing different from mobile app testing?

Mobile app testing checks the native application as a product: install, launch, login, permissions, push, deep links, app lifecycle, crashes, and release.

Mobile device testing checks how that app or mobile experience behaves across different physical devices, OS versions, hardware configurations, and network conditions.

How is mobile device testing different from mobile web testing?

Mobile web testing checks a website or web app in a mobile browser.

Mobile device testing is broader at the device level: real screen, touch, safe areas, camera, location, network switching, OS behavior, performance, and hardware limitations.

Do you need to test on real devices?

Yes. Emulators and simulators are useful, but real devices better reveal touch behavior, camera, push notifications, biometrics, performance, battery, network switching, safe areas, and device-specific issues.

Which devices should be included in a device matrix?

At minimum:

• one iPhone;
• one Android phone;
• small screen;
• large screen;
• latest supported iOS;
• latest supported Android;
• older supported OS, if important;
• mid-range or low-end Android, if important for the audience;
• tablet, if supported.

The best matrix is based on analytics, crash reports, and the real audience.

What should be checked on iPhone?

Check mobile Safari or the iOS app, safe areas, notch, keyboard, autofill, camera/photo access, location, push notifications, biometrics, orientation, payment redirects, and performance.

What should be checked on Android?

Check Chrome or the Android app, system navigation, keyboard, file picker, camera/gallery, location, push notifications, Android Back button/gesture, OS fragmentation, manufacturer-specific behavior, and low-end performance.

Should tablets be tested?

Yes, if tablet support is important or promised.

Tablet layout may differ from phone layout: sidebars, split views, landscape orientation, modals, dashboards, and tables should be checked separately.

What should be checked during network testing on device?

Check Wi-Fi, mobile data, slow network, unstable connection, airplane mode, reconnect, switching between Wi-Fi and mobile data, retry behavior, loading states, and form data preservation.

How do you test hardware features?

Test hardware features only on real devices:

• camera;
• photo library;
• microphone;
• location/GPS;
• biometrics;
• Bluetooth;
• NFC;
• sensors;
• QR/barcode scanner.

For each feature, test both allow and deny permission scenarios.

How do you know mobile device testing has passed?

Mobile device testing can be considered passed when:

• key flows work on selected real devices;
• iOS and Android are covered;
• important screen sizes work;
• supported OS versions work;
• hardware features work;
• permissions are handled;
• network issues are handled;
• performance is acceptable on target devices;
• no blocker device-specific bugs remain;
• crashes do not appear;
• production device smoke has passed.