An end-to-end suite is only useful if a red run stops a deploy. The moment a team starts re-running failures until they pass, the suite has become decoration — and flakiness, not coverage, is what gets it there.
What we automate
Signup, login, search, add to cart, checkout, payment, the main create-and-save path of the product, and every journey that has broken before. Perhaps a dozen tests that matter, not four hundred that mostly assert that a heading exists.
Written to be stable
- Selectors from roles and test ids, never from CSS that a redesign will change
- Playwright’s own waiting, never a fixed sleep
- Each test creates its own data and cleans up after itself
- No test depends on another having run first
Cross-browser, and mobile widths
Chromium, Firefox and WebKit, plus a mobile viewport for the journeys where most of the traffic actually is. Traces, screenshots and video are captured on failure so a broken run is diagnosed from the artefact rather than reproduced by hand.
Where it runs
On every pull request for the critical set and on a schedule for the full one, inside CI/CD. Against a seeded environment, so a failure means the code changed rather than that someone edited staging data.
Beyond functional checks
The same suite is a good home for accessibility assertions on key pages and for visual comparison on the components a brand cares about. Both catch the regressions unit tests structurally cannot see.
Sits inside the wider practice on QA and testing; compare with Cypress.