openskills.info
Course catalog
Course Preview

End-to-End Testing

End-to-end testing runs a complete user journey through a deployed application and its connected parts. It checks that the interfaces between the browser or client, services, data stores, and external dependencies produce the expected observable result.

itSoftware engineering

End-to-End Testing

End-to-end testing exercises a complete user journey through a running application. A test starts at a real entry point, such as a browser or mobile interface, crosses the same application boundaries used in production, and checks an observable result. A checkout test might sign in, add an item, submit payment through a controlled test integration, and confirm the resulting order.

The defining feature is scope. A unit test checks one small piece of code. A component test checks a larger unit behind a controlled boundary. An integration test checks that selected parts communicate. An end-to-end test follows a valuable path across the assembled system. The names overlap between teams, so document which boundaries each suite includes.

End-to-end tests answer a narrow but important question: can the assembled system complete this journey in this environment? They do not prove that every input, path, browser, or failure mode works. A small set of high-value journeys complements broader coverage at lower test levels.

The system under test

A web end-to-end test usually involves these parts:

  1. A test runner discovers cases, controls setup and teardown, evaluates assertions, and reports results.
  2. A browser driver or browser automation protocol sends navigation, input, and inspection commands to a browser.
  3. The application under test serves the user interface and processes the journey through its services.
  4. A test environment supplies configuration, databases, queues, identity, and controlled external dependencies.
  5. test data puts the environment into a known starting state.
  6. artifacts such as traces, screenshots, video, logs, and reports explain what happened.

The control path and application path are different. The runner tells the browser what a user would do. The browser sends normal application requests. The services change state and return responses. The runner then observes user-visible behavior or another approved boundary and compares it with the expected result.

This separation matters during diagnosis. A failed click may mean the locator found the wrong element, the element never became actionable, the browser could not reach the page, or the application did not render the control. The failure message alone rarely identifies the layer at fault.

Continue the course

This section is part of the paid course.

See pricing to subscribe, or log in if you already have access.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources