End to End is Usually Not End to End

What? Why?

I’ve recently noticed that we kind of use end-to-end for almost anything that involves more than one tiny part of the system. That is not completely wrong of course, but I find it misleading anyway, I’ll try to explain why.

My current situation is something along these points:

• we build one platform (solution) for our users
• the platform really consists of multiple separate applications that have to work together in order to provide the final solution for the users
• if any of those apps is bugy, it is a problem that has a potential to affect the overal experience for the users
• we have teams focused mostly on single applications
• then there are a few people who are focused more on the platform as a whole; I’m part of one of these platform teams (although I’m focused more on “user onboarding” which for our team transletes to authentication and authorization processes)

Having said that, I think there are a few pain points:

• testers often completely ignore anything beyond the boundaries of the app their team works on
• the automated checks that have been created are structured along the boundaries of these apps

The second point is what I want to focus on from now on.

When I think about end-to-end as an expression, I think it’s important to ask end-to-end for whom? For a developer? For a tester? For insiders? For our users and customers?

We in our company see the internals of the system and apps, that already makes such a huge difference. So when we refer to something as end-to-end, it’s often something that’s not even noticeable for the users.

One example: our users can search for events on the homepage. This simple task involves at least two systems (depending on where they are taken if the event was found or not, if they log into the event etc.).

Internally, just going to the homepage and searching for an event is already something we refer to as end-to-end. Fine. Not wrong. But it’s more like this is end-to-end only for us. Because it’s unlikely the user would just search for an event (we also want them to do more). The user typically searches for an event for a reason — the reason being they can join the event, and do something inside it (ask questions, vote, participate in quizzes, consume other people’s content, …). Do you see how the definition of end-to-end changed when I considered someone else’s point of view?

This sometimes creates real problems when something is tested, and checked with automated checks, with the internal e2e definition in mind, but the users use the solution with their e2e definition. One example that comes to mind:

log in => app A => click on a button => app B

This is an example flow that can happen with our solution. This is something our users do thousands of times a day. But how we often check it? Something like this:

log in

log in => app A

app A => click on a button

app B

click on a button => app B

There’s little what customers would call end-to-end, especially with automated checks that almost never focus on more than two parts (apps) in a flow.

I guess I can also say that we sometimes lack the big picture, or that there’s not enough integration testing.

Going back to the automated checks I mentioned before, I think that one of their biggest minuses is that they are created with the knowledge of the internals of the solution. I mean it cannot happen differently, but they also stay like that, so they end up checking something that is only a part of the picture for the user.

In other words, I think what I want to say is that the user is many times completely taken out of the picture when testing, and definitely many times when creating automated checks. What those checks end up checking is just a part, a tiny one really, of what the users really care about.

That said, I’m not advocating for not creating any checks, far from that. I’m, however, advocating for better checks, and for being aware of this and using human exploratory skills when testing for problems that real users might consider important. Sometimes I feel this side of testing is completely left out, or not mentioned, or forgotten?