How do you build and govern a mobile testing strategy across multiple product squads?

Policy layer: produce a Mobile Quality Standard document that specifies: minimum supported OS versions, mandatory unit test coverage per feature, required Appium test scenarios for new critical paths, the device matrix, and the CI gates (PR gate on emulator, nightly on real devices). Make this part of the engineering handbook and review it quarterly.

Shared infrastructure: individual squads should not each manage their own Appium server, device farm account, or CI pipeline configuration for mobile. Provide a shared service: a maintained Appium config, a device farm organisation account with role-based access, shared screen object base classes in a published internal package, and a dashboard that shows test health across all mobile projects.

Metrics that matter at lead level: crash-free session rate (from Firebase Crashlytics or Sentry) is the ultimate quality signal — a crash a user encounters matters far more than a test pass rate. Track crash-free rate per OS version and per device model to identify fragmentation issues. Also track time-to-green on the mobile CI gate — if mobile tests take 45 minutes, squads will bypass them.

Squad autonomy vs central standards: squads own their screen objects and test cases. Central QA owns the base classes, the device matrix definition, and the farm configuration. When a squad wants to deviate from the device matrix (e.g. add a niche device their users love), they make a case to central QA rather than adding it unilaterally.

Handling release confidence: establish a release checklist that requires sign-off from a QA lead on: nightly suite green on the top device matrix, zero open critical bugs, crash rate stable or improving versus the previous release. This is a process gate, not a technical gate — it requires human judgment.