> For the complete documentation index, see [llms.txt](https://docs.testvibe.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.testvibe.com/run-tests/run-full-suite.md).

# Run the Full Suite

Run the full suite when you want broad confidence across the generated tests in a project. 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 plan 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, cloud test session, and configuration are working. |
| Key groups are stable       | Prevents one known setup issue from producing many noisy failures.           |
| Credit balance is available | Full suites use more session time 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. Under **Environment**, pick the environment you want to validate (or a Custom URL).
5. Choose one or more **Run Configurations**.
6. Optionally set **Execution** — **Sequential** or a lower **Custom** cap reduces load on the target site during a large full-suite run, at the cost of a longer run; leave it on **Auto** otherwise.
7. 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
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.