Phase 3: I Broke My Own Playwright Framework on Purpose (So You Don't Have To)
Updated: Sep 3
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 took that framework, ran it locally — clean. Ran it through GitHub Actions — clean. Then I turned workers up from one to four to actually get some parallel speed out of it. That's where it broke. Not the local run, not CI as-is — the moment concurrency entered the picture.
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
Verifying Test Data Isolation: check whether that was enough on its own. A confirmed gap turned up in checkout, and shared resources got checked and ruled out for now.
Add Cross-Browser Automation to run across multiple browsers with multiple workers in place already
Sharding and Docker: scaling horizontally, on GitHub Actions
Running Playwright Tests in the Cloud with TestMu
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.
OR
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.
This is Post 1 of the Phase 3: Enterprise Scalability series.
