Skip to main content
The Test Runner is where your test cases and test suites actually run. Each case executes independently in its own browser session, so a batch runs in parallel and results stream back into a single grid as they finish. Open it from Test Runner in the project sidebar.

Run your test cases

The runner walks you through three phases: pick the cases, watch them run, review the results.

1. Select what to run

First, enter the Target URL you want to test (e.g. https://app.example.com). Then load the cases to run from one of three sources:

From library → Test cases

Browse your saved test cases and tick the ones to run. Use Select all / Deselect all to move fast.

From library → Test suites

Pick a suite and click Load suite into selection to load and pre-select every case in it.

From JSON

Paste an array of test cases as JSON—handy for ad-hoc runs or CI. Sample buttons (1 passing, 5 cases, …) give you a starting shape.
Selected cases appear in the Staged cases list. When you’re happy with the selection, click Run case(s).

2. Watch the run

Each case becomes a card in the execution grid with a live status badge:
StatusMeaning
QueuedWaiting for an execution slot.
Starting…The browser session is being created.
Running…Scout is executing the case—you’ll see step-by-step progress (✓ done, ● current, ○ pending, ✗ failed) and a live activity label.
PassedEvery step and assertion succeeded.
FailedAt least one step or expectation failed.
Blocked / Could not startThe case couldn’t run—often a bad URL or missing precondition.
A summary bar at the top tallies the run: how many passed, failed, blocked, running, and queued, plus a Done badge when everything finishes.

3. Review results

From each card you can:
  • View execution — open the full transcript, screenshots, and any bug reports Scout filed for a failure.
  • Download script — grab the deterministic Playwright script recorded for a passing case.
When the run is complete, click Start new run to go again.

Parallel runs

Scout runs your selected cases concurrently—each in its own isolated browser session—rather than one after another, so a suite finishes much faster than running cases by hand. You don’t configure a worker count; Scout throttles the run automatically and respects your plan’s concurrency limits.
Concurrency is bounded by your plan. Vibe allows up to 5 concurrent executions and Ship up to 10. If you queue more cases than your limit, the extras wait in Queued and start as slots free up. Hitting the ceiling shows a “too many active executions” message—let the in-flight cases finish, then continue.
Because each case runs in a fresh session, cases don’t share state. Put anything a case depends on (login, seed data) in its preconditions or test data rather than assuming an earlier case set it up.

Run state is per-session

A run’s progress is stored in your browser session, so a refresh won’t lose it. Opening a new tab or clearing browser storage starts fresh.