Mobile Automation at Scale: What Nobody Tells You About Appium

· 4 min read
automationappiummobile-testingengineering

The Tutorial Lie

Every Appium tutorial makes it look straightforward:

  1. Install Appium
  2. Write a test
  3. Run it
  4. 🎉

What tutorials don’t show: the test you just wrote will be flaky by week 3. Your locator strategy will fail when the app updates. Your CI pipeline will have inexplicable 2am failures. And your team will lose faith in the automation faster than you built it.

I’ve been running Appium frameworks in production for 5+ years. Here’s what the tutorials leave out.

Mistake 1: Starting with Locators Instead of Strategy

Most engineers start Appium by writing tests — pick a button, get its ID, click it, assert something. This works for demos. It collapses at scale.

The right starting point is your test architecture:

How many apps?
How often does the UI change?
Who will maintain the tests?
How will you run them in CI?

For Bykea — 3 apps, fast-moving UI, a mixed-experience QA team, and Jenkins CI — the answer was:

  • Page Object Model for every screen
  • Python for maintainability across skill levels
  • BrowserStack for real devices (not emulators)
  • Separate suites for smoke, regression, and nightly

Get this architecture right before writing test #1.

Mistake 2: Trusting Emulators for Production Confidence

Emulators are fine for development. They are not fine for production confidence.

The bugs that slip through emulator-only testing:

  • Gesture handling on budget Android devices (Xiaomi’s custom gesture layer behaves differently)
  • Memory pressure crashes (emulators don’t simulate real memory constraints)
  • Network condition variations (critical for a ride-hailing app)
  • Notification interactions on locked screens

We switched to BrowserStack real devices after our second production crash that we’d missed on emulators. The subscription pays for itself in the first quarter.

For Pakistani market apps specifically: Test on Samsung Galaxy A series, Xiaomi Redmi devices, and Tecno/Infinix. These are the dominant device categories your users actually have.

Mistake 3: Not Treating Test Code Like Production Code

Your automation codebase will become unmaintainable if you treat it as “just test scripts.” Apply the same standards:

  • Code review for every PR (yes, even test code)
  • Refactoring cycles — Page Objects accumulate technical debt too
  • Naming conventions — test_user_can_book_ride_successfully beats test_booking_flow_v2_final
  • Documentation — comment why, not what

At Bykea, I introduced a quarterly “test debt sprint” — one sprint per quarter focused entirely on improving the automation foundation. It kept the framework healthy as the app evolved.

Mistake 4: Building Before Establishing Trust

Here’s the uncomfortable truth: a CI pipeline your team doesn’t trust is worse than no pipeline.

When tests fail, if engineers assume “probably a flaky test” before “probably a real bug,” your automation isn’t adding value — it’s adding noise.

How to build trust:

  1. Zero tolerance for flaky tests. When a test flakes, fix it or delete it. Never ignore it.
  2. Fast feedback. If your smoke suite takes 2 hours, nobody waits for it.
  3. Clear failure messages. “Element not found” is not a useful failure. “Login button not visible on Samsung Galaxy A52” is.
  4. Track flakiness rates. Make it visible. Make it a metric you actively reduce.

What Actually Works: The Layered Strategy

The architecture that works for high-velocity apps:

Layer 1: API Tests (5-10 min)
→ Runs on every commit
→ Validates backend contracts
→ Fast and reliable

Layer 2: Smoke Tests (15-20 min)
→ Runs on every PR merge
→ Critical user journeys only
→ Real devices on BrowserStack

Layer 3: Full Regression (3-4 hours)
→ Runs nightly
→ Complete coverage
→ Generates detailed Allure reports

Layer 4: Exploratory Testing
→ Human-driven
→ Focuses on new features and edge cases
→ No automation (by design)

Most teams try to automate everything, then wonder why maintenance is overwhelming. Automate the reliable, test the complex manually.

The Metric That Matters

Not: How many tests do you have?

Yes: How often do your tests find real bugs before humans do?

Track this. If your automation is finding bugs that would have otherwise reached production, it’s working. If it’s just validating what developers already knew works, refocus your test coverage.

Mobile automation done right is a force multiplier for your engineering team. Done wrong, it’s a maintenance burden that erodes trust in automated quality entirely. Choose the architecture before writing the code, and the code will take care of itself.

All articles