Web (browser) tests

Build multi-step browser journeys with the step model and recorder.

syntheticbrowserwebstepsrecorder

Web (browser) tests

A web test drives a real browser through a multi-step journey and asserts on what it sees. Use it for anything a user does in a page: sign-up, login, search, add-to-cart, checkout.

Building a test: the step model

A web test is an ordered list of steps, built in the step builder. Each step has an Action Type, usually a selector that points at an element, and a value. The common actions:

Action What it does What you fill in
Navigate Go to a URL URL
Type Text Type into an element Selector, Text to Type
Click Click an element Selector
Wait Pause, or wait for a condition Wait Condition (Fixed Time, Element Visible, Element Clickable, Text Present, Page Load Complete…) and a Wait Duration (ms)
Read Text Extract text from an element into a variable Selector, Variable Name
Assert (Validate) Check a condition Assertion Type, Expected Text/Value; tick Soft Assert to continue the test on failure

More actions are available for richer journeys: Hover, Select Option, Clear Field, Scroll, Switch Frame and Execute JavaScript. Every step also has its own Timeout (ms) and an optional screenshot toggle.

Example: a login journey, step by step

  1. Navigate to https://app.example.com/login.
  2. Type Text into the email field (Selector Type CSS Selector, value #email): demo@example.com.
  3. Type Text into #password: {{SECRET_PW}} — a secret, never the literal password.
  4. Click the submit button (button[type=submit]).
  5. Wait — Element Visible on the welcome banner.
  6. Read Text from .welcome into the variable greeting.
  7. Assert (Validate) that .welcome contains "Welcome".

Selectors

Prefer stable selectors: a data-testid attribute or a unique id beats a brittle CSS path. Selector types include CSS Selector, XPath, ID, Class, Name, Tag and Link Text.

Using the step recorder

  1. Open Synthetics → New Web Test → Record.
  2. Click through your journey in the embedded browser; each action is captured as a step.
  3. Stop, then clean up: add waits where the UI is async, add asserts, and replace any captured secret with a {{variable}} (see Variables and secrets).

What you capture

  • Step-by-step pass/fail with screenshots and video on failure.
  • Performance: DNS, connect, TLS, TTFB, and Core Web Vitals.
  • Captured network requests for correlation with APM traces.

Common cases and tips

  • Flaky waits: prefer "wait for selector/network idle" over fixed sleeps.
  • Auth: store credentials as secrets; never hard-code them in steps.
  • Dynamic content: assert on stable text or roles, not generated ids.
  • Multi-environment: parameterize the base URL so one test runs against staging and prod.