# Run the full suite

Run the full suite when you want broad confidence across the generated tests in a repository. Full-suite runs are best after individual tests and key groups are already stable.

Because this option may run many browser sessions, it can take longer and may surface shared setup issues such as unavailable test data, expired credentials, or runner capacity limits.

## Before you start

Check the basics before launching a full suite:

| Check                        | Why it matters                                                       |
| ---------------------------- | -------------------------------------------------------------------- |
| A recent single test passed  | Confirms the target site, runner, and configuration are working.     |
| Key groups are stable        | Prevents one known setup issue from producing many noisy failures.   |
| Runner capacity is available | Full suites can keep runners busy longer than focused runs.          |
| Test data is ready           | Shared accounts, seed data, and environment state affect many tests. |
| Secrets are current          | Expired credentials can fail the whole run.                          |

## Start a full-suite run

1. Open **Runs**.
2. Select **New Run**.
3. Select all runnable tests in the test list.
4. Enter the **Site URL** for the environment you want to validate.
5. Choose one or more **Run Configurations**.
6. Start the run.

If your suite is organized into groups, you can select all groups or select the top-level suite entry when available. Review the selected tests before starting so the run matches the scope you intend.

## When to use a full suite

Full-suite runs are helpful for:

| Situation          | Why it helps                                                 |
| ------------------ | ------------------------------------------------------------ |
| Release readiness  | Confirms the main generated coverage passes before shipping. |
| Major UI changes   | Catches regressions across multiple feature areas.           |
| Nightly validation | Gives the team a regular signal on the state of the app.     |
| Environment checks | Confirms staging or test deployments are usable end to end.  |

For recurring coverage, see [Schedule runs](/run-tests/schedule-runs.md).

## Review failures

Start with the overall run status and then inspect failed rows. A full suite can produce related failures from a single root cause, so look for patterns before editing many tests.

Common examples:

| Pattern                            | Likely next check                                   |
| ---------------------------------- | --------------------------------------------------- |
| Many tests fail at sign-in         | Check credentials, secrets, and login flow changes. |
| Failures start after a setup step  | Review prerequisite steps and test data.            |
| Only one group fails               | Investigate that feature area first.                |
| Only one browser or viewport fails | Review the selected run configuration.              |

For evidence review, see [Review Results](/results.md).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.testvibe.com/run-tests/run-full-suite.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.