5 Playwright Patterns That Eliminated Flaky Tests on My Team

If you run a test suite long enough, flaky tests become the background radiation of your CI pipeline. Green on retry, red on Tuesdays, mysteriously passing on your laptop but failing in CI. I spent years fighting this at companies like Amazon, Tinder, and now Motorola Solutions — and I finally have a playbook that actually works.

Here are five Playwright patterns that took our end-to-end pass rate from 74% to 99.2% in under six weeks.

1. Replace Hard Waits with Auto-Retrying Assertions

The single biggest source of flakiness I see on teams is page.waitForTimeout(3000). It's a guess. Sometimes three seconds is enough, sometimes it isn't.

Playwright's auto-retrying assertions like expect(locator).toBeVisible() and expect(locator).toHaveText() poll the DOM automatically until the condition is true or the timeout expires. No guessing. No arbitrary sleeps.

Before: Tests that passed 80% of the time. After: The same tests passing 99%+ because they wait for exactly what they need.

2. Use Web-First Locators Instead of CSS Selectors

CSS selectors are brittle. A designer changes a class name and suddenly 40 tests break. Playwright's web-first locators — getByRole(), getByLabel(), getByText() — find elements the way a user would.

I migrated our entire suite from CSS selectors to role-based locators over a single sprint. The number of "locator not found" failures dropped by 85%. Bonus: your tests now double as accessibility audits.

3. Isolate Test State with API Setup

Every test that clicks through a login flow, creates a user, and navigates three pages just to test a single button is a test waiting to break. We moved all setup into API calls using Playwright's request fixture.

Our tests now create their own users, seed their own data, and tear it down — all via API. Each test is independent. Parallelization went from "terrifying" to "trivial."

4. Leverage Trace Viewer for Debugging — Not Console Logs

When a test fails in CI, most engineers add console.log statements and re-run. That's a 10-minute feedback loop at best. Playwright's Trace Viewer captures a full timeline: screenshots, DOM snapshots, network requests, and console output — all in one interactive UI.

We configured traces to capture on first retry. Now when a test fails, the engineer opens the trace, scrubs to the failure point, and sees exactly what happened. Average debug time dropped from 45 minutes to under 10.

5. Shard Tests Across CI Workers

A 60-minute test suite is a 60-minute bottleneck on every PR. Playwright's built-in sharding (--shard=1/4) distributes tests across parallel CI workers with zero configuration.

We shard across four GitHub Actions runners. Total wall-clock time: 14 minutes. And because each shard runs fewer tests, flakiness from resource contention dropped too. Win-win.

The Results

After implementing these five patterns across our Playwright suite at Motorola Solutions:

• Pass rate: 74% → 99.2%
• Suite duration: 58 min → 14 min
• Weekly flaky-test triage: 12 hours → under 1 hour
• Developer trust in tests: "I'll just skip it" → "If it's red, it's real"

The best part? None of this required exotic tooling or a framework migration. It's all built into Playwright today.

What I'd Do Next

If you've got these basics locked down, the next frontier is AI-powered self-healing locators. I've been experimenting with using local LLMs via Ollama to dynamically regenerate broken selectors — and the early results are promising.

QA automation isn't about writing more tests. It's about writing tests that actually tell you the truth. These five patterns are how you get there.

— Suneet Malhotra, Sr. Manager of Test Engineering at Motorola Solutions