Explain why developers are bad at testing their work, like I am five

Your mom says you are good looking.

Generally, they're not. They're bad at manually testing their own code, because they're too close to it. Kind of like how an author writes a story, and then a proof-reader picks apart all the obvious mistakes they didn't notice.

Developers can be good at writing tests, they can be good at anticipating strange conditions and at writing their code defensively, but they can't always see the wood for the trees.

People are bad at checking their own work.

Ever wrote a 10 page document, looking it over again and again, not seeing a single error. And then hand it over to somebody else who finds an error within a minute in the first paragraph?

You did not see the problem because your brain had made assumptions about the content.

The same happens with software. You've already filtered out problem states when you start testing.

To make anything you need a special kind of mindset.
To break the same thing you need the opposite mindset.
Now just for the sake of argument lets suppose you are equally good at both said trains of thought.
It still takes time to adjust your mentality from one to the other.
So it's fair to say "point of view" is a factor.

Cheers.

Some do suggest developers are too protective of their own code, but I'm certain 99.99% of developers would actually prefer to get their code broken early on, rather than having to deal with shouting boss' boss 2-3 months after deployment.

In my opinion the actual reason is lack of time.

Once you are pressed for deadlines, there's direct conflict of interest, and it's easy for everything becomes about meeting the deadline and less about quality of both tests and deliverables.

What developers probably are bad at is asking for that additional time up-front for testing and fixes. Management of course can be as bad at allowing that extra time, so it's a team job to get it working.

There are of course some other factors like superior domain knowledge or lack of user empathy that could affect ability to come up with right tests, but these should be easier to overcome if necessary time is available.

You want to bake a cake for the family.
You like it really sweet, so you want to add extra sugar.
Your brother says it will be too sweet.
You tone it down a bit.
The whole family loves the cake.

I would explain the metaphor but I guess you'll understand.
A developer builds something in a certain way because he believes that's the right way. A tester double-checks if he agrees and if it works the way he would expect.

Would you walk into a hole if you knew there is a hole in front of you? :) Thats what developers do when testing, they leave out the scenarios they know are bound to break the app. After a long day's work they want to feel good not disappointed.

I think I'm pretty good at writing tests, with or without tdd. Corner an standard cases and regressions. The same reason why I love debugging complicated bugs I guess.

What I'm definitely bad at is e2e testing because it's always an afterthought and I don't have as much experience with it 😭

Fact:
Testing is hard
Time is limited
Breaking your code is as hard as writing your code
No one likes to do things twice

Opinion:
Its impossible to figure out how my code will break, where and under what circumstances
I can test as much as is possible using good tools and a little prior experience
Its good to scope out a good hiding place before your mistake brings down the app (that is totally a joke)

They are not.

mic drop

:p