End-to-End Test Strategy Template

Fewer than you think. The testing pyramid suggests E2E tests should be the smallest layer. A typical SaaS product with 20-30 user flows might have 30-50 E2E tests covering P0 and P1 flows. If you have 200+ E2E tests, you likely have tests that belong at the integration or unit level. E2E tests should validate user journeys, not individual UI components. The [test strategy template](/templates/test-strategy-template) helps you decide which test type is appropriate for each area.

For most tests, bypass the login UI. Use API calls or direct cookie/token injection to authenticate before the test starts. Only the actual login and signup flow tests should interact with the login form. This makes every other test faster and less fragile. Store test credentials in CI environment variables, never in test files.

Industry standard target is below 5% suite-level flake rate. Individual tests should be below 2%. Above these thresholds, developer trust in the test suite erodes and people start ignoring failures. Track flake rates in your CI dashboard. When a test exceeds 10% flake rate, either fix the root cause or delete the test. A test you cannot trust is worse than no test.

Run your P0 suite (critical happy paths) on every PR. This typically takes 5-10 minutes and catches the most impactful regressions. Run the full suite (including P1, P2, edge cases, and cross-browser) nightly. This gives you broader coverage without slowing down every PR. The [smoke test template](/templates/smoke-test-template) helps define the minimal subset for PR checks.

Use the Page Object pattern (or equivalent) to centralize UI selectors. When a button moves or gets renamed, you update one file instead of 15 tests. Use data-testid attributes on key elements so tests do not break when CSS classes or text content changes. Delete tests for removed features immediately. A 200-test suite with 50 tests for features that no longer exist is a maintenance burden that provides zero value. ---