How I Learned to Stop Worrying And Love End-to-End Testing
Test and Monitor | Posted February 07, 2018

What is End-to-End Testing?

This is a harder question to answer than you might think, because different QA roles can refer to very different testing approaches as “end-to-end.”

Often, more technical testers or developers consider End-To-End as following the technical stack: for example, following one piece of data through the UI, API, Database layers. This follows your application’s Data Journey and is sometimes referred to as “Vertical” End-to-End testing and it is meant to ensure that all layers of an application are integrating correctly.

More traditional or manual testers usually refer to “Horizontal” End-To-End tests; following the User’s Journey through the application. Often this journey is broken into smaller workflows to keep the test sizes manageable. This type of E2E test is meant to ensure that a user can functionally perform the main activities of your application.

For example, let’s take the Horizontal User Journey of purchasing an item on an ecommerce platform and the Vertical Data Journey at the point of Checkout.

Observant readers or those familiar with ecommerce may note that there are many other Data Journeys such as the Purchase flow, or recommendations for other purchases when an item is added to an Order.

Thorough End-To-End Tests use both Horizontal and Vertical test approaches to fully cover the entire workflow or experience of BOTH the Data and the User. Very thorough tests also include responsivity/timings as pass criteria, not just functional performance.

Two Approaches to build End-To-End Tests: Top-Down and Bottom-Up

When beginning to build End-to-End tests, the natural inclination is to utilize your functional tests and “stitch” them together to form a more complete workflow. This Bottom-Up approach can be quick as you are reusing existing assets, but frequently falls into biasing E2E tests towards existing coverage and a very functional assessment.

A better approach is to go Top- Down and start from the actual Workflow (both horizontal and vertical) in question and break it down into smaller pieces. Each piece can then be evaluated and the proper testing approach (such as manual, automated, exploratory, etc…) applied. This approach adds coverage, removes the bias existing assets introduce, and more fully tests the actual experience.