The biggest Playwright lesson I’ve learned isn’t about Playwright at all.

It’s about discipline.

I’ve seen teams switch from Selenium to Playwright expecting flaky tests to magically disappear. The framework changes. The habits don’t.

A few patterns show up again and again:

→ waitForTimeout() everywhere instead of waiting for real conditions
→ Fragile CSS selectors that break with every UI change
→ Shared test data causing random failures
→ Hundreds of lines of test code with no structure or Page Objects
→ A test suite that nobody trusts during release week

Playwright is fast. Playwright is reliable. But only when we use it the way it was designed.

Some practices that consistently work:

✓ Use assertions and explicit waits, not arbitrary sleeps
✓ Prefer data-testid and accessible selectors
✓ Keep tests isolated with fresh browser contexts
✓ Manage test data through APIs whenever possible
✓ Structure automation using Page Object Model
✓ Run tests continuously in CI/CD with fast feedback loops

The uncomfortable truth?

Most flaky Playwright suites aren’t failing because of Playwright.

They’re failing because we’ve carried old automation habits into a new framework.

Tools don’t create quality.

Quality comes from engineering discipline, thoughtful design, and treating test automation as a software product—not a collection of scripts.

17 Common Playwright Mistakes That Create Flaky Tests

Here’s the uncomfortable truth: frameworks don’t eliminate poor engineering habits. Playwright can be just as flaky as any other tool if the underlying automation practices are weak.

Let’s break down the 17 most common Playwright mistakes we see teams make — and how experienced QA engineers avoid them to build automation that’s fast, stable, and genuinely trustworthy.

---

Quick Answer: What Causes Flaky Playwright Tests?

The most common causes of flaky Playwright tests are poor waiting strategies, fragile selectors, shared test data, lack of test isolation, weak assertions, and improper CI/CD integration. Fixing these six areas resolves the majority of flakiness most teams encounter.

---

Mistakes at a Glance

Mistake	Impact
Using waitForTimeout()	Random failures and slow execution
Fragile selectors	High maintenance costs
Shared test data	Intermittent failures
Lack of test isolation	State leakage between tests
Ignoring API setup	Slow execution
Poor Page Object implementation	Difficult maintenance
Running everything serially	Long CI pipelines
Weak assertions	False positives
No retries or tracing	Difficult debugging
Testing everything through UI	Slow and brittle suites

---

Mistake #1: Overusing waitForTimeout()

Hardcoded waits are the single most common source of flakiness in Playwright suites. A waitForTimeout(3000) might work on your machine and fail in CI the moment the environment is slightly slower.

Fix: Use explicit waits tied to actual application state, not arbitrary time delays.

await expect(page.getByText('Success')).toBeVisible();

Playwright’s built-in assertions already retry automatically until the condition is met — you rarely need a manual timeout at all.

Mistake #2: Misunderstanding Auto-Waiting

Playwright automatically waits for elements to be actionable — visible, stable, enabled, and receiving events. But auto-waiting doesn’t know about your business logic. It won’t wait for an API call to finish or a toast notification to disappear on its own.

Fix: Pair Playwright’s actionability waits with explicit assertions on business-relevant states (API responses, loading spinners, data appearing in the DOM).

Mistake #3: Using Fragile Selectors

CSS classes and DOM structure change constantly as UI evolves. Selectors tied to styling (.btn-primary-v2) break the moment a developer refactors a component.

Fix: Prefer data-testid attributes and accessible role-based locators that are stable across UI changes.

Mistake #4: Ignoring Accessibility Selectors

Beyond stability, accessibility-based selectors force your app to actually be accessible — a nice side benefit of good test design.

Fix: Use getByRole() and getByLabel() wherever possible instead of XPath or deeply nested CSS selectors.

Mistake #5: Poor Page Object Model Design

Overly broad Page Objects — with 50+ methods covering multiple pages — become unmaintainable fast. Every UI tweak forces a ripple of changes.

Fix: Keep Page Objects focused on a single page or component. Small, composable objects are far easier to maintain than monolithic ones.

Mistake #6: Shared Test Data

Two tests running in parallel that touch the same user account, order, or record will step on each other — causing failures that only appear intermittently and are painful to reproduce.

Fix: Generate isolated, unique test data per test run (dynamic emails, unique IDs, factory-generated records).

Mistake #7: Testing Setup Through the UI

Logging in, creating prerequisite records, or navigating through five screens just to reach the actual test scenario wastes time and introduces unnecessary points of failure.

Fix: Use API calls for setup and teardown, and reserve UI interaction for the actual behavior under test.

Mistake #8: Lack of Test Isolation

Tests that depend on execution order or leftover state from a previous test are a maintenance nightmare — they pass locally, fail in CI, and nobody can figure out why.

Fix: Use fresh browser contexts per test. Playwright makes this cheap and fast, so there’s little reason not to.

Mistake #9: Running Tests Sequentially

Sequential execution might feel “safer,” but it dramatically slows down feedback loops as your suite grows.

