E2E test coverage: how much is enough for your SaaS?

The coverage question everyone asks wrong

"What percentage of E2E test coverage should we have?"

It's the wrong question. Chasing a percentage leads teams to write tests that inflate numbers without adding value—testing trivial features while critical paths remain unprotected.

The right question: "Which user journeys would hurt most if they broke in production?"

That question focuses your testing where it matters. For SaaS applications, the answer usually involves signups, core feature usage, billing, and account management. Get those right, and your coverage percentage becomes an irrelevant metric.

Why E2E tests matter (despite being expensive)

E2E tests sit at the top of the testing pyramid. They're slower to write, slower to run, and more expensive to maintain than unit or integration tests. So why bother?

Because research from the University of Illinois found that at least 20% of severe failures in cloud applications stem from cross-system interaction bugs. For open-source applications, that number rises to 37%.

These are bugs that unit tests can't catch. Your payment service might work perfectly in isolation. Your user service might be rock solid. But when they interact during checkout? That's where production breaks.

E2E tests verify the entire flow—from user action to database change to response—catching integration failures before users do.

The testing pyramid for SaaS

A healthy test distribution for most SaaS applications looks like:

Notice E2E tests are intentionally few. They're not meant to test every feature—they're meant to protect critical paths that span your entire system.

What "critical paths" means for SaaS

Your critical paths are the flows where failure causes maximum damage. For typical SaaS products, this includes:

Revenue paths (test these first)

• Signup → Onboarding → First value moment: If new users can't complete signup, you have no business.
• Subscription purchase/upgrade: If users can't pay you, revenue stops.
• Subscription renewal/billing: Existing customer revenue depends on this.
• Payment method updates: Users need to maintain their subscriptions.

Core feature paths

• The primary action users came for: What's your app's main job? Test that flow thoroughly.
• Data creation and retrieval: Users creating and accessing their data is fundamental.
• Key integrations: If you connect to Slack/email/calendar/etc., test those connections.

Account management paths

• Login/logout/password reset: Users must access their accounts.
• Settings and preferences: Configuration changes should persist correctly.
• User management (for teams): Invites, role changes, removals.

Compliance-critical paths

• Data export (GDPR): Required by law in many jurisdictions.
• Account deletion: Same—and often more complex than it seems.
• Audit logs (if applicable): For enterprise customers.

How to prioritize what to test

Not all critical paths are equally critical. Use this framework to prioritize:

Impact matrix

For each potential E2E test, score:

Flows with high scores across multiple factors deserve E2E coverage first.

Example prioritization

Focus your limited E2E budget on the highest-scoring flows first.

The "money paths" approach

Industry experts recommend identifying your "money paths"—the flows directly connected to revenue.

For a SaaS product, typical money paths include:

1. Acquisition path: Landing page → Signup → Email verification → First login
2. Activation path: First login → Onboarding → First meaningful action
3. Conversion path: Free tier → Pricing page → Checkout → Payment confirmation
4. Retention path: Login → Core value delivery → Logout (or session timeout)
5. Expansion path: Settings → Upgrade plan → Payment → Confirmation

If you have 20 E2E tests to write, spend 15 of them on these paths. The remaining 5 can cover your next-highest-risk areas.

Signs your coverage isn't enough

Coverage metrics are lagging indicators. Here are leading indicators that you need more E2E tests:

Production bugs in untested areas

If bugs repeatedly appear in production in areas you don't have E2E tests for, your coverage isn't enough. Track where production bugs occur and cross-reference with your test coverage.

Fear of deploying

When your team hesitates to deploy because "something might break," that's a test confidence problem. Either your tests don't cover critical paths, or they're too flaky to trust.

Manual testing bottlenecks

If every release requires extensive manual testing of the same flows, those flows should be automated. Manual regression testing doesn't scale.

Customer-reported bugs for basic flows

When customers report that signup is broken or they can't access their dashboard, your E2E tests have gaps in critical paths.

