Cognitive biases in software development. Part 2. Cognitive biases QAs fall for
2nd part, other posts — first part, third part, fourth part.
Fundamental Attribution Error: Probably dev’s not an idiot?
Developers fall victim to this error many times, and probably will again. They know they produce bugs, even though they try hard not to, but it’s always the damn test engineers who pester them with bugs.
Conversely, can’t developers run some simple tests before throwing their code over the wall to QA? It’s as if they just checked their code compiles, but never ran it, before committing it to the version control system.
At the end of the day, everyone involved has to realize that this is a co-operative exercise, and not a power struggle.
What can you do against this effect?
- Actively find ways to reduce the odds of future failures (f.e. use automated testing)
- QAs and developers must work collaboratively to take ownership of their work as well as their faults. This will help reduce the negativity and provide a path for quality improvement.
Confirmation Bias: Keep noticing your blind spots!
Whilst very common, confirmation bias is very easy to combat in software testing. All it needs is a reminder that only one test case with valid and/or simple data for a piece of functionality is required, and any additional test cases with valid and/or simple data are a waste of time. Instead, spend time on edge cases, invalid data, and complex data (such as unicode strings, fractions for numbers, SQL injection, etc.)
Basically, QA will validate that the functionality works in the ways that they expect, but won’t test to see if there are any variations in behavior. This obviously leads to missed negative test cases and can result in some major problems, especially when the program is released to users.
Negativity Bias: If smth BAD happens?
Negativity bias is the psychological phenomenon by which humans pay more attention to and give more weight to negative rather than positive experiences or other kinds of information.
Have you ever worked with someone who always seems to be shooting down ideas, yet commands a lot of respect and seems extremely knowledgeable? In software engineering, this often occurs when product managers or designers describe some feature that is fairly difficult to implement. Engineers will frequently push back on this, explaining why the goals are impossible to achieve. Because of the negativity bias we all have, these people can come across as intelligent, mature, and even seem to be saving the company time and money.
Negativity bias is a particularly relevant error for QA to make. As test engineers are primarily involved in discovering negativity (bugs), it is very easy for them to assume a piece of software is unshippably broken because of all the stuff they discovered.
What can you do against this effect?
- That’s why it’s the product manager’s responsibility to define acceptance criteria together with the test lead :)
- It is often the right decision to say no to things, but if you find someone who is doing this on a regular basis, take a step back and ask yourself if their arguments have merit or if you are simply falling prey to this cognitive trap.
Inattentional blindness: Do you always see the Moonwalking bear?
Before reading — watch this video, please.
It’s very easy to miss the most obvious things when you aren’t looking for them. This describes the essence of inattentional blindness. In an interview with StickyMinds, QA consultant Gerie Owen gave the example of an experiment where participants were instructed to watch a basketball clip and count the number of passes. The viewers were so intent on this mission that half of them missed when a person in a gorilla suit did a dance on the court during the middle of the game.
This type of blindness carries over into testing because QA professionals may be so focused on looking at one thing, that they miss other very significant things that are happening.
What can you do against this effect?
- It’s important to keep an open mind and to collaborate effectively with teams to bring up issues that may not have been noticed previously, providing total requirements coverage.
