Lesson 2 of 4
Lesson 02 — Testing Environments
Title: Emulators, real devices, and cloud farms — choosing the right environment
Description: Learn the differences between Android emulators, iOS simulators, physical devices, and cloud device farms, and understand when to use each one for effective mobile testing.
Why it matters for QA: Choosing the wrong testing environment leads to two problems: wasting time on setup that does not reflect real user conditions, or missing bugs that only appear on real hardware. A good QA engineer knows when to use a free emulator and when a real device is absolutely necessary.
1. Android Emulator vs iOS Simulator
When you first start mobile testing, you do not need to buy a device. You can use a software emulator or simulator on your computer.
What is the difference?
These words are often used interchangeably, but they mean different things:
Android Emulator (technically an emulator):
- Runs a full copy of the Android operating system inside a virtual machine
- Simulates the hardware of a real Android device
- Included in Android Studio for free
- Slower to start, but more accurate to real device behavior
iOS Simulator (technically a simulator):
- Simulates the behavior of an iPhone or iPad, but does NOT run the actual iOS code
- Runs iOS app code compiled for Mac (not ARM like a real iPhone)
- Included in Xcode for free (macOS only)
- Faster than the Android emulator, but less accurate
In practice: You need a Mac to run the iOS Simulator. There is no official way to simulate an iPhone on Windows or Linux. This is one reason Android testing is often easier to set up.
How to create an emulator in Android Studio
- Open Android Studio
- Click More Actions → Virtual Device Manager
- Click Create Device
- Choose a device type (e.g., Pixel 6)
- Choose an Android version (e.g., API 33 — Android 13)
- Click Finish — the emulator will download and be ready to use
How to create a simulator in Xcode
- Open Xcode
- Go to Window → Devices and Simulators
- Click the Simulators tab
- Click the + button
- Choose a device (e.g., iPhone 15) and iOS version
- Click Create — the simulator appears in the list
What emulators and simulators are good for
- Running quick smoke tests during development
- Testing new features before a real device is available
- Testing on many different OS versions without owning every device
- Running tests in CI/CD pipelines where physical devices are not practical
- Testing screen layouts and responsive design
What emulators and simulators cannot test
This is the critical part. Here is what you cannot reliably test on an emulator or simulator:
| What to test | Emulator/Simulator | Real device needed? |
|---|---|---|
| Basic app functionality | Works well | Not required |
| UI layout and navigation | Works well | Not required |
| Screen rotation | Works | Not required |
| Camera (photo/video) | Limited — no real camera input | Required |
| GPS and location | Can be simulated with fake coordinates | Required for accuracy |
| NFC (tap to pay, etc.) | Not supported | Required |
| Bluetooth | Not supported | Required |
| Fingerprint / Face ID | Can be simulated | Required for accuracy |
| Phone calls and SMS | Partially supported | Required |
| Real network conditions | Simulated | Required |
| Thermal throttling (overheating) | Not applicable | Required |
| OEM-specific UI (Samsung One UI, etc.) | Not applicable | Required |
| Real-world performance | Unreliable — your computer is faster | Required |
| Battery behavior | Not applicable | Required |
| Physical gestures (precision tapping) | Works differently | Required |
In practice: Use emulators for fast feedback loops during development. But before any release, always run your critical test scenarios on real devices.
2. Real physical devices
At some point, you must test on a real phone or tablet. Real devices reveal problems that emulators simply cannot show.
When you MUST test on a real device
- Camera features: Scanning barcodes, taking photos, video calls — these require a real camera
- Bluetooth: Pairing with headphones, speakers, or other devices
- NFC: Contactless payments, NFC tag scanning
- Biometric authentication: Real fingerprint readers and Face ID behave differently from simulations
- Performance testing: App speed, animation smoothness, memory usage under real conditions
- OEM-specific behaviors: Samsung adds features to Android that vanilla Android emulators do not have
- Real network switching: Going from WiFi to cellular, or losing network connectivity
Setting up an Android device for testing (USB debugging)
Before you can connect an Android phone to your computer for testing, you need to enable USB debugging. This is a developer setting hidden by default.
Step 1: Enable Developer Options
- Open Settings on your Android phone
- Go to About phone
- Find Build number (it may be under "Software information")
- Tap Build number 7 times — you will see a message "You are now a developer!"
Step 2: Enable USB debugging
- Go back to Settings
- You will now see a new menu called Developer options
- Open it and find USB debugging
- Toggle it On
- Tap OK on the confirmation dialog
Step 3: Connect your device
- Connect your phone to your computer with a USB cable
- A dialog will appear on your phone: "Allow USB debugging?"
- Check "Always allow from this computer" and tap Allow
- Open a terminal and run
adb devices— your device should appear in the list
Setting up an iOS device for testing
Testing on a real iPhone is more complex because Apple requires you to sign the app with a certificate.
For basic testing (without Xcode):
- Use TestFlight — the tester receives an invite and installs the build from the TestFlight app
- No developer account needed on the tester's side, just an Apple ID
For Xcode development testing:
- Connect your iPhone with a USB cable
- Open Xcode
- Go to Window → Devices and Simulators
- Your device should appear — click Trust on the phone when prompted
- In Xcode, select your device as the build target
- You need an Apple developer account to sign the app (free accounts can test on personal devices)
Managing a small device lab
If you are a QA engineer at a company, you may need to manage a small collection of test devices. Here are some recommendations:
Recommended minimum (3–6 devices):
- 1 recent iPhone (latest iOS)
- 1 older iPhone (1–2 versions behind)
- 1 Samsung Galaxy (most popular Android brand)
- 1 Google Pixel (pure Android, reference device)
- 1 budget Android phone (low RAM, older processor)
- 1 tablet (if your app supports tablets)
Device management tips:
- Keep devices charged and on the same WiFi network
- Label each device with its model and OS version
- Create a shared account for test apps (do not use personal Apple IDs)
- Update OS versions carefully — document the current OS version of each device
- Wipe devices between major test runs to start with a clean state
3. Cloud device farms
Imagine you could run your tests on 50 different real devices simultaneously, without owning any of them. That is what a cloud device farm provides.
What is a cloud device farm?
A cloud device farm is a service where you can remotely access real physical devices (or emulators) to run your tests. Your test code runs on their servers and controls the devices remotely.
Major cloud device farm providers
| Provider | Best known for | Free tier? |
|---|---|---|
| BrowserStack App Automate | Very popular, great documentation, Appium support | Free trial |
| Sauce Labs | Strong CI/CD integrations, large device selection | Free trial |
| AWS Device Farm | Integrates with AWS ecosystem, pay-per-minute | Limited free tier |
| Firebase Test Lab (Google) | Free for limited use, great for Android, integrated with Firebase | Free tier |
| LambdaTest | Competitive pricing, growing device library | Free tier |
Benefits of cloud device farms
- Parallelism: Run your tests on 10 devices at the same time, reducing total test time by 10x
- No maintenance: You do not need to buy, charge, update, or troubleshoot devices
- Access to rare devices: Test on a Samsung Galaxy Fold or an old iPhone 8 without owning them
- Video recordings: Most farms record video of every test run for debugging
- Automatic screenshots: Screenshots are taken at each test step
- Detailed logs: Device logs, app logs, and network logs are captured automatically
Drawbacks of cloud device farms
- Cost: Can become expensive at scale. Some teams spend thousands of dollars per month
- Network latency: Your test commands travel over the internet to the device, adding delay
- Queue waiting: Popular device configurations (iPhone 15, iOS 17) may have a wait queue during busy hours
- Setup complexity: Integrating with your CI/CD pipeline requires configuration
- Privacy concerns: Your app binary and test data go through a third-party server
- Device state: Shared devices may have unexpected state from previous users (farms should reset between sessions, but bugs happen)
How to choose the right cloud farm
Consider these questions:
- What platforms? iOS-heavy teams often prefer BrowserStack (excellent iOS support). Android-heavy teams might use Firebase Test Lab (free, Google-native)
- What budget? Firebase Test Lab is cheapest for Android (free tier available)
- CI/CD integration? AWS Device Farm integrates naturally with GitHub Actions and other AWS services
- Appium support? All major farms support Appium, but check the documentation for your specific version
In practice: For a beginner or small team, start with Firebase Test Lab for Android (it is free for up to 5 virtual device tests per day) and BrowserStack's free trial to understand how farms work before committing to a paid plan.
4. Android Debug Bridge (adb) — your Swiss army knife
adb (Android Debug Bridge) is a command-line tool that lets you communicate with a connected Android device or emulator. It comes bundled with Android Studio and is essential for Android QA work.
Think of adb as a direct communication channel between your computer and an Android device. With it, you can install apps, capture screenshots, read logs, and much more.
How to install adb
If you have Android Studio installed, adb is already on your computer. You just need to add it to your system PATH:
- Mac/Linux: Usually at
~/Library/Android/sdk/platform-tools/adb - Windows: Usually at
C:\Users\YourName\AppData\Local\Android\Sdk\platform-tools\adb.exe
Alternatively, download Platform Tools directly from the Android developer site.
The most useful adb commands for beginners
# List all connected Android devices and emulators
# Use this to confirm your device is recognized
adb devices
# Install an APK on a connected device
# Replace 'app-debug.apk' with the path to your APK file
adb install app-debug.apk
# Reinstall (update) an existing app without losing its data
adb install -r app-debug.apk
# Take a screenshot on the device and save it to your computer
adb shell screencap -p /sdcard/screenshot.png
adb pull /sdcard/screenshot.png ./screenshot.png
# Record a screen video (press Ctrl+C to stop recording)
adb shell screenrecord /sdcard/test_video.mp4
adb pull /sdcard/test_video.mp4 ./test_video.mp4
# View live device logs (useful for debugging test failures)
# Press Ctrl+C to stop
adb logcat
# Filter logs to show only your app's output
adb logcat -s "MyShopApp"
# Clear all app data (useful for testing first-launch behavior)
# Replace 'com.your.app.package' with the actual package name
adb shell pm clear com.your.app.package
# Uninstall an app
adb uninstall com.your.app.package
# Get the package name of a running app
adb shell dumpsys window | grep mCurrentFocus
# Simulate pressing the back button
adb shell input keyevent 4
# Simulate pressing the Home button
adb shell input keyevent 3
# Send a text input to the focused field
adb shell input text "hello world"
# Reboot the device
adb rebootIn practice: The command you will use most often is adb devices to confirm your device is connected, and adb logcat to read device logs when a test fails unexpectedly.
5. Practical recommendation: which setup to use when
Here is a simple decision guide based on what you need to test:
| Situation | Recommended environment |
|---|---|
| Developer testing a new feature quickly | Android Emulator / iOS Simulator |
| Running automated tests in CI pipeline | Emulator or cloud farm |
| Testing on many OS versions | Cloud device farm |
| Testing camera, Bluetooth, NFC | Real physical device |
| Testing real performance and battery | Real physical device |
| Testing OEM-specific behavior (Samsung, Xiaomi) | Real device of that brand OR cloud farm |
| Parallel testing (10+ devices at once) | Cloud device farm |
| Testing on a tight budget | Emulator for most things, 2-3 owned devices for hardware features |
| Pre-release final check | Real physical devices (your most important OS/device combinations) |
Summary flowchart
Is the feature hardware-dependent?
(camera, Bluetooth, NFC, biometrics, real GPS)
|
YES → Use a real physical device
|
NO
|
Do you need many OS versions / devices?
|
YES → Use a cloud device farm
|
NO
|
Use an emulator/simulator (free, fast, good enough)
Official references
- Android Emulator — Getting Started — Official guide to setting up and using the Android emulator
- adb — Android Debug Bridge documentation — Complete reference for all adb commands
- Firebase Test Lab — Google's cloud testing service, free tier available for Android
Quick recap
| Environment | Best for | Limitations |
|---|---|---|
| Android Emulator | Fast feedback, CI automation, layout testing | No real camera, Bluetooth, NFC, thermal throttling |
| iOS Simulator | Fast feedback on macOS, layout testing | macOS only, no real hardware features, less accurate |
| Real device | Hardware features, real performance, OEM behaviors | Costs money, requires setup, limited parallelism |
| Cloud device farm | Scale, parallelism, rare devices, CI integration | Costs money, network latency, privacy considerations |
| adb | Android device communication, log capture, file transfer | Android only |
Practice exercises
-
Set up an emulator: Install Android Studio and create a Pixel 6 emulator running Android 13. Launch it and take a screenshot using
adb screencap. Confirm the screenshot appears on your computer. -
adb exploration: If you have an Android phone, enable USB debugging and connect it to your computer. Run
adb devices,adb logcat, andadb shell pm list packages(this shows all installed apps). Take notes on what each command outputs. -
Cloud farm trial: Create a free account on BrowserStack or Firebase Test Lab. Browse the available devices. Note: which Android versions are available? Which iPhone models are available? How long is the queue for the most popular devices?
-
Device matrix exercise: Imagine you are testing a popular food delivery app. Your analytics show:
- 60% Android users, 40% iOS users
- Top Android devices: Samsung Galaxy S21, Xiaomi Redmi Note 10, Samsung Galaxy A52
- iOS devices: iPhone 12, iPhone 14, iPhone 11
- OS versions: Android 11 (30%), Android 12 (28%), Android 13 (22%), iOS 16 (40%), iOS 17 (35%)
Based on this data, design a 6-device test matrix. Which devices would you choose and why?
-
adb commands cheatsheet: Without looking at this lesson, write down from memory the
adbcommand to: (a) list devices, (b) install an APK, (c) clear app data, (d) capture a screenshot, (e) view logs. Check your answers against the lesson.
Next: Lesson 03 — Test design for mobile (lab03.md)