Maestro E2E
Purpose
Verify critical mobile journeys end-to-end on a device/emulator using Maestro — the few flows whose breakage blocks release — plus fast smoke flows for post-build/deploy confidence. The mobile pack's ../../mobile/mobile-maestro-e2e owns mobile-side detail; this testing-pack skill places Maestro in the cross-project testing strategy.
When to Use
- For business-critical mobile journeys (onboarding, login, core transaction) and smoke checks.
- Not for logic (
unit-testing), component behavior (Testing Library / ../../mobile/mobile-component-testing), or web (playwright-e2e).
Inputs
- Selected mobile app + critical flows (
testing-selection, ../../mobile/mobile-stack-selection).
- Build to test against + device/emulator (
../../mobile/mobile-builds), seeded backend state (test-data-management).
Discovery Questions
- Which mobile flows are critical enough for device E2E (few, high-value)?
- Which minimal flows form the smoke set (app launches, logs in, core screen loads) for post-deploy checks?
- What backend/test state must exist for the flows to run deterministically?
Responsibilities
- Take the behavior to be covered from its Gherkin scenarios (
gherkin-specifications) — implement one test per scenario rather than inventing a parallel case list.
- Cover critical device journeys: happy path through the real app, plus key error and authorization-denied variants at the journey level.
- Define a smoke set: minimal, fast flows proving the build is fundamentally alive (launch → auth → primary screen) — run after builds/deploys (
smoke-testing, ../../devops/production-readiness).
- Use Maestro's resilient waiting (element-based, not fixed sleeps); stable selectors (ids/accessibility labels —
../../mobile/mobile-accessibility).
- Control backend/test state deterministically (
test-data-management); run on emulator/simulator in CI where feasible (../../devops/ci-cd, ../../mobile/mobile-builds).
- Keep the set small — top of the mobile pyramid; push detail to component/unit tests.
Required Workflow
- Select critical flows + define the smoke set.
- Ensure a testable build + deterministic backend state.
- Script flows with element-based waits + stable selectors.
- Wire E2E + smoke into CI/build pipeline.
- Keep small; move detail down the pyramid.
Decision Rules
- Device E2E for whole-journey integration only; component-level cases go to
../../mobile/mobile-component-testing.
- Smoke flows stay minimal and fast — they gate deploys, not features.
- Element-based waits, never sleeps (flakiness —
flaky-test-audit).
- A flaky device test is worse than none — stabilize or cut.
Rules
- Deterministic backend/test state per run.
- Runs against a real build on device/emulator.
- Failures produce logs/screenshots for triage.
Anti-Patterns
- E2E-testing every screen/edge on device.
- Fixed sleeps to paper over timing.
- Selectors tied to volatile UI text.
- Smoke sets that balloon into full regression suites.
- Duplicating component coverage on device.
Validation Checklist
Definition of Done
A small, stable Maestro suite covering critical mobile journeys and a fast smoke set — happy path plus key error/denial variants — with resilient waits, deterministic state, and CI/build integration.
Related Skills
../../mobile/mobile-maestro-e2e, testing-selection, playwright-e2e, smoke-testing, ../../mobile/mobile-component-testing, test-data-management, flaky-test-audit, ../../devops/ci-cd, ../../devops/production-readiness.
Related Knowledge
../../../knowledge/ (critical mobile flows).
Related References
../../../references/testing/ (mobile E2E patterns, when populated).
Context Loading Guidance
- Requires: critical mobile flow list, testable build, backend seed strategy.
- Does not require: unit internals, unrelated screens.
- May load:
../../mobile/mobile-maestro-e2e, smoke-testing.
- Stop when: critical flows + smoke set pass stably in CI.
Token Efficiency Guidance
The flow list (critical + smoke) bounds the suite; don't enumerate every screen — that detail lives lower in the pyramid.
1---2name: maestro-e2e3description: Use to plan mobile end-to-end and smoke tests with Maestro — critical device flows on emulator/simulator, resilient to timing, covering happy path plus key error and authorization-denied variants. Reserved for critical mobile journeys; coordinates with the mobile pack.4---56# Maestro E2E78## Purpose910Verify **critical mobile journeys** end-to-end on a device/emulator using **Maestro** — the few flows whose breakage blocks release — plus fast **smoke** flows for post-build/deploy confidence. The mobile pack's `../../mobile/mobile-maestro-e2e` owns mobile-side detail; this testing-pack skill places Maestro in the cross-project testing strategy.1112## When to Use1314- For business-critical mobile journeys (onboarding, login, core transaction) and smoke checks.15- **Not** for logic (`unit-testing`), component behavior (Testing Library / `../../mobile/mobile-component-testing`), or web (`playwright-e2e`).1617## Inputs1819- Selected mobile app + critical flows (`testing-selection`, `../../mobile/mobile-stack-selection`).20- Build to test against + device/emulator (`../../mobile/mobile-builds`), seeded backend state (`test-data-management`).2122## Discovery Questions2324- Which mobile flows are critical enough for device E2E (few, high-value)?25- Which minimal flows form the **smoke** set (app launches, logs in, core screen loads) for post-deploy checks?26- What backend/test state must exist for the flows to run deterministically?2728## Responsibilities2930- Take the behavior to be covered from its **Gherkin scenarios** (`gherkin-specifications`) — implement one test per scenario rather than inventing a parallel case list.31- Cover **critical device journeys**: **happy path** through the real app, plus key **error** and **authorization-denied** variants at the journey level.32- Define a **smoke set**: minimal, fast flows proving the build is fundamentally alive (launch → auth → primary screen) — run after builds/deploys (`smoke-testing`, `../../devops/production-readiness`).33- Use Maestro's **resilient waiting** (element-based, not fixed sleeps); stable selectors (ids/accessibility labels — `../../mobile/mobile-accessibility`).34- Control backend/test state deterministically (`test-data-management`); run on emulator/simulator in CI where feasible (`../../devops/ci-cd`, `../../mobile/mobile-builds`).35- Keep the set **small** — top of the mobile pyramid; push detail to component/unit tests.3637## Required Workflow38391. Select critical flows + define the smoke set.402. Ensure a testable build + deterministic backend state.413. Script flows with element-based waits + stable selectors.424. Wire E2E + smoke into CI/build pipeline.435. Keep small; move detail down the pyramid.4445## Decision Rules4647- Device E2E for whole-journey integration only; component-level cases go to `../../mobile/mobile-component-testing`.48- Smoke flows stay minimal and fast — they gate deploys, not features.49- Element-based waits, never sleeps (flakiness — `flaky-test-audit`).50- A flaky device test is worse than none — stabilize or cut.5152## Rules5354- Deterministic backend/test state per run.55- Runs against a real build on device/emulator.56- Failures produce logs/screenshots for triage.5758## Anti-Patterns5960- E2E-testing every screen/edge on device.61- Fixed sleeps to paper over timing.62- Selectors tied to volatile UI text.63- Smoke sets that balloon into full regression suites.64- Duplicating component coverage on device.6566## Validation Checklist6768- [ ] Critical flows + minimal smoke set defined.69- [ ] Happy path + key error/authorization-denied variants.70- [ ] Element-based waits; stable selectors; no sleeps.71- [ ] Deterministic backend state.72- [ ] E2E + smoke CI-wired with failure artifacts; set kept small.7374## Definition of Done7576A small, stable Maestro suite covering critical mobile journeys and a fast smoke set — happy path plus key error/denial variants — with resilient waits, deterministic state, and CI/build integration.7778## Related Skills7980`../../mobile/mobile-maestro-e2e`, `testing-selection`, `playwright-e2e`, `smoke-testing`, `../../mobile/mobile-component-testing`, `test-data-management`, `flaky-test-audit`, `../../devops/ci-cd`, `../../devops/production-readiness`.8182## Related Knowledge8384`../../../knowledge/` (critical mobile flows).8586## Related References8788`../../../references/testing/` (mobile E2E patterns, when populated).8990## Context Loading Guidance9192- **Requires:** critical mobile flow list, testable build, backend seed strategy.93- **Does not require:** unit internals, unrelated screens.94- **May load:** `../../mobile/mobile-maestro-e2e`, `smoke-testing`.95- **Stop when:** critical flows + smoke set pass stably in CI.9697## Token Efficiency Guidance9899The flow list (critical + smoke) bounds the suite; don't enumerate every screen — that detail lives lower in the pyramid.
ahtishamshahzad