Automation is leaving me without coffee.

Every morning I have a simple routine:

I walk my child to school, then stop by a store and buy two cups of coffee, one for me and one for my wife.

And for the past few months, I have been regularly breaking the coffee machine.

The failure pattern

The scenario is always the same.

I order the first cup, take it, and immediately start ordering the second one.

And at that moment, the machine freezes.

After looking into it, I understood why.

The machine is designed to accept a new order only after the previous one is fully completed, when the welcome screen appears again.

If you start too early, it gets stuck between states.

As someone who works with automation, I understand the solution:

just wait a couple of seconds.

And if I do it the right way, everything works.

But as a regular person, I do not do that.

I am standing there with shopping bags, reading something on my phone, thinking about something else, and just acting out of habit.

I order the second cup right away.

And again, a broken machine.

Why this matters

In a month, I use this machine about 22 times.

And roughly half the time, I leave with just one cup.

But the problem is not really me.

When the machine freezes, it cannot be fixed quickly.

The staff try to reboot it, it does not help, and then it can stay out of service for several days.

So one wrong user creates a problem that affects the revenue of the whole location.

The real lesson

Here is what is interesting.

I understand how the system works.

I know what is correct.

It is not even in my interest to make this mistake.

But I still make it.

Because I behave like a normal person, not like the person who designed the system.

And that is the essence of automation:

the people who use it are not the ones who built it.

People do not read instructions.

People are in a hurry.

People do what is convenient, not what is correct.

And if a system breaks because of that behavior, the problem is not the people.

The problem is the system.

What testing should actually mean

That is why testing is not just about running the expected scenario.

It is about trying to break your own automation:

• make an extra click
• start the process too early
• interrupt it halfway
• go back
• perform two actions in a row

And see what happens.

I usually give automation a week of real-world use.

I watch where processes fail, which errors are critical, and which ones can be ignored.

And almost always, something comes up that you could never predict in theory.

Because a real user is always more inventive than you think.

And sometimes, that user just wants two cups of coffee.