पाठ 25 / 25

An E2E Testing Checklist

Review before you trust a suite.

Questions to ask

Do the tests cover the critical user journeys and leave edge cases to lower layers? Are selectors user-facing (roles, labels) or dedicated test ids? Are there zero fixed sleeps, with assertions that retry? Does each test create its own data and run in any order? Is login reused through storageState or cy.session? Are third-party services stubbed while some tests still hit the real API? Are traces, screenshots and reports uploaded from CI, with retries reported as flaky? Is the suite fast enough to run on every pull request, using workers and shards where needed?

The checklist

Use it in reviews.

# [ ] critical journeys covered; details tested lower in the pyramid
# [ ] role / label / test-id locators; no styling-based CSS selectors
# [ ] no fixed sleeps; retrying assertions everywhere
# [ ] each test sets up its own data; unique names; order-independent
# [ ] login reused (storageState / cy.session); one real UI login test kept
# [ ] external services stubbed; some tests against the real backend
# [ ] visual + accessibility checks on key pages
# [ ] CI: headless, retries in CI only, reports/traces/screenshots uploaded
# [ ] parallel workers / shards; suite fast enough for every PR
# [ ] flaky tests tracked and fixed, not just retried

Treat test code as production code

Review it, refactor it and delete tests that no longer earn their run time. A small, trusted suite beats a large ignored one.

त्वरित जाँच: Which belongs on an E2E checklist?

  • Fixed sleeps after every click
  • Tests share one account and must run in sequence
  • Each test creates its own data and can run in any order
  • Selectors based on nth-child and styling classes
Answer

Each test creates its own data and can run in any order — Isolation and stable selectors keep suites reliable.