> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scoutqa.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Test Runner

> Run one test case or a whole suite against your app—cases execute in parallel and results stream into a live grid.

The **Test Runner** is where your [test cases](/essentials/test-cases) and [test suites](/essentials/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:

<CardGroup cols={3}>
  <Card title="From library → Test cases" icon="clipboard-list">
    Browse your saved test cases and tick the ones to run. Use **Select all** / **Deselect all** to move fast.
  </Card>

  <Card title="From library → Test suites" icon="folder-tree">
    Pick a suite and click **Load suite into selection** to load and pre-select every case in it.
  </Card>

  <Card title="From JSON" icon="code">
    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.
  </Card>
</CardGroup>

Selected cases appear in the **Staged cases** list. When you're happy with the selection, click **Run {n} case(s)**.

### 2. Watch the run

Each case becomes a card in the execution grid with a live status badge:

| Status                            | Meaning                                                                                                                          |
| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Queued**                        | Waiting 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. |
| **Passed**                        | Every step and assertion succeeded.                                                                                              |
| **Failed**                        | At least one step or expectation failed.                                                                                         |
| **Blocked** / **Could not start** | The 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.

<Note>
  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.
</Note>

<Tip>
  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.
</Tip>

## 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.