Have you read Quiet by Susan Cain yet? In it Cain refers to studies that show just how much peer pressure influences our decisions — a concept that has some interesting ramifications for us as software testers.
We’re all exposed to peer pressure. Even as testers we are subjected to peer pressure.
Peers in development roles question the defects that we uncover. Our project management peers question our test plans.
In an attempt to overcome issues with peer pressure, an advertising man named Alex Osborn invented brainstorming. He believed that creativity was stifled by the fear of judgment from colleagues. So he sought to remove the threat of criticism from teamwork.
Brainstorming has just 4 rules:
1. Don’t judge or criticize ideas
2. Put forward unusual ideas
3. Aim for quantity of ideas
4. Build on each other’s ideas
Osborne believed that brainstorming as a practice would produce more and better ideas. He also believed that brainstorming as a group would deliver better results than working alone.
Yet, according to several studies, there’s an argument to suggest that brainstorming doesn’t work. Why?
In 1963, Professor Adrian Furnhams at the University of Minnesota conducted a study on brainstorming — the results showed that more ideas are produced when people work on their own. It also showed that the ideas produced alone are of equal or higher quality. Adrian Furnham’s research led to the following conclusion: “evidence from science suggests that business people must be insane to use brainstorming groups.”
Further studies have produced similar results.
So what, you say? How often does anyone use brainstorming is software testing?
In my experience, not often.
It’s where this leads that’s important, though.
It turns out that even in a brainstorming environment, the fear of looking silly in front of our peers is still strong. So strong that it’s been given its own term — “evaluation apprehension.” There’s not a lot we can do about it, unfortunately. Neuroscience research suggests that the fear of judgment runs deep, so deep it may have a significant impact even for those of us in roles as software testers.
As humans we’re prone to conform. Gregory Berns, a neuroscientist, wanted to know if people conformed even though they knew their peers were wrong. Or (and this is where it gets interesting), if their perception had been altered.
In 2005, Berns came up with a complex way of measuring brain activity to work out the answer (more of which you can read about in the book Iconoclast — see below). The long and short was that peers somehow managed to change individuals’ perceptions!
This implies that peer pressure can actually change your view of a problem. Worse still, you are completely blind to how much your peers have influenced you. You have NO control over this.
Which leaves an interesting question to consider. Just how much influence do our peers (developers, project managers, etc.) really have over us?
For example, we find a defect in an application. We’re not sure if it really is a defect. It works, but it just doesn’t quite conform to what we think the end user would expect. Developers think it’s okay. Do we say nothing?
Just how much are our independent roles as assessors of quality influenced by our peers? How often have you let a bug go because a developer or project manager applied peer pressure? (Peer pressure that you didn’t even realise was being applied?)
If nothing else, it suggests that there’s a whole world of psychology and neuroscience that we can learn and grow from as we strive to be our best as software testers.
References:
Quiet: The Power of Introverts in a World That Can’t Stop Talking by Susan Cain
Iconoclast: A Neuroscientist Reveals How to Think Differently by Gregory Berns, Ph.D.
