What it does
Routes the surface from tooling.mobile (native/cross-platform via Appium or device farm, vs responsive mobile-web handed to mobile-test), builds the device/OS matrix from config, and automates the applicable CT-MAT concerns: functional flows via accessibility IDs, gestures, app lifecycle and interrupts, network conditions, platform differences, install/upgrade and on-device performance. Uses per-platform screen objects, stable accessibility-ID locators, synthetic data, and parallel CI runs; emits a device-matrix traceability table.
When to use it
For mobile test automation — iOS/Android native or cross-platform apps (or mobile web), automating a feature or flow on device.
Prerequisites
qa.config.yml; tooling.mobile set (route to tool-select if unset); tooling.mobile_device_matrix; native: Appium/device farm config; test_data; CI platform.
Output
Test Procedure Specification (ISO/IEC/IEEE 29119-3) + Test Execution Log under paths.reports_dir, tests under paths.tests_dir/mobile/, plus a device-matrix coverage table.
Mechanics
How it works
- Guard config and resolve the target flow (and surface) as test basis
- Route the mobile surface from tooling.mobile (native vs web vs tool-select)
- Build the real-vs-emulated device/OS matrix from config
- Automate the applicable CT-MAT concerns for the flow
- Engineer per-platform screen objects with stable accessibility IDs
- Use synthetic data; run device parallelism in CI
- Run, fix test defects, escalate product defects via triage
- Emit the device-matrix traceability table with residual gaps
Why it works
The theory behind it
CT-MAT executed through CT-TAE; mobile UI automation is system-level and expensive, so the test pyramid still applies — only genuine end-to-end flows belong on-device.
CT-MAT (Specialist) · CT-TAE
Example
See it in use
> /qa:mobile-automate "checkout" web✓ Correct when Tests cover the mobile_device_matrix (e.g. iPhone 14, Pixel 7) viewports/touch.