What is E2E
in software testing?

The full narration of the video.

You order a milk tea on your phone and tap Pay. Behind that one tap, several parts pass the job along like a relay. The button hands your order to a computer far away. That computer takes the payment, then sends the order to the shop. Finally, your phone shows: Order placed. The people who build it need to be sure of one thing: this whole path works, every single time.

The most common way is to check each piece on its own. Like a relay team, where you first time each runner alone. But even if every runner is fast, the baton can still drop at the handoff. Checking pieces alone will never catch that. So there's another kind of check: a robot goes through the whole thing from start to finish, just like a real user. That's called end-to-end testing, or E2E for short.

The ends are the two ends of the path. One end is your finger tapping; the other is the result you finally see. The robot follows a script: open the page, pick the milk tea, tap Pay. Then it checks the answer. If it sees Order placed, the light turns green. If not, it turns red, and many tools snap a picture of the screen at that moment.

It's the closest thing to a real person using the app, so it gives the most confidence. But it has a catch: it's slow. Checking one piece takes a blink. Walking the whole path takes seconds, sometimes much longer. It also raises false alarms. A slow network or a surprise pop-up, and it thinks something broke. And when something really breaks, it's hard to tell which handoff dropped the baton. So experienced teams build something like a pyramid. At the bottom, lots of checks on single pieces. In the middle, fewer checks on the handoffs. At the top, just a few of the most important start-to-finish runs.

In 2015, Google's testing team suggested a rough split: seventy, twenty, ten percent. Every team's mix is different, but the shape is about the same. Next time you tap Pay and it just works, chances are a robot already walked that path for you.