Test Cases

A test case is a single scenario written in plain English. You describe what a customer should be able to do: the setup, the actions, and the outcome to verify. The AI agent runs it in a real cloud browser, then reports a pass or a fail. There are no selectors, scripts, or step recorders: you state the intent, and the agent works out how to reach it and adapts when your UI changes.

Anatomy of a test case

Every test case has four core fields plus its suite membership.

When you save a test case it also gets a short ID (slug) shown in its settings. Launch results and history use this ID to identify the test case.

URL

The URL is where the agent opens the browser before it starts working through the description. You can hardcode a full https address:

https://app.example.com/login

We recommend building it from the {{PROJECT_URL}} variable instead:

{{PROJECT_URL}}/login

{{PROJECT_URL}} is seeded from the project URL, so you don't retype the host, and — more importantly — you can override it per launch to point the same test cases at another environment.

The agent opens this URL from a cloud browser, so it must be reachable over the public internet.

The agent performs real actions — it submits forms, makes payments, and deletes data exactly as described. Point destructive or paid flows at a non-production environment, use dedicated test accounts, and rely on provider test modes (for example Stripe test cards) so launches never touch real customers or funds.

Screen sizes

The screen size sets the browser viewport for the run:

Pick the one your flow is meant to be tested at. If a flow behaves differently on desktop and mobile, create one test case for each.

Writing the description

The description is a single plain-English block, not a list of typed steps. Write it the way you'd brief a teammate sitting next to you: start with the setup, continue with the actions, and finish with the outcome to verify.

Guidelines for reliable descriptions:

• Lead with a clear goal. State what the customer is trying to accomplish, so the agent optimizes for that end state rather than a fixed click path.
• State assertions explicitly. Tell the agent what must be true for the test to pass — a specific message, a redirect, an updated value. "Make sure the success banner appears" is checkable; "make sure it works" is not.
• Avoid ambiguity. Don't leave the agent to guess between two plausible actions. If order matters, say so; if a value matters, give it.
• Keep it to one flow. One test case should cover one scenario. Split unrelated flows (signup vs. checkout) into separate cases and group them in a suite, so a failure points at one thing.
• Reuse values through variables. Reference credentials, URLs, and other shared data as {{VARIABLE}} tokens instead of hardcoding them. Secrets are masked in logs and results.

Examples

Each example below is a complete description you could paste into a test case. The {{...}} tokens are variables resolved at run time.

Chat assistant conversation with follow-up questions:

Make sure an AI chat assistant is present on the page. Ask "What time do you close
on Sunday?" and confirm it gives a specific closing time. Then ask "Do you have
vegan options on the menu?" and confirm the reply names at least one vegan dish.

Signup flow using a fresh random email each run:

Create a new account using {{RANDOM_EMAIL}}. Submit the onboarding form
with random but valid values. After that, you should see
the dashboard with an empty list of workspaces. Delete this account
from the settings. You should be logged out and end up on the login page.

Billing upgrade flow with Stripe checkout:

Log in with {{TEST_USER_EMAIL}} and {{TEST_USER_PASSWORD}}. Create a project
with a random name and a valid https URL. You should be redirected to the
project page. Open the project settings and upgrade the plan from Free to
Starter. Pay with the pre-saved card. Purchase as a customer,
not a business, and make sure VAT is included in the final total. After paying,
you should be redirected from Stripe back and see a success message.
Confirm the test quota has increased to match the Starter plan. Finally, delete
the project and confirm you land on the dashboard.

Preview a test case before you rely on it

While editing a test case, use Run test to try it immediately. The editor streams the cloud browser live so you can watch the agent work through your app in real time, alongside its reasoning and the actions it takes. Use this to confirm the description is unambiguous and the assertions hold before you add the case to a suite.