Article summary
A few years ago I got a Mini, and, once I had it, I noticed many more on the roads. That includes several hundred when I went on a Mini on the Mack world record attempt. Recently a co-worker sent me a pic of her new car — a Mini of course. I never knew there were so many Minis in Michigan! The number of Minis in Michigan hasn’t actually increased or decreased, but I now have a confirmation bias, in that I notice Minis rather than Buick SUVs or Alfa Romeos.
My confirmation bias carries over into my job. I’m a tester, which means I try to find and notice bugs, and this carries on outside of work hours as I notice bugs in apps I’m trying to use. And, there are a lot of them out there, which confirms my bias that all software is full of bugs.
Designers will have their own confirmation bias and notice bad choices of font or color combinations. Editors will pick up on poor grammar.
Everyone has cognitive biases.
There are many cognitive biases. These can’t be avoided, but they can be managed if you are aware of them. An awareness of these biases means you can use the advantages of them in your favor and lessen their negative effects.
One advantage of a confirmation bias is that my co-workers know I like hearing about defects. So, as well as sending me pictures of Minis, they send me bugs they come across. I get to find out about different bugs and can work out if there’s a new technique or approach that I should use in the testing that I do.
This also works for the person sending the bug to me. Would this have been a problem on their project? Could such a problem happen with their project, and if so, how would this have been caught? And when and where in the process would it be caught?
Double-check to counter your biases.
One problem is feeding my negativity bias (I told you there were a lot of biases!). That means I tend to see the negative in things rather than the positive. In turn, this can lead to issues where all my conversations with developers are about problems and issues rather than how well things are working.
The disadvantage of confirmation bias? I might be working with DevA who I’ve worked with before and know they usually produce solid code. I get their latest project, run some quick tests, and find no issues. My bias is confirmed, and I might not dig too deep.
I then work with DevB, someone I’ve not worked with before. They don’t seem as confident as DevA, and so I dig in deeper and pay more attention to their work. If I do find an issue, no matter how trivial, then my bias has been confirmed, and I feel a need to test their work more than I do the other developer.
To counter this bias, you could check to see what testing you were planning to do, or did, for each developer. If there was an imbalance, work out whether it was appropriate. Was one work working on a more crucial area of the app? Was the code more complex? Were they familiar with the type of app, or was this a new area for them? These questions check to see if any bias was coming into play.
Are you aware of your biases and how they might affect your actions and thoughts? If so, how do you deal with them? Let me know in the comments.
Your story about biases against dev B is interesting. On its face it makes a lot of sense—but what if you knew dev A was not just generally someone who produced solid code, but took a specific kind of care around a certain class of bug—say, input validation? Does it still make sense to take the extra effort if you have a good reason to believe they’re already doing a great job in one key area?