What it does
Builds or extends automated Web UI / E2E tests for a user journey: selects critical journeys by risk (pushing checks down to API/component where cheaper), encapsulates selectors/actions in page objects with assertions in specs, uses only stable role/label/test-id locators, sets up per-role auth state and synthetic data, relies on web-first assertions with no hard waits, runs cross-browser per ci.browsers, and adds config-gated accessibility/visual checks. Reports journeys, risk tier, and browsers/viewports run.
When to use it
For web UI test automation — building or extending E2E coverage of a feature, journey, or page.
Prerequisites
qa.config.yml; E2E framework present (tooling.e2e/language via scaffold); running app for execution; ci.browsers; test_data; optional tooling.accessibility/visual.
Output
Test Procedure / script (ISO/IEC/IEEE 29119-3 Test Procedure Specification) under paths.tests_dir/e2e/ + the run's Test Execution Log from the e2e reporter.
Mechanics
How it works
- Guard config; resolve the journey as test basis
- Select journeys by risk; push checks down to API/component where cheaper
- Encapsulate selectors/actions in page objects (assertions in specs)
- Use only stable role/label/test-id locators
- Set up per-role auth state; seed synthetic data; each test owns its data
- Use web-first assertions with no hard waits
- Run cross-browser per ci.browsers and record viewports
- Add config-gated a11y/visual hooks; place, run, and wire smoke into the PR gate
Why it works
The theory behind it
Automation (CT-TAE) at the system test level; the test pyramid governs scope — reserve E2E for genuine journeys and push cheaper checks down to API/component; flakiness is a test defect.
CT-TAE · CTFL v4.0 §2.2
Example
See it in use
> /qa:web-automate "guest checkout journey"✓ Correct when Tests use POM + auth state, run cross-browser per ci.browsers, with no hard waits.