When I first started testing my own projects, I realized something funny.
I wasn’t really testing.
I was just proving that my code worked the way I expected it to work.
Which sounds fine… until you remember that users almost never behave the way you expect.
As developers, we naturally follow the “happy path.” We click the right buttons, fill forms correctly, and use the app exactly how it was designed. Everything works — but only because we’re subconsciously helping it work.
Real users don’t do that.
Thinking like a developer
When I test like a developer, I already know the logic behind everything.
I know which inputs are valid.
I know which buttons are safe.
I know what not to touch.
So of course nothing breaks.
But that’s not realistic. That’s like studying for an exam with the answer sheet open.
Testing this way might feel productive, but it hides a lot of problems.
Thinking like a user
Testing like a user feels completely different.
Now I try to forget how the system works internally and focus only on what I see.
I click things in weird orders.
I leave fields empty.
I type nonsense values.
I refresh at the worst possible moment.
Basically, I try to be a little chaotic.
And that’s when the interesting bugs appear.
Suddenly buttons stop responding, validations fail, or screens behave in ways I never predicted. Not because the code is “bad,” but because real life is messy.
The shift that changed everything
Once I started separating these two mindsets, my testing improved a lot.
Developer mode helps me understand the system.
User mode helps me challenge it.
Both are useful, but user thinking is usually what reveals the real issues.
Now, whenever I test something, I ask myself a simple question:
“If I had never seen this app before, what would I try first?”
The answers are usually where the bugs are hiding.