•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
You have an app. You need to test it. You're not sure where to start.
Most guides on this topic list 12 abstract steps ("define objectives," "identify requirements," "develop a test strategy") that read like a project management textbook. This is different. It's the practical sequence a QA engineer or developer follows when testing a mobile app for the first time, starting from "I have a build file and no testing process" and ending at "my tests run automatically before every release."
If you want the background first — what mobile app testing covers, how it differs from web testing, and which types matter — start with our guide to mobile app testing and come back here for the sequence.
Before you test anything, decide which devices you're testing on. This is the decision that determines whether your testing catches real user bugs or only catches bugs on your personal phone.
Check your analytics. If you use Firebase, go to Analytics > Demographics > Device model. If you use Mixpanel or Amplitude, look at the device breakdown report. You'll see which phones your users actually have. For most apps targeting India and Southeast Asia, you'll see Samsung Galaxy A-series, Xiaomi Redmi, Realme, and a mix of iPhones. For US-focused apps, it's iPhone, Samsung Galaxy S-series, and Pixel.
Pick at least 4 devices:
If you don't have physical devices, use emulators and simulators for development and a cloud platform for real-device testing before release.
Get the build file (APK for Android, IPA for iOS) onto your test device. On Android, sideload the APK or use Firebase App Distribution. On iOS, use TestFlight or install directly from Xcode.
Once installed, do a quick smoke test: launch the app, sign up or log in, navigate to the main screens, and confirm core flows work. This takes 10-15 minutes. If the app crashes at launch or login is broken, stop. Send it back to development. There's no point in deeper testing on a build that can't complete basic flows.
This first pass answers one question: is this build stable enough to test?
Now you know the build is stable. Next, document what you're going to test. For each core flow (login, search, checkout, payment, onboarding), write a test case that includes: preconditions (user is logged out, Wi-Fi connected, test account exists), steps (tap email field, type credentials, tap Login), and expected result (home screen loads within 3 seconds, welcome message shows the user's name).
If you're starting from zero, focus on 10-15 test cases covering the flows that matter most. Don't try to cover everything. Cover the paths that cost you money or users when they break: login, core feature, checkout, and payment.
For a reusable format, use our test case template. For organizing multiple test cases into a release plan, use our test plan template.
Run through each test case on one device. This is manual testing. Open the app, follow the steps, check the results. Document what passes and what fails. Take screenshots of failures.
While you're at it, do some exploratory testing. Don't just follow the script. Try things the test case didn't anticipate: paste a 500-character string into a field, rotate the device mid-form, kill the app during a payment, switch between Wi-Fi and cellular. Set a timer for 20 minutes and explore. You'll find bugs that scripted test cases never would have covered.
Record your findings in a session charter (see our exploratory testing guide for a template).
Now run the same core test cases on the other 3 devices in your matrix. You'll find bugs that only appear on specific hardware:
These are bugs that emulators can't catch. Testing on one device catches code bugs. Testing on four catches device bugs. Our guide to mobile app testing on real devices covers how to size a device matrix without buying hardware for every model.
After a few manual test cycles, you'll notice a pattern: every sprint, you're running the same 10-15 smoke and regression tests by hand. That's the automation signal.
Automate tests that are repeatable, deterministic, and run more than 5 times. Start with smoke tests (10-15 tests, core flows, run on every build). Then add regression tests (tests for features that previously broke, run on every PR).
The tool you pick depends on your team. If you have automation engineers comfortable with code, Appium or Espresso work. If your team includes manual QA or PMs who should contribute tests, plain-English tools lower the barrier. With Drizz, a test is plain English: "Tap on Login," "Type 'user@test.com' in the email field," "Validate 'Welcome' is visible." Vision AI executes the steps on real devices. No selectors. No Appium Inspector workflow. The popup agent handles OEM dialogs. Self-healing adapts when the UI changes.
Morgan Ellis, a QA Engineering Lead, described the difference: "Writing tests in plain English made automation something the whole team could contribute to. We shipped 20 tests in a single day."
For a deeper comparison of automation tools, see our mobile test automation tools comparison.
The final step is making tests automatic. Instead of a person triggering tests manually, your CI/CD pipeline triggers them on every build.
Set up your pipeline (GitHub Actions, Jenkins, Fastlane) so that:
This is shift-left testing in practice: testing happens automatically, early, and on every change. No manual trigger. No "we'll test it on Friday." Testing is part of the build process.
After release, monitor crash-free rates in production. When a production bug is found, write a regression test for it. The bug gets fixed, the test prevents it from returning, and the suite grows with tests grounded in real user failures.
Steps 1-5 can start today with zero tooling. Steps 6-7 require a testing tool and a CI pipeline. The whole process scales from "one person testing on their phone" to "an automated suite running on real devices before every release."
For the wider picture — what mobile app testing involves, the types of testing to run, and how teams structure coverage — see our complete guide to mobile app testing. For the full testing strategy (what types of tests, which tools, what cadence), see our test automation strategy.
Start with manual testing. Install the app on a real device, walk through core flows (login, main feature, checkout), and document what breaks. No tools needed. See step 2 above.
10-15 covering your core flows. Don't try to cover everything. Cover the paths that cost you money or users when they break: login, onboarding, core feature, checkout, and payment.
Both. Emulators for daily development (fast, free). Real devices before release (accurate, catches OEM-specific bugs). At minimum, test on one Samsung, one Pixel, one budget device, and one iPhone.
When you notice you're running the same 10-15 tests manually every sprint. Automate those first (smoke and regression), then expand. Don't automate before you have stable test cases.
A manual smoke test takes 10-15 minutes per device. Full manual testing across 4 devices takes 2-4 hours. An automated smoke run takes 2-3 minutes. Automated regression across 5 devices runs in 20-30 minutes.
Manual testing is a person following test steps on a device. Automated testing is a script or AI executing those steps. Manual finds unexpected bugs through exploration. Automated prevents known bugs from returning through regression. You need both.
©Drizz 2026 • All Rights Reserved
