Parallel runs reduce execution time, but they can also multiply flaky behavior. Use these patterns to run web tests in parallel reliably using WebDriver endpoints (Selenium Grid or cloud providers).
Decide how you want to parallelize, common strategies:
- Parallel by browser/capability set (same test, different browsers/versions/platforms)
- Parallel by suite split (different test groups per worker)
- Parallel by data rows (data-driven runs)
Note: Use remote WebDriver sessions (Grid/cloud) or separate runners/agents. Parallel Runner is designed to execute one test across multiple capability sets via a WebDriver endpoint in parallel.
Isolation strategies (must-have)
Use isolated test data
- Separate accounts per parallel worker
- Avoid shared records that multiple tests update simultaneously
Avoid shared state
- Don’t reuse the same inbox, same order-number pool, etc.
Keep filesystem paths unique (when needed)
- If tests download files or write artifacts, ensure each worker uses unique output/download paths.
Endpoint and capacity strategy
- Ensure your Grid/provider has enough capacity for the number of parallel sessions you want.
- Start with low parallelism and increase gradually.
- Keep capability sets simple and predictable (add constraints only when needed).
Endpoint configurations are just capabilities JSON sets that define browser/OS/version behavior, and Parallel Runner is built to run across multiple capability sets.
Debugging parallel failures
If only parallel runs fail, suspect collisions or environment limits.
- Compare failures per worker (same test, different capability set).
- Capture logs/reports per worker and correlate with the capability set that produced the failure.
- Ensure each parallel run writes to a separate output folder (Parallel Runner can generate a default parallelRuns folder if you don’t specify one).