Phase 3: I Broke My Own Playwright Framework on Purpose (So You Don't Have To)

Anuradha Agarwal
Aug 12
4 min read

Updated: 24 hours ago

Scaling a Playwright Framework From One Worker to Enterprise Ready

If you've followed my Playwright course through Phase 1 and Phase 2, you already have a working test automation framework - Page Object Model, custom fixtures, API testing, CI/CD, AI-assisted review, the whole build, tested against qa-cart.com, my test demo store. It runs cleanly. It passes. It looks done.

Then I tried to scale it.

I pointed the framework at four concurrent workers, sharded it across CI jobs, containerised it with Docker, and connected it to a cloud browser grid - and it broke, in ways I didn't expect, for reasons that had nothing to do with the test code itself.

This series - Phase 3: Enterprise Scalability - is the record of that process. Not a polished, pre-solved tutorial. The bugs, the wrong guesses, and the fixes, in the order they happened.

Why this matters if you're job hunting

If you're a QA engineer or SDET working toward a senior role, here's something worth sitting with: writing correct Playwright tests is table stakes. What separates a mid-level automation engineer from a senior one is what happens when those tests need to run at scale - four workers instead of one, sharded across machines, sometimes on infrastructure you don't control at all.

That's exactly the gap this series closes. Not "how to write a Playwright test" -you already know that. This is "how to make a working framework hold up under enterprise-scale constraints": shared identity pools, worker isolation, cart and session state that leaks across concurrent tests, hosting infrastructure with genuine bandwidth limits, cloud execution grids with their own queueing behaviour.

Each post covers a stage of the build, in order:

Getting the framework running: cloning the repo, setting up .env with your own qa-cart.com credentials, and confirming the baseline passes before anything else changes
Running in parallel for the first time: turning workers up from one to four and watching a single shared login collide with itself
Designing authentication that can survive concurrency: why a single shared login breaks under concurrency, and the architecture (IdentityProvider, AuthenticationManager, WorkerResolver) that fixes it properly.Building from architecture to working code
Worker Scope, the Fixture, and Closing Out Concurrency: the decision that's actually the root cause of half your isolation bugs
The bug that only shows up at scale: cart and coupon state leaking between tests, and the fix
Sharding and Docker: scaling horizontally, containerizing for portability
Cross-browser at scale: extending the same architecture to Firefox and WebKit
The hosting mystery: I was convinced my CPU was the bottleneck. The data said otherwise. This one's my favorite: hosting metrics, a wrong hypothesis, and the root cause behind it.
Running tests on someone else's browsers: a debugging diary from connecting to a cloud execution grid, including the .env file bug that cost me an hour
Two ways to go cloud: comparing two fundamentally different cloud execution architectures
Reviewing my own framework with AI: what Copilot's review got right, what it got subtly wrong, and why the difference matters

This is Phase 3 of my Playwright course

Everything in this series is the build behind Phase 3: Enterprise Scalability, the newest section of my Playwright Automation Testing course on Udemy. The blog series is the story - the reasoning, the bugs, the fixes- freely available. The course is where you build it with me, step by step, narrated, with exercises along the way.

The companion repository for this series isn't a stripped-down demo - it's the same framework built step by step across Phase 1 and Phase 2 of the course, tested against qa-cart.com: Page Object Model, custom fixtures, API testing, CI/CD, AI-assisted review. Everything this series does happens within that same working framework, carried forward rather than rebuilt from scratch.

That means two ways to use it, depending on where you're starting from:

Already comfortable with Playwright fundamentals and just here for scalability? Clone the repo as-is and follow along from this post - you don't need the full course to get value from this series.

Starting from scratch, or want the framework itself explained line by line? Head to Phase 1 and Phase 2 of the course first. This series assumes that framework already exists; it doesn't teach you how to build it.

Who this is for

QA engineers and SDETs preparing for senior-level interviews who want enterprise scalability patterns they can apply directly to their own frameworks
Anyone who's hit "it works on my machine but fails in CI" and wants to understand why, not just find a workaround
Playwright users ready to grow from writing individual tests into designing how those tests execute at scale

If that's you, follow along.

The next post is the practical starting point: getting the repo onto your own machine, running the existing suite once to confirm it works, and setting up the two things every post after that depends on - before we touch a single line of the execution architecture.