Lesson 1 of 4
Lesson 01 — Introduction to Mobile Testing
Title: Understanding the mobile landscape as a QA engineer
Description: Learn why mobile testing is its own discipline, how different app types affect your testing approach, and what unique scenarios you must cover that simply do not exist on the web.
Why it matters for QA: Mobile apps run on thousands of different devices, operating system versions, screen sizes, and network conditions. A bug that only appears on Android 11 with a low-end chipset can cost a company millions of users. Understanding the landscape helps you make smart decisions about what to test, how to test it, and where to focus your limited time.
1. Why mobile testing is different from web testing
When most people start learning QA, they begin with web applications — you open a browser, click around, fill in forms, and check what happens. Mobile testing feels similar at first, but the reality is quite different. Here is why:
Touch interactions vs mouse and keyboard
On a website, users interact with a mouse (hover, click, right-click) and a keyboard. On a mobile app, users interact with their fingers — and that changes everything.
Mobile-specific touch interactions include:
- Tap — a quick touch, like a click
- Double tap — two quick taps (often zooms in)
- Long press — holding a finger down (often opens a context menu)
- Swipe — dragging a finger across the screen (scroll, dismiss, navigate)
- Pinch and zoom — two fingers moving together or apart (zoom in maps, images)
- Drag and drop — moving an element from one place to another
As a QA engineer, you need to test all of these. A button that works perfectly with a mouse click might be impossible to tap on a small screen because it is too small or obscured by the on-screen keyboard.
Massive variety of screen sizes and OS versions
Imagine you are testing a website. You test it in Chrome, Firefox, and Safari. That is maybe 10 combinations.
Now imagine testing a mobile app. Android alone has over 20,000 unique device models (as of 2024). Each device can run a different version of Android — from Android 9 to Android 14. Each manufacturer (Samsung, Xiaomi, OnePlus, Huawei) adds their own UI layer on top of Android. Each device has a different screen size, resolution, and pixel density.
This is called device fragmentation, and it is one of the biggest challenges in Android testing.
iOS is much simpler — Apple controls both the hardware and software, so there are far fewer combinations. But you still need to consider different iPhone models and iPad versions.
App store approval process
When a web developer fixes a bug, they deploy the fix to the server and the user gets it immediately. Mobile is different.
To publish an update on the Apple App Store, Apple reviews the app manually. This review typically takes 1–3 days, but can take longer. If they reject the app, the team must fix the issue and resubmit.
Google Play review is automated and much faster (often a few hours), but it still exists.
This means bugs that reach production are expensive to fix. You cannot just push a patch in 5 minutes. This is why quality gates before submission are so important in mobile QA.
Limited resources: CPU, RAM, and battery
Mobile devices have much less power than desktop computers. A test that works on an emulator with generous settings might fail on a real low-end device because:
- The app uses too much RAM and the OS kills it
- A heavy animation causes the app to freeze (ANR — Application Not Responding)
- A background process drains the battery quickly
- An expensive operation blocks the UI thread
In practice: Always test on low-end devices, not just flagship phones. Your average user does not have the latest iPhone.
2. Three types of mobile apps
Understanding what kind of app you are testing is the first step to knowing how to test it. There are three main types:
Native apps
A native app is built specifically for one platform using that platform's official programming language and tools:
- iOS native apps are written in Swift or Objective-C using Xcode
- Android native apps are written in Kotlin or Java using Android Studio
Pros:
- Best performance — the app uses the device's hardware directly
- Full access to device features (camera, GPS, NFC, Bluetooth, biometrics)
- The best user experience — follows platform design guidelines (Material Design on Android, HIG on iOS)
- Works offline
Cons:
- You need separate teams/codebases for iOS and Android
- More expensive to develop and maintain
- Updates must go through app store review
Testing approach for native apps:
- Use platform-specific automation tools (XCUITest for iOS, Espresso for Android) or cross-platform tools like Appium
- Test all native interactions: gestures, system dialogs, notifications, background behavior
- Always test on real devices for performance-sensitive features
Mobile web apps
A mobile web app is just a website, but optimized for mobile screens. Users access it through the browser (Chrome, Safari, Firefox). No app store download required.
Pros:
- One codebase works on all platforms (iOS, Android, any browser)
- Instant updates — no app store review needed
- No installation required
- Easy to share via URL
Cons:
- No access to most device hardware features (camera is limited, no NFC, no Bluetooth)
- Performance is worse than native
- No offline support without extra work (Service Workers)
- Browser differences add complexity
Testing approach for mobile web:
- Use browser-based tools like Playwright or Selenium with mobile device emulation
- Test responsive design across different screen sizes
- Test in real mobile browsers (Safari on iOS is very different from Chrome on Android)
- Check touch interactions and viewport behavior
Hybrid and cross-platform apps
A hybrid app is a native shell that displays web content inside a WebView. A cross-platform app is built from one shared codebase but may render native-like UI without being a WebView app.
Popular WebView-based hybrid frameworks include Ionic and Cordova. Popular cross-platform native-style frameworks include React Native and Flutter. From a QA perspective, this distinction matters because locator strategy, performance risks, and debugging tools can be different.
Pros:
- One codebase for iOS and Android (or close to it)
- Can access some native device features through plugins
- Cheaper to develop than separate native apps
- Easier for web developers to transition into mobile
Cons:
- Performance is between native and web
- Some native UI elements look or feel slightly "off"
- Testing is more complex — depending on the framework, you may need native locators, WebView context switching, or framework-specific debug tooling
Testing approach for hybrid and cross-platform apps:
- Appium can handle native screens and WebView contexts
- For WebView-based apps, you may switch from
NATIVE_APPtoWEBVIEW_* - For React Native or Flutter, confirm which locator strategy your framework exposes
- Test native platform behavior separately: permissions, notifications, deep links, and backgrounding
Comparison table
| Characteristic | Native | Mobile Web | Hybrid / cross-platform |
|---|---|---|---|
| Languages | Swift / Kotlin | HTML, CSS, JS | HTML/CSS/JS, JavaScript, Dart |
| Performance | Best | Moderate | Good |
| Device hardware access | Full | Very limited | Partial (plugins) |
| App store required | Yes | No | Yes |
| One codebase | No (2 codebases) | Yes | Yes (mostly) |
| Offline support | Yes | Limited | Yes |
| Testing tools | Appium, Espresso, XCUITest | Playwright, Selenium | Appium, framework tools, sometimes context switching |
| Development cost | High | Low | Medium |
3. iOS vs Android key differences for QA
Both iOS and Android are mobile operating systems, but they work quite differently. As a QA engineer, you need to understand these differences.
App distribution
When you are testing a new build of an app, how does it get to your device?
iOS (Apple):
- Internal testing uses TestFlight — Apple's official beta testing service
- Testers receive an email invitation and install the app through the TestFlight app
- The build must be uploaded to App Store Connect and processed (takes 15–30 minutes)
- Every device must be registered with the developer's account (or use an enterprise certificate)
- This process has more steps and is more restricted
Android (Google):
- Internal testing often uses Firebase App Distribution (free) or a simple shared APK file
- Testers can receive an APK file and install it directly (sideloading)
- Android allows "install from unknown sources" — much more flexible
- Firebase App Distribution provides a web link to download and install the build directly
In practice: Setting up TestFlight for a new tester takes more time than sending them an APK. Make sure you understand your team's distribution process before testing starts.
Automation tool landscape
| Tool | iOS | Android | Notes |
|---|---|---|---|
| Appium | Yes | Yes | Cross-platform, most popular for QA teams |
| XCUITest | Yes | No | Apple's official framework, fast and reliable |
| Espresso | No | Yes | Google's official framework, fast and integrated |
| Detox | Yes | Yes | Popular for React Native apps |
| WebDriverIO | Yes | Yes | JavaScript-based, uses Appium under the hood |
Device fragmentation
iOS: Apple makes all hardware. Current testing matrix is usually:
- The latest 2–3 iPhone generations (iPhone 13, 14, 15 series)
- A couple of iPad models (if your app supports tablets)
- The latest 2 iOS versions (iOS 17, iOS 16)
Android: Hundreds of manufacturers. Your matrix should cover:
- Different screen sizes (small phone, normal phone, tablet)
- Different Android versions (Android 11, 12, 13, 14)
- Different manufacturers (Samsung, Xiaomi, Google Pixel) — they all customize Android differently
- Different hardware tiers (flagship, mid-range, budget)
In practice: Use your app's analytics to find out what devices your actual users have. Test on those, not on the most expensive phones you can find.
Other key differences
| Feature | iOS | Android |
|---|---|---|
| Permission model | Request at runtime, user can only Allow/Deny | Allow/Deny + granular options (allow once, allow always) |
| Back button | No hardware back button (gestures only) | Physical or gesture back button |
| Notifications | Standard, consistent | Can vary by manufacturer |
| Default browser | Safari (WebKit) | Chrome (Blink) |
| Keyboard | iOS keyboard | GBoard or manufacturer keyboard |
| System dialogs | Always appear, cannot be customized | Varies slightly |
4. The mobile testing pyramid
The testing pyramid is a concept that helps teams decide how many tests to write at each level. The idea is: write many fast, cheap tests at the bottom and fewer slow, expensive tests at the top.
/\
/ \
/ UI \ ← Fewest tests (slow, expensive, brittle)
/------\
/ Integ- \
/ ration \ ← Some tests (moderate speed)
/-------------\
/ Unit Tests \ ← Most tests (fast, cheap, stable)
/------------------\
Level 1: Unit tests (base of the pyramid — most tests)
Unit tests check individual functions or small pieces of code in isolation. They are:
- Very fast (milliseconds)
- Written by developers
- Run on every code change
- Examples: "Does the price calculation function return the right number?" or "Does the date formatter display the correct format?"
Level 2: Integration tests (middle of the pyramid)
Integration tests check that different parts of the app work together. They might check that:
- A button tap correctly calls the API
- The data returned from the API is correctly displayed on the screen
- Navigation between screens works correctly
Level 3: UI automation tests (top of the pyramid — fewer tests)
UI tests run the full app and simulate real user interactions. They are:
- Slow (minutes per test)
- Most similar to what a real user does
- Brittle — they break easily when the UI changes
- Best used for the most critical user flows
For mobile, add a fourth layer: Manual and Exploratory testing
Some things are very hard to automate: how the app feels, whether gestures are smooth, how the app behaves during an actual phone call. For these, manual and exploratory testing is still essential.
In practice: Aim for the pyramid shape. If you find yourself writing mostly UI tests and no unit tests, the team is likely spending too much time on slow, expensive testing.
5. What to test on mobile that you do not test on web
Here are the most important mobile-specific test areas that beginners often miss:
Push notifications
Mobile apps can receive push notifications — small messages that appear on the screen even when the app is closed. Test:
- Does the notification appear when it should?
- Does tapping the notification open the correct screen?
- Does the notification appear correctly when the app is in the foreground?
- What happens if the user dismisses the notification?
Deep links
A deep link is a URL that opens a specific screen inside the app. For example, myshop://product/12345 might open the product page for item 12345.
Test:
- Does the deep link open the correct screen?
- What happens if the user is not logged in when following a deep link?
- Does the deep link work from an email, SMS, or browser?
Biometric authentication
Many apps support fingerprint or Face ID login. Test:
- Does biometric login work correctly?
- What happens if biometric authentication fails?
- Can the user fall back to password login?
- What happens when the user has no biometric data enrolled?
App permissions
Mobile apps must ask users for permission to access the camera, location, microphone, contacts, etc. Test:
- Does the app correctly ask for each permission it needs?
- What happens if the user denies a permission?
- Does the app gracefully handle missing permissions without crashing?
- Can the user grant a permission later in Settings?
Background and foreground transitions
Unlike websites, mobile apps continue to exist (in the background) when the user switches to another app. Test:
- Does the app correctly save its state when sent to the background?
- Does the app correctly restore its state when brought back to the foreground?
- What happens to an in-progress form, video, or audio when the app goes to the background?
Official references
- Android Testing Fundamentals — Google's guide to testing Android apps, covering unit, integration, and UI tests
- Apple — Testing Your Apps in Xcode — Apple's official documentation on testing iOS apps
- Firebase App Distribution — Free tool for distributing test builds to testers
Quick recap
| Topic | Key takeaway |
|---|---|
| Why mobile is different | Touch input, device fragmentation, app store process, limited resources |
| Native apps | Best performance, full device access, platform-specific tools |
| Mobile web apps | Cross-platform, no store, limited hardware access |
| Hybrid apps | One codebase, moderate performance, needs context switching in automation |
| iOS vs Android | TestFlight vs Firebase, XCUITest/Espresso vs Appium, much more fragmentation on Android |
| Testing pyramid | Many unit tests, some integration tests, few UI tests, plus manual exploration |
| Mobile-specific areas | Push notifications, deep links, biometrics, permissions, background/foreground |
Practice exercises
-
App type identification: Find 3 apps on your phone. Try to identify whether each is native, web, or hybrid. Hint: if the UI follows the platform style guidelines perfectly, it is likely native. If elements look a bit "web-like," it may be hybrid.
-
Fragmentation research: Go to Android Studio's API dashboard and find the current distribution of Android versions. Which Android version do the most users have? What does this tell you about which OS versions to test on?
-
Testing pyramid audit: Think of a mobile app you use every day (Instagram, WhatsApp, a banking app). Imagine you are the QA engineer. Write down:
- 3 things you would cover with unit tests
- 3 things you would cover with integration tests
- 3 critical user flows you would automate as UI tests
- 3 things you would test manually
-
Mobile-only checklist: Write a checklist of at least 8 tests for a login screen on a mobile app that you would NOT need to test on a web app. Think about permissions, biometrics, background behavior, etc.
-
iOS vs Android comparison: Download the same app on both an iOS device (or simulator) and an Android device (or emulator). Navigate through 3 different screens. Write down 5 visual or behavioral differences you notice. These are things you would need to test separately on each platform.
Next: Lesson 02 — Devices, emulators, and cloud farms (lab02.md)