When I started as a QA engineer, what I mostly heard was: “QA is the easiest way into IT” and “QA is simpler than development.”
The most disappointing this is that I internalized that. And even now, years later, I still catch that bias in myself.
So this post is partly for me, thinking out loud. And partly for other QAs, maybe to give language to something they already do.
One thing that changed how I see QA was learning about critical thinking and the scientific method.
As a habit: don’t jump to conclusions before you have data.
In everyday life, we often do the opposite. We decide first, then look for facts that support the decision.
In QA, this habit could break things.
A lot of my mistakes didn’t come from lack of technical skill. They came from unnoticed assumptions.
Meet my least favorite debugging partner: confirmation bias 👏
By definition, it’s the tendency to search for, interpret, and remember information in a way that confirms what we already believe.
In QA, it often looks like this: You see an error in the UI → you immediately filter logs for the known error → you ignore other warnings because “they’re probably unrelated”
Or
A feature breaks in production → you assume it’s caused by the last backend change → you don’t verify environment differences, caching, or timing
Once the assumption forms, evidence stops being neutral. Logs become supporting material. Repro steps are written to confirm beliefs instead of testing it.
And that’s how we end up with:
- Wrong root causes
- Misleading bug reports
- Developers debugging ghosts