Test automation by surface

/qa:scan-ui

Discover a running UI into page objects and test cases

Deep-dive a web UI to extract stable locators and actions into page objects, then generate cases covering every element and flow.

USAGE/qa:scan-ui <url or page/flow> [auth role]
Test automation by surfaceCTFL v4.0 §1.4 · §4 · CT-TAE (POM) · ISO/IEC/IEEE 29119-3Automation

What it does

Crawls a running UI (bounded to base_url_web origin, capped at 10 pages), extracts every interactive element with its role/name/test-id and state, derives the most stable locator and action per element, writes/extends Page Object classes (assertions kept in specs), and generates test cases covering presence/state, actions, input validation (EP/BVA), navigation, and negative paths. Marks expected results not derivable from the UI as TODO and reports element coverage as counts.

When to use it

To bootstrap or expand UI automation from a running app — discovering elements into page objects and covering cases.

Prerequisites

qa.config.yml; running app + stack.base_url_web; E2E framework present (tooling.e2e via scaffold); test-case-template.md; optional saved storageState per role.

Output

Test Procedure Specification (page objects under paths.tests_dir/pages/ + specs under e2e/) and a Test Case Specification doc at docs/UI-SCAN-<target>.md + a counts coverage summary; temp _scan/ probe removed.

Mechanics

How it works

  1. Guard config and resolve the target (URL / page-flow / auth role)
  2. Run a temporary exploration script to discover every interactive element
  3. Choose the most stable locator and infer the action(s) per element
  4. Generate or extend Page Object files, reusing existing POMs
  5. Derive conditions and generate covering test cases with EP/BVA
  6. Mark non-derivable expected results TODO: confirm with requirements
  7. Output page objects, the cases doc, and a coverage summary
  8. Run smoke specs, remove the _scan/ probe, then hand off

Why it works

The theory behind it

Test analysis and design using the running UI as the test basis, implemented with the Page Object Model; POM is the maintainability pattern (ISO 25010) that keeps UI tests from rotting; oracle caveat — the scanner knows what exists, not always the correct business outcome.

CTFL v4.0 §1.4 · §4 · CT-TAE (POM) · ISO/IEC/IEEE 29119-3

Example

See it in use

scan-ui
> /qa:scan-ui http://localhost:3000/checkout

✓ Correct when Every interactive element gets a stable locator and at least one covering case, and the temp probe is removed.