How many parallel tests do I need?

Divide your total suite runtime by the wall-clock time you are willing to wait, then round up. A 200-minute suite that must finish inside 20 minutes needs roughly 10 parallels. Adding parallels past that point stops helping, because your slowest single test becomes the floor.

What happens if I start more tests than my plan allows?

They queue rather than fail. TestingBot holds the extra sessions until a slot frees up, then starts them automatically, so a CI job that bursts above your concurrency still completes without errors. It simply takes longer.

Do I need to change my test code to run in parallel?

You change your test runner configuration, not your tests, as long as your tests are independent. Each framework has its own switch: workers in Playwright, threads in TestNG or pytest-xdist, and the parallel flag in Cypress. Tests that share state or fixed test data need isolating first.

Does parallel testing work with real mobile devices?

Yes. Appium, XCUITest, Espresso and Maestro sessions consume the same concurrency as browser sessions, so the same plan covers both. Each parallel session gets its own dedicated device.

Parallel testing

Parallel testing is running several automated tests at the same time instead of one after another. Each test gets its own isolated browser or device session, so a suite that takes an hour sequentially can finish in a few minutes. The number you can run at once is your concurrency.

See plans by concurrency

How concurrency works on TestingBot

Every test you start takes one parallel session for as long as it runs, then releases it. Your plan sets how many sessions can be open at once. Browser sessions and real-device sessions draw on the same pool, so a Selenium run and an Appium run compete for the same slots.

If your CI job starts more tests than your plan allows, the extra ones queue instead of failing. TestingBot holds them and starts each as a slot frees up, so a burst above your concurrency still completes. It just takes longer, which is usually the first sign that it is time to size up.

Parallel sessions by plan

Plan	Parallel sessions available
Automated	1, 2, 4, 8, 16, 24
Pro	1, 2, 4, 8, 16, 24
Live (manual)	1, 2, 4, 10, 25

Concurrency is the axis these plans scale on. For what each tier costs, see pricing.

What speedup to actually expect

A suite of 200 tests averaging one minute each takes about 200 minutes end to end. Split across parallel sessions it drops roughly in proportion, until the point where your slowest individual test becomes the floor. Nothing finishes faster than its longest single test, however many sessions you buy.

Parallel sessions	200-minute suite finishes in about
1	200 min
2	100 min
4	50 min
8	25 min
16	13 min
24	9 min

Indicative only. Real suites have uneven test durations, so a run ends when the slowest worker finishes rather than when the average one does. Treat these as an upper bound and expect to land slightly above each figure.

To size it against your own suite rather than this example, use the parallel test calculator.

Running your framework in parallel

Parallelism is a test-runner setting, not a rewrite, as long as your tests are independent of each other. Each framework spells it differently:

Playwright parallel testing — set workers in your Playwright config and shard across CI machines.
Selenium parallel testing with JUnit — thread-safe WebDriver instances and parallel JUnit execution.
Puppeteer parallel testing — run multiple browser connections concurrently against the grid.
Parallel test calculator — work out how many sessions your suite needs to hit a target run time.

Framework overviews: Selenium, Playwright, Cypress and Appium.

Frequently asked questions

What is parallel testing?: Parallel testing is running several automated tests at the same time instead of one after another. Each test gets its own isolated browser or device session, so a suite that takes an hour sequentially can finish in a fraction of that. The number of tests you can run at once is called your concurrency, or your number of parallels.
How many parallel tests do I need?: Divide your total suite runtime by the wall-clock time you are willing to wait, then round up. A 200-minute suite that must finish inside 20 minutes needs roughly 10 parallels. Adding parallels past that point stops helping, because your slowest single test becomes the floor.
Does doubling my parallels halve my test run?: Close to it at first, but not exactly, and not forever. Real suites have uneven test durations, so the run ends when the slowest worker finishes rather than when the average one does. Speedup is close to linear while you have many more tests than parallels, and flattens as the two numbers converge.
What happens if I start more tests than my plan allows?: They queue rather than fail. TestingBot holds the extra sessions until a slot frees up, then starts them automatically, so a CI job that bursts above your concurrency still completes without errors. It simply takes longer.
Do I need to change my test code to run in parallel?: You change your test runner configuration, not your tests, as long as your tests are independent. Each framework has its own switch: workers in Playwright, threads in TestNG or pytest-xdist, and the parallel flag in Cypress. Tests that share state or fixed test data need isolating first.
Does parallel testing work with real mobile devices?: Yes. Appium, XCUITest, Espresso and Maestro sessions consume the same concurrency as browser sessions, so the same plan covers both. Each parallel session gets its own dedicated device.