When We Build, We Get Biased
Clear eyes beat crossed fingers. How creator attachment blinds us and how teams can catch it early.
There’s a belief that shows up in almost every team:
The person who built it is the best person to test it.
It sounds practical. Efficient. Even responsible.
Who else understands the system better? Who else knows the edge cases, the constraints, the intent?
But it carries a quiet assumption.
That understanding leads to objectivity.
It doesn’t.
The hidden mechanism
When you build something, you don’t just write code.
You build a story.
You decide how it should behave. You resolve tradeoffs just enough to move forward. Over time, that story stabilizes. It starts to feel like reality.
And then it becomes your lens.
From that point on, you don’t see the system directly. You see your version of it.
The shift is subtle.
You stop asking, “What could go wrong?”
You start thinking, “This should work.”
That’s the moment bias enters.
Because now, if something breaks, it’s not just the system that’s wrong.
It’s you.
A real scenario
A team had just finished a new checkout flow.
The developer who built it walked me through the feature. Clean structure. Edge cases handled. Logging in place.
He ran through a few scenarios.
Everything passed.
He leaned back. “Looks solid.”
Then, almost under his breath: “Unless I’m missing something.”
He was.
Later that day, during exploratory testing, we found a pricing issue.
Switch currency mid-session. Apply a discount code. The total became inconsistent.
A real user could hit it in minutes.
No crash. No error. Just the wrong price.
That’s the kind of bug that quietly costs money and trust.
He didn’t miss it because he lacked skill.
He missed it because he followed the path he designed.
We didn’t.
The frame shift
Here’s the shift that matters:
Expertise narrows your search space. Testing needs you to widen it again.
Clarity helps you build.
It can blind you when you evaluate.
Testing needs someone willing to say, “I don’t trust this yet,” even when everything looks clean.
Not out of cynicism.
Out of respect for how systems behave outside our intent.
What this looks like in practice
Watch someone test their own work.
They follow intended flows, use expected data, and confirm outcomes that match design. When it passes, there’s a quiet relief.
That relief is the tell. The goal wasn’t just learning. It was confirmation.
On one team, we made this visible.
Developers tested their own features first.
Then someone else explored the same feature with no prior context.
We compared findings.
Developers caught setup issues and obvious failures quickly.
Testers found inconsistencies, confusing flows, and state problems that didn’t break the system but broke understanding.
The overlap was small.
Different lenses. Different risks uncovered.
The core assumption
The assumption underneath all of this is simple:
If I understand the system deeply, I can test it thoroughly.
Understanding helps you explain.
Testing requires you to question.
And questioning your own work is harder than it sounds.
Because now your judgment is involved.
If something fails, it means you missed something.
If behavior is unclear, it means your design wasn’t as clear as you thought.
Most people don’t explore well under those conditions.
So the brain protects you.
“It’s probably fine.”
“Users won’t do that.”
“I already tested this.”
Those aren’t technical conclusions.
They’re self-defense.
The tension we avoid
Now hold two things at once:
The builder understands the system better than anyone.
The builder is also the easiest person to mislead.
So who do you trust?
The one who knows the most?
Or the one who doubts the most?
You don’t resolve this by choosing.
You resolve it by designing for both.
Let builders test. Their insight matters.
But don’t let that be the final word.
Bring in someone who doesn’t share the same story.
Someone who is still allowed to be confused.
That confusion is not a weakness.
It’s signal.
At a team level, this compounds. Shared ownership can quietly turn into shared blind spots when everyone buys into the same story.
Practical application
You don’t need a new process.
You need clearer intent.
1. Separate confirmation from testing
Let builders verify their work. Call it confirmation.
Then create a second step focused on exploration by someone else.
Different goal. Different mindset.
2. Bring in fresh eyes earlier
Don’t wait until something is “done.”
Invite another perspective while the feature is still forming.
Misunderstandings at this stage are valuable. They expose assumptions before they harden.
3. Listen to the language
Bias leaks through words:
“This should work.”
“It’s probably fine.”
“Users won’t do that.”
Pause when you hear them.
Ask: What did we actually observe?
Closing
Testing is not about proving that what we built works.
It’s about discovering how it behaves.
And discovery requires distance.
Not from the team.
From the story we told ourselves while building.
Because the moment we start hoping our work will pass, we stop seeing clearly.
Clear eyes beat crossed fingers.
And quality begins when we’re willing to see our own work without defending it.
Further Reading
If you found this useful, you might also enjoy these articles:
If you found this helpful, stay connected with Life of QA for more real-world testing experiences, tips, and lessons from the journey!