Fix: Enable parallel execution. Playwright is built for it — combined with proper isolation (Mistake #8), parallelism is usually safe by default.

Mistake #10: Weak Assertions

Asserting that a button merely “exists” doesn’t verify the feature actually works. Weak assertions give false confidence.

Fix: Assert on business outcomes — the correct data was saved, the correct total was calculated, the correct state was reached — not just implementation details like element presence.

Mistake #11: Ignoring Tracing

When a test fails in CI, teams without tracing enabled are left guessing what went wrong, often re-running the pipeline repeatedly to catch the failure “in the act.”

Fix: Enable Playwright’s built-in tracing on failure. It captures screenshots, DOM snapshots, and network activity — turning a 30-minute investigation into a 2-minute one.

Mistake #12: No Retry Strategy

Zero retries means one infrastructure hiccup fails your whole build. Excessive retries mask real flakiness and hide legitimate bugs.

Fix: Use retries carefully and sparingly — as a safety net for genuine environment flakiness, not as a substitute for fixing unstable tests.

Mistake #13: Testing Implementation Details

Tests tightly coupled to internal implementation (specific class names, internal state, component structure) break every time the code is refactored, even when behavior hasn’t changed.

Fix: Focus tests on user-facing behavior — what the user sees and does — not how the feature is built internally.

Mistake #14: Treating Automation as “QA-Only”

When automation is owned solely by QA, developers ship changes without considering test impact, and the suite becomes a bottleneck rather than a safety net.

Fix: Treat quality as a shared responsibility. Developers should write and maintain tests alongside features, with QA providing strategy and review.

Mistake #15: Ignoring CI/CD Integration

Automation that only runs manually, or once a week, catches bugs far too late — often after they’ve already reached production.

Fix: Run your Playwright suite on every pull request, so regressions are caught before merge, not after deployment.

Mistake #16: Lack of Monitoring

Without visibility into flaky test trends over time, teams repeatedly “fix” the same tests without addressing root causes.

Fix: Track flaky test rates, failure patterns, and runtime trends over time — treat test health as a metric worth reporting, just like code coverage.

Mistake #17: No Automation Standards

Without shared conventions, every engineer writes tests differently — different selector strategies, different assertion styles, different folder structures — making the suite harder to scale and onboard new engineers into.

Fix: Create team-wide guidelines covering selector strategy, folder structure, naming conventions, and review standards for automation code.

---

Frequently Asked Questions

1. What causes flaky Playwright tests? Poor waiting strategies, fragile selectors, shared test data, lack of isolation, weak assertions, and missing CI/CD integration are the leading causes.

2. Is Playwright better than Selenium? Playwright generally offers faster execution, built-in auto-waiting, and better multi-browser support out of the box, but “better” depends on your team’s existing stack and expertise.

3. What selectors should I use? Prioritize data-testid attributes and accessible role-based locators (getByRole, getByLabel) over CSS or XPath selectors.

4. Should I use Page Object Model? Yes, but keep objects small and focused per page or component rather than building large, monolithic classes.

5. How do I speed up Playwright tests? Enable parallel execution, use API calls for setup instead of UI navigation, and avoid unnecessary hardcoded waits.

6. How do retries work in Playwright? Playwright can automatically re-run failed tests a configured number of times, useful for absorbing genuine environment flakiness — but shouldn’t mask real bugs.

7. How do I debug Playwright test failures? Enable tracing on failure to capture screenshots, DOM snapshots, and network logs for each failed test.

8. What is test isolation? Ensuring each test runs independently, with its own data and browser context, so no test’s outcome depends on another’s execution.

9. How should I manage test data? Generate unique, isolated data per test run rather than relying on shared or static fixtures.

10. What is auto-waiting in Playwright? Playwright automatically waits for elements to become actionable (visible, stable, enabled) before interacting with them.

11. When should I use API setup instead of UI setup? Whenever you’re establishing preconditions (login, creating records) rather than testing the behavior itself.

12. How do I parallelize Playwright tests? Configure workers in your Playwright config and ensure tests are properly isolated so they can run concurrently without conflicts.

13. What is tracing in Playwright? A built-in feature that records a detailed timeline of a test run — screenshots, actions, and network requests — for post-failure debugging.

14. How do I integrate Playwright with CI/CD? Run your test suite as a required check on every pull request using your CI provider (GitHub Actions, GitLab CI, Jenkins, etc.).

15. What are Playwright best practices? Stable selectors, proper waits, test isolation, API-based setup, strong assertions, and CI integration form the foundation of reliable automation.

16. How do I reduce test maintenance? Use resilient selectors, focused Page Objects, and team-wide automation standards to minimize the ripple effect of UI changes.

17. Why do tests fail only in CI, not locally? Usually due to timing differences, missing waits, or environment-specific data/state issues that don’t surface on a developer’s faster local machine.

18. How should I structure Playwright projects? Organize by feature or page, separate Page Objects from test specs, and keep fixtures/utilities in shared, reusable modules.

19. How do I improve overall test reliability? Address the top causes of flakiness first — waits, selectors, isolation, and data — before adding more tests to the suite.

20. What metrics should I monitor for test health? Flaky test rate, average run time, failure frequency by test, and time-to-fix for broken tests.

---

Conclusion

Playwright is one of the most powerful test automation frameworks available today. But sustainable automation success doesn’t come from the framework alone — it comes from engineering discipline, maintainable architecture, and strong quality practices applied consistently across the team.

Most Playwright failures aren’t caused by Playwright. They’re caused by engineering habits. Fix the habits, and the flakiness goes away.

Curious: What’s the most expensive Playwright mistake you’ve seen a team make?

Bookmark