Run the Full Suite
Run the full generated suite when you need broad regression coverage for a project or release candidate.
Last updated
Was this helpful?
Run the full generated suite when you need broad regression coverage for a project or release candidate.
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.
Check the basics before launching a full suite:
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.
Open Runs.
Select New Run.
Select all runnable tests in the test list.
Under Environment, pick the environment you want to validate (or a Custom URL).
Choose one or more Run Configurations.
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.
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.
Full-suite runs are helpful for:
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.
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:
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.
Last updated
Was this helpful?
Was this helpful?
