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.

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.