Skip to main content

Creating a Playtest Run

Every test starts on the New Playtest page (/runs/new), reachable from My Runs or the Start a playtest button on the homepage. This page has one job: build up a list of numbered steps against a target URL, which gets saved as a draft run. Nothing runs yet at this stage, and no credit is spent, so you're free to walk away from a draft and come back to it later, or delete individual steps and rebuild the list, with zero cost.

This page documents every field on that form. The same form is reused, pre-filled, when editing a previous run's steps before running it again; see Editing & Re-running a Test for that flow specifically.

Target URL​

The full URL of the app you want to test, including the scheme (https://...). This is the address every navigate step reloads (see Step Types & AI Resolution for exactly what navigate does), and it's what every click/type/assert step operates against once the browser has loaded it.

A few practical notes:

  • The target does not need to be publicly reachable from the internet at large by anyone but VeriWasp's own runner, but it does need to be reachable from wherever the VeriWasp server itself runs. A localhost URL on your own machine won't work unless VeriWasp is also running on that same machine; a staging URL behind a VPN won't work unless VeriWasp's network can reach it.
  • There's no built-in way to supply HTTP basic-auth credentials or a custom header for a target that's gated that way. If your target requires that, it isn't testable today.

Viewport​

A dropdown with two options:

  • Desktop: a standard 1280×800 browser viewport.
  • Mobile: emulates a real iPhone 12's screen dimensions, pixel ratio, and touch behavior (not just a resized desktop window: chromedp's device emulation profile is used, so pages that branch behavior on touch support or screen size will behave as they would on an actual phone).

Pick Mobile whenever you're testing responsive layouts, a hamburger-menu navigation pattern, or anything you specifically want validated at phone dimensions. The built-in Mobile navigation template (see Scenario Templates) is designed to be run with this viewport.

Chaos Mode​

A checkbox, off by default. When enabled, VeriWasp doesn't just run your scripted steps, it also injects extra, unscripted noise alongside them: rapid repeated clicks, erratic back/forward browser navigation, and an artificially throttled network connection, meant to simulate the kind of punishing, impatient, poor-connectivity usage a real user actually subjects your app to, which a clean, well-behaved scripted run would never surface.

Chaos Mode costs 3 credits instead of 1 per run, reflecting the extra execution time and resource use the extra actions add. Full details, including exactly what each type of chaos action does, are in Chaos Mode.

Starting point: templates vs. writing your own​

A dropdown labeled Starting point lets you either:

  • Write my own from scratch: starts you with a single blank step, and you build the list up manually using the + Add step button.
  • Pick one of five built-in scenario templates (signup, checkout, invite teammate, mobile navigation, or full onboarding), each of which pre-fills a complete, ready-to-run sequence of steps for that flow. You can still edit, add to, or delete any of the pre-filled steps before confirming; templates are a starting point, not a locked sequence.

Selecting a template swaps the step list below via a live, no-page-reload update. Full details on exactly what each template's steps do are in Scenario Templates.

Run label (optional)​

A free-text field, purely descriptive, with no effect on execution. Use it to tell runs apart at a glance in My Runs, especially useful once you have several runs against the same target, for example "Post-deploy signup check" or "Weekly regression: checkout."

The step editor​

This is the core of the form: a list of numbered rows, each representing one action the browser will take, in order. Each row has:

  • An action type dropdown: navigate, click, type, wait, or assert. See Step Types & AI Resolution for a complete explanation of what each one actually does at execution time. This is the single most important page in these docs for writing steps that actually work, especially the difference between navigate and everything else.
  • A target description field: plain English describing what this step acts on, e.g. "the Sign Up button in the top nav" or "the email field." This is what gets handed to the AI element resolver (or the deterministic text-matching fallback) at execution time to find the actual element on the live page. It is not a CSS selector, and you should never write one here. Describe the element the way you'd describe it to another person looking at the screen.
    • Exception: when the action type is navigate, this field becomes read-only and dimmed, with an inline note explaining why: navigate always reloads the Target URL you entered above, in full, regardless of what this field says. Nothing you type here for a navigate step is ever read by the runner. This is enforced in the UI specifically because it used to be a common mistake. See the callout in Step Types & AI Resolution for why. The same read-only treatment applies to the target description when the assert kind is no failed network requests (see below), for the same reason: that assert kind doesn't read the field either.
  • An assert kind dropdown, shown only when the action type is assert: element is present (default), element is absent, element count, URL contains, or no failed network requests. Changing it also updates the target description's placeholder text and, for element count, the value field's placeholder, to hint at what that kind expects. See Step Types & AI Resolution for exactly what each one checks.
  • A value field, meaningful for type steps (the literal text typed into the resolved element) and for assert steps using the element count kind (the expected number of matches, e.g. 3). Left blank for every other action type/assert kind combination.
  • ↑ and ↓ buttons to move that step earlier or later in the sequence. Clicking ↑ on the first step (or ↓ on the last) does nothing; there's no wraparound.
  • A ✕ button to remove that step from the list.

Click + Add step to append a new blank row (defaulted to action type click, since that's the most common one). There's no upper limit on step count enforced by the UI, though very long scenarios take proportionally longer to execute and are more likely to hit a step's individual timeout if the target app is slow.

Reordering works the same way on the edit form as it does here: the step order at the moment you click Confirm & Create Run is exactly the order that gets saved, whether you built the list from scratch or rearranged steps copied in from a previous run.

Writing target descriptions that actually resolve​

Because target descriptions are matched against real elements on the live page, either by an AI model or by deterministic text scoring, a step can only succeed if the element it describes actually exists on the page at that point in the run, for whatever user (if any) is logged in at that point. Two failure patterns are worth calling out explicitly, because they're easy mistakes that produce a confusing "could not find an element matching..." failure rather than an obviously wrong one:

  1. Describing something that requires being logged in, when nothing earlier in the scenario logs in. VeriWasp's runs are anonymous browser sessions by default; there is no automated way to complete your app's own login/magic-link/OAuth flow mid-run (see the callout in Account & Sessions for why). A step like "click on my account settings" will fail if nothing before it actually established a logged-in session, because the element it's describing genuinely isn't on the page.
  2. Describing an action rather than an element. Every action type except wait needs to resolve to a specific, real, interactive-or-not element on the page: a button, link, input, heading, etc. A description like "scroll to the pricing section" describes something you'd do with a mouse wheel, not a page element, so there's nothing for the resolver to match it against. Rephrase it as the actual link or button that gets you there, like "the Pricing link in the nav," instead. If the section really has no link and is just further down a single scrolling page, there may be no valid step for it at all.

Submitting the form​

Clicking Confirm & Create Run posts the form to the server, which:

  1. Validates that a target URL and at least one step are present.
  2. Creates the run row in a draft status, with a fresh, random public share slug and CI trigger token generated up front (even though they're not needed yet; see Shareable Reports and CI/CD Integration).
  3. Saves every step, in order.
  4. Redirects you to the new run's detail page.

No credit is deducted and nothing executes at this point. See Understanding Run Results for what happens when you click Run this test on the following page.