End-to-end tests: key considerations for designing them with confidence

End-to-end (E2E) testing ensures your system works in the real world, helping prevent costly failures. Read on to learn why it matters, the challenges to expect and how to design E2E tests that fit your context.

What is end-to-end testing?

End-to-end (E2E) testing simulates real user journeys to make sure your application works as intended. Unlike unit tests, which check small pieces of code in isolation, E2E tests simulate entire user flows — like logging in, submitting a form or searching your site. They catch issues that only show up when all the parts of your system come together in real-world scenarios.

Why it matters (especially for high-stakes systems)

End-to-end (E2E) tests play a key role in modern testing strategies, especially for mission-critical applications. When people rely on your services, a broken user flow is more than an inconvenience — it can disrupt lives and damage trust. Consider what happens if:

• A job seeker can’t submit their CV online because of a UI bug
• A parent can’t renew child care support because of a failed third-party API
• A student can’t complete an application for financial support due to a missed edge case

E2E testing helps catch issues like these before they impact your audience — and before they become more costly to fix. By running E2E tests on lower environments before deploying changes, you’ll build confidence that critical user journeys will continue to work.

Key considerations for setting up E2E tests

Setting up E2E testing takes planning. You’ll need to involve stakeholders early, decide what environments to use, gather feature specifications to inform test coverage, and plan how the tests will run and be maintained. Here are some of the big considerations:

Optimizing your E2E testing coverage

It’s rarely practical to aim for 100% coverage for your end-to-end testing. You’ll get more value by focusing on the code you touch most often and the critical processes that must not fail — such as logins, payments or applications. Layering unit, integration and end-to-end tests will provide solid protection without unnecessary overhead.

Knowing when to run E2E tests

Unit tests typically run right before a change is merged. The right time to run integration and end-to-end tests depends on a few factors — but in general, as early as possible and triggered automatically by a pull request. For systems with background or overnight jobs, it can be useful to schedule E2E tests to run on a cadence (like every morning) to confirm that critical flows are still working. This may require extra planning, especially if some jobs are dependent on others. 

Shaping tests that work for your context

The complexity, workload, and depth of E2E testing is always specific to your system and your testing requirements.

For example, a simple chatbot test might involve navigating to the bot, entering some information, and checking that the response looks as expected. It’s basic, but it confirms that the bot was deployed correctly, permissions are in place, and the back-end systems can talk to each other.

At the other end of the spectrum, you could design a much more complex test. Imagine starting with an empty knowledge base, running a web scraper to add new information, indexing that content, and then querying the chatbot to confirm it’s using the knowledge base correctly.

These examples highlight why it’s so important to gather detailed testing requirements from the feature team up front — without them, you risk over-engineering a test that drains resources or under-scoping a test that leaves critical gaps.

Adding new environments

Many teams start with only development and production environments, but you may need to create a dedicated testing environment to run E2E reliably and efficiently. This may mean additional work, as well as a small increase in hosting costs.
I know some teams that work with as many as five full-time environments, including a regularly updated copy of production. This lets them catch any final issues — like bugs caused by database changes — before pushing code to production.

Creating and managing mock data

Some E2E tests require mock data that needs to be created, stored, retrieved and verified. In some cases, reusing the same data makes tests unreliable because it can be altered by other processes. This means your test may fail — not because something is actually wrong, but because something else interfered. Ideally, you’d generate fresh data for each run and discard it afterward. This adds complexity, so be prepared for more planning and discussion.

Working around third-party code

Getting your E2E tests to interact successfully with third-party code can be tricky. For example, you can’t customize selectors — you’ll simply need to choose the best ones available and find clever workarounds, writing clear code that makes up for poor selectors. 

Keeping E2E tests stable during UI changes

E2E tests often interact through the browser, which makes them sensitive to UI changes. Something as small as a changed identifier can break a test. And I once saw an E2E test fail because a new pop-up ad from the sales team blocked it from interacting with the normal interface. Strategic test writing and good tooling (like Playwright) helps prevent breaks, but you should expect to spend time maintaining your end-to-end tests — especially when the UI is evolving rapidly.

Making results easy to see and act on

An intentional approach to E2E testing includes making results clear and accessible. Raw output in the terminal or a testing tool’s UI can contain valuable insights — but interpreting it can be time-consuming, complex, and too technical for many team members. 

Invest in a better way for team members to consume results — whether through dashboards, alerts, or blocked pull requests — and ensure failures are easy to act on. It’s also worth defining a shared language around your tests. Even short documentation prevents confusion and keeps everyone aligned as teams grow.

Need help? Hire an E2E testing partner

For mission-critical public systems, E2E testing is a worthy investment that prevents costly failures and provides peace of mind. Yet it can be complex and time-consuming to implement. Working with an experienced partner can help you define priorities, assess capabilities, and design tests that fit your unique context.

At Last Call Media, we specialize in comprehensive testing for multi-vendor, high-stakes systems. Just as importantly, we equip your team to maintain E2E tests in-house — giving you lasting confidence without vendor lock-in. Get in touch to learn how we can help.