Most mobile testing tutorials are either 30-page reference guides or Appium installation walkthroughs. This one is neither. It's a single walkthrough that follows one app (a food delivery app called FoodDash) from "I just got the APK" to "my tests run automatically before every release." You can follow along with your own app by substituting your flows for FoodDash's.
If you want definitions and concepts, see our what is mobile app testing guide. If you want a step-by-step process without the tutorial context, see how to do mobile app testing. This tutorial assumes you know nothing and walks you through doing it.
Part 1: set up your test environment (15 minutes)
You need two things: the app and a device.
The app. Get the APK (Android) or IPA (iOS) from your developer. If you're testing an app already in the Play Store or App Store, download it from there. For this tutorial, we're working with FoodDash v4.2, a food delivery app with login, restaurant browsing, cart, checkout, and order tracking.
The device. Use a real phone if you have one. A Samsung or Xiaomi is ideal because OEM-specific bugs are most common on these devices. If you don't have a spare phone, use the Android Emulator in Android Studio or the iOS Simulator in Xcode. For a deeper comparison of when to use each, see our emulator vs simulator guide.
Install the app on your device. On Android, you can sideload the APK by enabling "Install from unknown sources" and opening the file. On iOS, use TestFlight or install directly from Xcode.
Open the app. Make sure it launches. If it crashes at launch, stop here and send it back to development.
Part 2: manual smoke test (10 minutes)
Before doing anything structured, walk through the app like a user would. This is your smoke test: a quick check that the core paths work.
For FoodDash, that means:
- Launch the app
- Sign up with a new account (or log in with an existing one)
- Browse the restaurant list
- Tap a restaurant and view the menu
- Add an item to the cart
- Go to the cart and verify the item is there
- Tap "Checkout" and verify the checkout screen loads
- Go back to the home screen
That's it. You're not testing edge cases. You're confirming the app doesn't crash on the main paths. If any of these steps fail, the build isn't ready for deeper testing. File the bug and wait for a fix.
Write down what you did and what happened. Even informal notes ("login worked, restaurant list loaded slow, checkout screen froze for 2 seconds") are useful.
Part 3: write your first 5 test cases (20 minutes)
Now formalize what you just did. Take the smoke test flow and turn it into structured test cases.
Here are 5 test cases for FoodDash. Each one follows the format from our test case writing guide: one action per step, device in preconditions, exact screen text, measurable expected result.
TC-001: Successful login. Preconditions: Samsung Galaxy A14, Android 13, Wi-Fi, app installed, user logged out. Steps: Launch app. Tap email field. Type "user@test.com." Tap password field. Type "Test@1234." Tap "Log in." Expected: Home screen loads in under 3 seconds. Header shows "Welcome, User."
TC-002: Add item to cart. Preconditions: User logged in, on home screen. Steps: Tap first restaurant. Tap first menu item. Tap "Add to Cart." Tap cart icon in bottom nav. Expected: Cart screen shows 1 item. Item name and price match the menu.
TC-003: Checkout screen loads. Preconditions: User logged in, 1 item in cart. Steps: Tap "Proceed to Checkout." Expected: Checkout screen loads within 2 seconds. Delivery address field is visible. Payment method section is visible. Total matches cart total.
TC-004: Apply promo code. Preconditions: User on checkout screen, promo code "SAVE20" is active. Steps: Tap promo code field. Type "SAVE20." Tap "Apply." Expected: Discount line shows "-20%." Total updates to the discounted amount.
TC-005: Empty cart message. Preconditions: User logged in, cart is empty. Steps: Tap cart icon. Expected: Cart screen shows "Your cart is empty" message. "Browse Restaurants" button is visible.
These 5 test cases cover the core revenue path: login, browse, cart, checkout, promo. If any of these break, users can't complete an order.
Part 4: run an exploratory session (20 minutes)
Test cases cover the expected paths. Exploratory testing covers the unexpected ones.
Set a timer for 20 minutes. Open FoodDash on your device. Your mission: try to break the checkout flow.
Here's what to try:
- Add 10 items to the cart, then remove 9. Does the total update correctly each time?
- Apply a promo code, then remove the item that qualifies for it. Does the discount disappear? Does the app explain why?
- Start the checkout, then rotate the device to landscape. Do the form fields keep their values?
- Start the checkout, get a phone call (or simulate one), come back. Is the checkout state preserved?
- Switch from Wi-Fi to mobile data mid-checkout. Does the app handle the network change?
- Set your device's font size to "Large" in system settings. Do any button labels truncate or overflow?
Write down everything you find. Use a session charter format: mission, time-box, device, bugs found, notes.
The first time I ran this session on a Samsung Galaxy A14, I found that the "Place Order" button disappeared behind the keyboard when the address field was focused. The button worked on a Pixel. It didn't work on the Samsung because One UI handles keyboard insets differently. That bug was invisible in the emulator. It only showed up on the real Samsung hardware.
Part 5: test on a second device (15 minutes)
Run your 5 test cases on a different device. If you tested on a Samsung, now test on a Pixel or an iPhone. If you only have one phone, use the emulator for the second run.
You're looking for differences. The same app, the same test steps, but different results on different hardware. Common findings:
- Font rendering makes labels longer or shorter on different devices
- Navigation bar height changes on OEM skins, pushing buttons off screen
- Performance differs: a budget phone with 3 GB RAM might show visible lag on screens that were instant on a flagship
Document every difference. These device-specific bugs are the ones users report and the ones emulator-only testing misses.
Part 6: automate your smoke tests (30 minutes)
You've been running the same 5 test cases manually. That works for one sprint. It doesn't scale. When you catch yourself running the same tests by hand for the third time, it's time to automate.
The fastest path to automation for the test cases above is plain-English authoring. In Drizz, TC-001 (successful login) becomes:
Launch the app
Tap on the email field
Type "user@test.com"
Tap on the password field
Type "Test@1234"
Tap "Log in"
Validate "Welcome" is visible
That's it. No Appium setup, no selector harvesting through Inspector, no page objects. Upload the APK to Drizz, paste the steps, and run. The test executes on a real device in the cloud. Rachel Bennett, a Release Manager, described it: "What surprised me most was how quickly the team supported our rollout with fast answers, practical guidance, and it scaled across the org without friction."
Convert all 5 test cases into plain-English steps. Run them. Fix any that fail (usually because the expected text doesn't match the screen exactly). Now you have an automated smoke suite.
For other automation approaches (Espresso, XCUITest, Flutter testing), see our platform-specific guides.
Part 7: plug into CI/CD (30 minutes)
The last step is making the smoke suite run automatically on every build. This is where testing becomes a permanent part of your release process instead of something someone remembers to do on Friday.
In your CI pipeline (GitHub Actions, Jenkins, Fastlane), add a step after the build that triggers your smoke tests. If using Drizz, this is an API call:
- Upload the new APK (POST /apk/upload)
- Trigger the test plan (POST /testplan/run)
- Wait for results
- If pass: continue to beta distribution
- If fail: block the build, notify the developer
Now every build gets tested on real hardware before anyone touches it. Broken builds are rejected in minutes. The developer gets screenshots showing exactly what failed and on which device.
For the full pipeline architecture, see our mobile CI/CD guide. For how this fits into a broader testing strategy, see our test automation strategy.
What you've built
If you followed all 7 parts, you now have:
- A device matrix (at least 2 devices)
- 5 structured test cases for your core revenue path
- An exploratory session charter with device-specific findings
- An automated smoke suite that runs on real devices
- A CI pipeline that blocks broken builds
That's a complete mobile testing practice. It's small, but it's real. Grow it by adding regression tests for every bug you fix, running performance benchmarks on budget devices before release, and monitoring crash-free rates in production. For the full set of best practices, see our mobile testing best practices guide.
FAQ
How long does it take to learn mobile app testing?
You can run your first manual test in 15 minutes by following Parts 1-2 above. Writing structured test cases takes a day. Automating and plugging into CI takes a week. Building a mature practice with regression, performance, and monitoring takes 1-2 months.
Do I need coding skills for mobile app testing?
For manual testing, no. For automation with Appium or Espresso, yes (Java, JavaScript, or Kotlin). For automation with plain-English tools like Drizz, no. The test IS the plain English.
What's the difference between this tutorial and an Appium tutorial?
Appium tutorials teach you one specific automation framework. This tutorial covers the full testing practice from manual testing through automation and CI. Appium is one tool you could use at the automation step. It's not the only one.
Can I follow this tutorial with an iOS app?
Yes. Substitute the Android Emulator with the iOS Simulator, sideloading with TestFlight, and Espresso with XCUITest. The test cases, exploratory sessions, and CI pipeline steps are the same.
What should I test first on a new mobile app?
The revenue path. Login, core feature, checkout, payment. If these break, the business loses money. Start there and expand to edge cases, device coverage, and non-functional testing after the core is covered.
How many test cases do I need?
Start with 5-10 covering the core flows. A mature app typically has 100-300 across functional, regression, and compatibility categories. Don't try to cover everything at once.