Signs you might have too much coverage

Yes, this is a real problem:

Tests for every minor feature

If you have E2E tests for tooltip display, minor UI variations, or rarely-used admin features, you're likely over-testing. These should be unit or integration tests.

Flaky test suite

When you have so many E2E tests that false failures are common, teams start ignoring test results. A smaller, reliable suite beats a large, unreliable one.

Slow CI/CD pipeline

E2E tests are slow. If your test suite takes 45 minutes to run and developers stop waiting for it, you've created a problem. Consider parallelization, test selection, or pruning low-value tests.

High maintenance burden

If maintaining E2E tests consumes more than 20% of your testing effort, you might have tests that aren't providing proportional value.

A practical E2E coverage strategy

Phase 1: Core protection (Week 1-2)

Write E2E tests for:

• User registration and login
• Your single most important feature flow
• Payment/subscription (if applicable)

Goal: Catch the bugs that would shut down your business.

Phase 2: Revenue expansion (Week 3-4)

Add tests for:

• Secondary conversion flows
• Plan upgrades and downgrades
• Critical integrations (email, third-party services)

Goal: Protect revenue-generating paths beyond the basics.

Phase 3: User experience protection (Week 5-8)

Add tests for:

• Key user settings and preferences
• Team/organization features
• Data export and import
• Account management

Goal: Protect flows that drive customer satisfaction and retention.

Phase 4: Ongoing maintenance (Ongoing)

• Add E2E tests for new critical features
• Remove or refactor flaky tests
• Review coverage gaps quarterly based on production bug patterns

Goal: Sustainable test suite that grows with your product.

What not to E2E test

Save your E2E budget by not testing:

Pure UI components

Button colors, padding, font sizes—these belong in unit tests or visual regression tools, not E2E flows.

Third-party functionality

Don't test that Stripe processes payments correctly. Test that your integration with Stripe works. Trust vendors to test their own systems.

Administrative features with low usage

Internal tools used by admins rarely? Keep those for manual testing unless they're genuinely critical.

Every edge case

E2E tests verify happy paths and critical error states. Edge cases like "user enters 500-character name" should be integration or unit tests.

Functionality already covered

If your integration tests verify API validation, your E2E tests don't need to re-test every validation rule through the UI.

Measuring test effectiveness

Instead of coverage percentage, track:

Production bug escape rate

What percentage of bugs reach production that tests should have caught? This measures actual test effectiveness.

Mean time to detect (MTTD)

How quickly do tests catch regressions after code changes? Faster detection = more valuable tests.

Test reliability rate

What percentage of test runs produce accurate results (no flaky failures)? Below 95% reliability indicates tests need attention.

Maintenance time ratio

Time maintaining tests vs. time creating new tests. If maintenance dominates, your suite may be too large or poorly designed.

Frequently asked questions

What percentage of E2E test coverage is standard?

There's no standard percentage. E2E coverage depends on your application's complexity, risk tolerance, and test strategy. Focus on critical path coverage, not percentages.

Should E2E tests run on every commit?

For small test suites (under 15 minutes), yes. For larger suites, run critical tests on every commit and full suites on merge to main or scheduled runs.

How do I handle E2E test flakiness?

Flaky tests erode trust. Fix them immediately, quarantine them, or delete them. A passing flaky test is worse than no test—it provides false confidence.

Should I test mobile and desktop separately?

For responsive SaaS apps, test critical paths on at least one mobile viewport. Full mobile coverage depends on your actual mobile user percentage.

When should I add E2E tests for new features?

Critical or revenue-impacting features get E2E tests immediately. Lower-risk features can rely on integration tests, with E2E added later if bugs emerge.

---

The right amount of E2E coverage isn't a number—it's the confidence to deploy without fear. Start with your money paths, expand based on risk, and maintain ruthlessly. When your tests catch regressions before users do, and your team deploys with confidence, you have enough coverage.