Why this matters on the job
In India most users meet your product on a phone, not a laptop. A UPI payment, a grocery order or an OTP login happens on a budget Android device with 3 GB of RAM, a flaky 4G signal and a battery saver that kills background apps. When a mobile release breaks, it breaks in public: one-star Play Store reviews arrive within hours and you cannot hot-fix a binary that is already installed on lakhs of phones. That is why product companies expect a QA engineer to bring a mobile-specific checklist, not just a web test suite run on a smaller screen.
Interviewers at both service and product companies regularly ask: "What will you test in a mobile app that you would not test on the web?" By the end of this lesson you will answer that with a structured checklist and you will have executed it against a real demo app.
Concepts
1. Types of mobile apps
| Type | How it is built | Example | What changes for testing |
|---|---|---|---|
| Native | Kotlin/Java (Android), Swift (iOS) using platform UI widgets | Phone dialer, most banking apps | Full access to device APIs; Appium drives it through UiAutomator2 / XCUITest |
| Hybrid | Native shell plus WebView pages (Cordova, Ionic, in-app web screens) | Help/FAQ screens, payment gateway pages inside an app | Two worlds: NATIVE_APP context and WEBVIEW context; you must switch |
| Cross-platform | React Native / Flutter rendering to native or custom canvas | Many startup apps | Locators depend on how developers set testID / Semantics labels |
| Mobile web / PWA | Website opened in Chrome/Safari, optionally installable | m.site.com | Browser testing on a phone; Appium uses Chrome/Safari automation |
2. Emulator, simulator or real device?
| Option | Good for | Cannot reliably test |
|---|---|---|
| Android Emulator (AVD) | Daily automation, debugging, CI, many API levels for free | Real camera, OEM skins (MIUI/HyperOS, One UI, ColorOS), true performance and battery |
| iOS Simulator (macOS only) | Fast iOS UI automation | Push notifications on older Xcode, camera, real performance |
| Real device / device cloud | Release sign-off, OEM bugs, performance, network, biometrics | Nothing major, but costs money and time |
3. Device fragmentation
Android runs on thousands of models. You cannot test them all, so you build a device matrix from analytics: the top OS versions (for example Android 12-15), the top 5-8 models your users actually have, at least one low-RAM phone, one small screen and one tablet or foldable if your app supports it. iOS fragmentation is smaller: usually the current and previous major iOS version on two or three iPhone sizes.
4. The mobile-only test areas
| Area | What to check |
|---|---|
| Install / update / uninstall | Fresh install, upgrade from previous version keeps login and data, uninstall clears data |
| Interrupts | Incoming call, SMS, notification, alarm, low-battery popup while user is mid-flow |
| Network | Wi-Fi to mobile data switch, airplane mode mid-request, slow 2G/EDGE, timeout messages, retry |
| Permissions | Allow, Deny, "Don't ask again", revoke from Settings while app is open |
| Lifecycle | Background/foreground, process death (state restoration), rotation, split screen |
| Hardware & OS | Back button, keyboard overlap, dark mode, font scaling, battery saver, low storage |
| Localization & accessibility | Hindi / regional strings that are longer than English, TalkBack labels, touch target size |
Hands-on Lab: Run a mobile checklist on Sauce Labs My Demo App
You will execute a real interrupt/network/permission checklist on the free Sauce Labs demo app. If you already have an Android phone, you can do this today; Lesson 2 sets up the emulator and adb, after which you should repeat steps 4-6 with the commands shown.
- Download the latest APK from the my-demo-app-android Releases page (the asset ending in
.apk) and save it asmda.apk. - On a physical phone: enable Developer options (Settings > About phone > tap Build number 7 times), allow installing unknown apps for your browser or file manager, then open
mda.apkto install. On an emulator:adb install -r mda.apk. - Open the app, browse the catalog, open Sauce Labs Backpack, tap Add To Cart and confirm the cart badge shows 1. This is your happy path.
- Execute the checklist below. For every row record Pass/Fail, device model, Android version and app version.
- Simulate interrupts and network conditions on an emulator with adb (expected results are in the table):
# Incoming call and SMS (emulator console via adb)
adb emu gsm call 9876543210
adb emu gsm cancel 9876543210
adb emu sms send 9876543210 "Your OTP is 482913"
# Network: slow EDGE, then airplane mode, then back to normal
adb emu network speed edge
adb emu network delay gprs
adb shell cmd connectivity airplane-mode enable
adb shell cmd connectivity airplane-mode disable
adb emu network speed full
adb emu network delay none
# Battery: fake 5% and unplugged, then reset
adb shell dumpsys battery unplug
adb shell dumpsys battery set level 5
adb shell dumpsys battery reset
# Permissions: revoke camera while the app is running
adb shell pm revoke com.saucelabs.mydemoapp.android android.permission.CAMERA
# Process death: press Home, then kill the background process, then reopen from Recents
adb shell input keyevent KEYCODE_HOME
adb shell am kill com.saucelabs.mydemoapp.android| ID | Scenario | Steps | Expected result |
|---|---|---|---|
| MOB-01 | Call during add-to-cart | Open product, trigger call, reject it, return | Same product screen; quantity and cart badge unchanged |
| MOB-02 | OTP SMS notification | Send SMS while on Login screen | Notification shows; app does not crash; typed username is retained |
| MOB-03 | Slow network | Set EDGE + GPRS delay, open catalog and WebView screen | Loader or graceful error, no frozen UI or ANR dialog |
| MOB-04 | Airplane mode mid-flow | Enable airplane mode on WebView screen, tap Go | Clear offline message; recovers after disabling |
| MOB-05 | Rotation | Rotate on product details with quantity 3 | Quantity stays 3; layout not cut off |
| MOB-06 | Camera permission denied | Menu > QR Code Scanner > Deny | Explains why permission is needed; no crash; can re-request |
| MOB-07 | Process death | Add item, Home, am kill, reopen | App restores sensibly (cart retained or clear empty state), no crash |
| MOB-08 | Font scale 1.3 | Settings > Display > Font size max | Product names and buttons readable, not truncated |
- For any failure, write a bug in this format and attach a screen recording (
adb shell screenrecord /sdcard/bug.mp4, stop with Ctrl+C, thenadb pull /sdcard/bug.mp4):
Title : [Android 14][Pixel 7] Cart badge resets to 0 after incoming call on Product Details
Build : mda 2.x (from Releases), Android 14 (API 34) emulator
Steps : 1) Open Sauce Labs Backpack 2) Tap Add To Cart (badge = 1)
3) adb emu gsm call 9876543210 4) Reject call
Actual : Badge shows 0, item missing in cart
Expected: Badge shows 1, item present
Severity: Major Priority: P2 Frequency: 3/3
Logs : adb logcat -d > logcat.txt (attached), bug.mp4 (attached)Expected outcome: an 8-row executed checklist with device details and at least one well-written observation or bug. Most learners find that the demo app handles these well; the skill being graded is the coverage and evidence, not finding a crash.
Common mistakes
- Testing only on the newest Pixel emulator. Real users in India are on mid-range Xiaomi, Samsung, Realme, Vivo and Oppo devices with aggressive battery optimisation.
- Writing "app crashed" with no build number, device, OS version or logcat. Developers will bounce the ticket back.
- Forgetting upgrade testing: always install the previous production build, log in, then upgrade to the new build.
- Treating permissions as one test. Allow, Deny, Deny-twice ("Don't ask again") and revoke-from-Settings are four different code paths.
- Ignoring Hindi/regional translations, which are often 30-40% longer than English and break buttons.
Real-world assignment
Your lead says: "We are launching a UPI bill-payment feature next sprint. Give me a mobile test matrix by tomorrow." Produce a spreadsheet with (1) a device/OS matrix of 6 devices justified by user share, (2) at least 25 mobile-specific test cases grouped by the areas in the table above, including what happens when the user switches to the UPI app and comes back, and (3) a list of 5 scenarios you would automate with Appium and 5 you would keep manual, with one-line reasons.
Key takeaways
- Mobile testing = functional testing + interrupts, network, permissions, lifecycle, hardware, fragmentation.
- Know the four app types; hybrid apps need context switching in automation.
- Emulators are for speed and CI; real devices are for sign-off, OEM bugs and performance.
- Build a device matrix from real analytics, not from what is on your desk.
- Every mobile bug needs device, OS, build, steps, logcat and a video.
