Avoid “Confirmation Bias” Getting In the Way of Finding Bugs

Read this – A Magician’s Best Trick: Revealing a Basic Human Bias – WSJ.

This is another reason why it is wise to use a separate person, team, or group to “do quality assurance”. Confirmation bias is built into a developer’s DNA. We use it to stay on task. It is a critical attribute that makes us really, really clever and productive.

Unfortunately we can’t just turn it off when our brains know it’s time to verify that the thing we are building will be viewed by others to be working as it should.

Developers could and should do test-based development, and there should always be thorough unit testing and post build automated regression testing built into all build workflows. This is a must (especially if you’re as “forgetful” in coding as I am).

But before you put your creation out for others to use, you need to give it to a different set of “others” who can find the things that were missed and tell you about it rather than ruin the believability of your deliverables. “Others” by definition cannot have confirmation bias.

Remember, your product is always going to be tested. All you need to worry about is WHO you want doing the testing!