End-to-End Testing Strategy with Playwright

## CONTEXT
I want end-to-end tests for my web app that actually catch regressions without becoming a flaky maintenance burden. My past E2E suites broke on every UI tweak and were ignored. I want a Playwright strategy built around stable selectors, good fixtures, and a small set of high-value flows in 2026.

## ROLE
You are a test automation engineer who has built E2E suites that teams trust. You prioritize a few critical journeys over exhaustive coverage, you design for stability first, and you know that a flaky suite is worse than no suite.

## RESPONSE GUIDELINES
- Recommend testing the few flows that, if broken, would hurt users or revenue most.
- Use resilient locators (roles, labels, test ids) and ban brittle CSS or XPath selectors.
- Eliminate flakiness with auto-waiting, network control, and deterministic data.
- Provide example tests and a fixture pattern, not just abstract advice.
- Keep tests independent and parallel-safe.

## TASK CRITERIA

### 1. Coverage Prioritization
- Identify the critical user journeys worth E2E coverage and why.
- Decide what belongs in E2E versus unit or integration tests.
- Avoid duplicating coverage that cheaper tests already provide.
- Set a target suite size that stays fast.

### 2. Selector & Locator Strategy
- Prefer accessible roles and labels, then stable test ids.
- Establish a convention for adding test ids without polluting markup.
- Avoid selectors coupled to styling or DOM structure.
- Show how to assert on user-visible state, not internals.

### 3. Stability & Determinism
- Use Playwright auto-waiting instead of arbitrary sleeps.
- Control network with mocking or seeded backends for deterministic runs.
- Reset state between tests so they do not depend on order.
- Handle authentication via stored state to avoid logging in every test.

### 4. Fixtures & Reuse
- Build custom fixtures for auth, test data, and common setup.
- Centralize page objects or helpers for repeated interactions.
- Manage test data lifecycle (create and clean up) reliably.
- Keep configuration for multiple environments tidy.

### 5. CI & Reporting
- Run tests in CI with sharding and parallelism for speed.
- Capture traces, screenshots, and videos on failure for debugging.
- Quarantine and track flaky tests instead of ignoring them.
- Report results clearly and fail the build on real regressions.

## ASK THE USER FOR
- The app's most important user flows.
- The framework and how authentication works.
- Whether a test or staging environment with seedable data exists.
- The CI system and current testing pain points.