Originally published on the QA Guardian blog.
The average engineering team running tests on GitHub Actions experiences something like this: a developer opens a pull request, CI triggers, tests run sequentially, forty-five minutes later a result appears. The developer has long since context-switched. They come back, see a failure, and try to remember what they were doing.
Sequential test execution is one of the most pervasive and underacknowledged sources of developer slowdown. And it is almost entirely unnecessary.
Why Sequential Testing Is the Default
Most CI platforms run tests sequentially out of the box. You configure a job, it runs your test command, tests execute one file at a time. This is the path of least resistance — and it scales terribly.
Going from twenty flows to forty doubles your CI time. Going from forty to a hundred makes CI unusable as a fast-feedback mechanism. At that point, developers stop treating CI results as a signal and start treating them as a gate to wait out. The test suite stops changing behavior.
How Parallel Execution Works
Parallel execution runs multiple test files simultaneously, each in its own isolated environment. Instead of forty flows running in sequence at roughly forty-five seconds each (thirty minutes total), ten workers each handle four flows simultaneously. Total time: three to four minutes.
The key requirement is isolation. Each parallel worker needs its own browser instance, its own test data seeded independently, and its own application state — no shared sessions or database records between workers. If your tests share state, parallelism will break them. This is actually a useful diagnostic: tests that cannot be parallelized almost always have a hidden state-sharing problem.
Implementation Approaches
Native Playwright sharding. Playwright supports --shard=1/5 arguments out of the box. Define a matrix strategy in GitHub Actions to run five parallel jobs, each handling a shard of the suite. This is the simplest approach and works well for most teams up to moderate scale.
Dedicated infrastructure. For larger suites or teams that need consistent, predictable performance, Kubernetes-based infrastructure spins up a fresh container per test file. This eliminates queue time — a common pain on shared CI runners — and delivers consistent sub-five-minute execution regardless of platform load.
The Math on Developer Time
Ten engineers opening three pull requests per day each is thirty CI runs per day. At forty-five minutes per run, that is twenty-two and a half hours of accumulated wait time — roughly two hours and fifteen minutes per engineer per day, every day.
Drop CI to four minutes and that becomes two hours total across the whole team — twelve minutes per engineer. The freed attention is significant. Engineers can review CI results before opening the next task. Feedback loops collapse from hours to minutes.
There is also a behavioral threshold at around four minutes: developers actually keep the CI tab open. When CI takes forty-five minutes, nobody waits. When it takes four, many do. That behavioral change is where the compounding value comes from.
What to Watch Out For
Database conflicts. Tests that write to a shared database will interfere with each other under parallelism. Use isolated database schemas per worker, or generate unique test data per run.
Port conflicts. If tests spin up local servers, multiple workers may collide on the same port. Target an already-running environment or use dynamic port allocation.
Rate limiting. Real external APIs may be hit in parallel far more aggressively than in sequential runs. Mock or stub third-party dependencies; reserve real API calls for dedicated integration runs.
The Target
For most applications with twenty to fifty critical flows, the benchmark is straightforward:
- Sequential on shared CI: thirty to sixty minutes
- Parallel with proper isolation: three to five minutes
Anything under five minutes means developers get feedback before they have fully switched context. That is the meaningful threshold — not just for efficiency, but for whether CI results actually influence developer behavior. A test suite nobody waits for is a safety net with holes.
If you'd like to see how Guardian runs your flows in parallel on dedicated infrastructure, book a demo and we'll walk through the execution model.
