Introduction
Let’s get this out of the way: I’m not a formally trained automation engineer. I didn’t come from a Selenium bootcamp or spend months perfecting test pipelines. I came from real-world QA. And like most testers turned QA leads, my first dive into automation wasn’t because I was passionate about scripting. It was because I wanted a title bump and a salary raise. Welcome to reality.
But over time, I found a way to use Playwright that worked for me, my team, and our projects. No flaky pipelines. No over-engineered test suites. Just smart automation where it helps and manual QA where it wins.
If you’re expecting a shiny tutorial with charts, screenshots, or a step-by-step CI/CD walkthrough, close this tab. If you want automation that actually works in the field? Keep reading.
How I Actually Use Playwright
When I first started with Playwright, I kept my scripts local. It was fast, easy, and mine. But eventually, I realized my dev teammates were curious. So I pushed the scripts to GitHub so they could fork, learn from, or build on top of them.
Initially, I ran everything on Windows. That didn’t last. WSL and the Windows filesystem refused to play nice, especially for anything beyond basic file handling. So I switched: full Ubuntu on WSL, Node installed, Playwright set up clean. Scripts lived in Ubuntu and got pushed to GitHub from there. Simple. Stable. Sharable.
I didn’t write scripts for every PR. That’s suicide unless you like debugging flaky tests every day. Instead, I used Playwright for what mattered: UI regression checks on staging. When I felt too lazy to test manually, automation picked up the slack. It became a tool—not a religion.
If you’re automating every test case just to feel productive, congratulations—you’ve just invented flaky hell.
I covered this style in Playwright for QA Testing and expanded on specific features in Advanced Tips for Using Playwright’s Codegen in Test Automation.
When Manual QA Still Wins (Yes, Even in 2025)
I’ve sat in enough meetings to know that some teams still think manual QA is obsolete. That’s laughable.
Here’s where manual still owns the game:
- Fresh features under rapid iteration
- Animation-heavy flows or UI edge cases
- Anything requiring judgment, timing, or eyes
Also? When your dev team pushes daily, and your automation tests fail daily, you learn the hard way that false positives kill trust. That failing test suite becomes background noise—and that’s worse than having no tests at all.
Manual QA lets me move fast, validate changes with context, and keep the team confident. Automation kicks in when the dust settles.
I touched on this balance in Balancing Manual, Automation, and AI-Driven Testing in Real-World Projects.
How I Decide What to Automate (and What to Skip)
My rule of thumb: If it’s stable, repeatable, and annoying to test more than twice, automate it.
I don’t automate bleeding-edge features. I don’t automate flows that change weekly. And I don’t automate just to say we’re doing automation.
I started scripting because it gave me leverage—title, trust, and skill. But that only worked because I didn’t overdo it. I knew when to skip automation entirely and just run manual sanity.
Now, my automation exists to support QA, not replace it. Most of the tests follow user logic, especially on React, Vue, Next.js, and Rails projects. I write what’s necessary. Nothing more.
And when performance became a concern, I didn’t pretend to know it all—I did the research and built How to Optimize Playwright Scripts for Performance Testing to break down what actually worked.
What’s Next: Trying CI/CD (Without Faking DevOps Expertise)
Eventually, stable scripts deserve a pipeline. I’m not there yet—but I’m getting there.
For now, I’m working on a practical test:
- Repo: qajourney-automation-lab
- Target: playground.qajourney.net
- Goal: Use GitHub Actions to run Playwright tests on push
I might even spin up a new test page on the playground to serve as a CI/CD test target. Not for show. For learning.
This will be a follow-up post: “Trying CI/CD as a QA Lead: What Worked, What Didn’t”
Final Thoughts
If you’re a QA lead or tester who’s not fluent in CI/CD, Docker, or infrastructure—that’s fine. You can still use tools like Playwright to add serious value.
You don’t need to be an automation engineer. You just need to know when automation helps, when it hurts, and when it’s time to let manual QA do what it does best.
Playwright didn’t turn me into a DevOps wizard. It turned me into a more dangerous QA.
And sometimes, that’s more than enough.
If you hear “flaky tests” and your brain twitches—good. That’s your QA gut speaking. Listen to it.