The Value of Wisdom in Testing—and How to Earn It

If you’ve been in testing long enough, you probably have a story something like this.

I was called in to review and then support a project. A single integrated multidiscipline development team was doing development and testing—an agile ideal before it had a name. The project involved some unique hardware driven by software, and I believed the software was the greater risk for the project. I looked over their plans and then asked, “In what kind of test lab are you going to run these software tests on this unique hardware?” The project team looked at each other. The manager looked at the project team. They gave a sheepish look and then admitted that they had forgotten about test equipment and facilities.

How did I know to ask that? You might say it came from wisdom, which comes from experience. I had done this sort of thing before, while the team was much younger and likely only had software experience, not integrated software/hardware work.

I realized from this that wisdom is important in testing, but is it a skill? Is wisdom something we learn, or something we gain over the years? I am not sure, but I think in my time practicing testing, I have become a wiser tester. However, I find many testers—even people with many years and great skill in testing—who seem to lack aspects of wisdom and sometimes create problems associated with group thinking.

Cass Sunstein and Reid Hastie recently published a book on the topic, Wiser: Getting Beyond Groupthink to Make Groups Smarter. I found the concepts in this book related directly to my project experience in software, hardware, and especially testing.

The book considers the problems we all face in making group and team decisions. Group thinking can:

1. Amplify, rather than correct, errors in judgment made by the team. People can convince themselves that a bad idea is actually good—after all, everyone else seems to think so. 
2. Fall into the snowball or cascade effect, where members of the group follow what others in the group say or do without questioning their thinking. I call this the “me too” parade. 
3. Polarize into extreme positions from viewpoints that are more middle of the road, e.g., “Our group has the only right idea.” 
4. Encourage what the majority of people think and know to be true instead of focusing on a critical piece of different information that a minority may have.

I see many teams, even whole organizations, having some of these problems. It’s worse when it happens to testers, because our role is supposed to serve to protect against this problem.

In my story, the development group was nearing the completion of an early planning phase of the project, but they had forgotten an important requirement: the test lab. They suffered from problems 1, 2, and 4 of group thinking. They got lucky because a senior director brought me onto the project to do a review because she thought I had critical information on testing. I was able to see the error in judgment before it became a costly overrun.

This was a single team on one project where everyone needed to be wiser. However, in the whole field of testing, I think I see problems 2 and 3 happening frequently.

I have been to conferences where people call various ideas in testing “toxic,” “worthless,” “dangerous,” “misguided,” and other hyperboles. Groups on both sides of these accusations are active members of the testing community. I know all these testers are interested in advancing the profession of testing, yet they have very different approaches. A further escalation that I also see is that the groups tend to disavow each other. This leads to groupthink problems 2, 3, and maybe 4. There may be ideas and concepts that are being overlooked by each party. We are still a young profession, and many ideas need context before they are proven or disproven.

Wisdom

Wisdom gives us the ability to see the value as well as the issues of each group’s viewpoint. As Sunstein and Hastie’s book points out, there are dangers in being overly attached to a particular viewpoint and refusing to see any value in another person’s ideas. We sometimes exclude that which does not match our group view and overlook ideas that may be valid in particular contexts, perhaps because we have not seen or worked in every context.

Also, as the book points out, this happens in many industries and sciences, resulting in slowed progress. Many testers I know travel in and out of these differing viewpoints of testing to bring views of one group to another in effort to overcome polarization, create a positive cascade effect, and help people avoid or correct errors. They try to see value in each group’s viewpoint. This moves different testing groups along, supports many different contexts, and, I believe, is a wiser course of career building for testers.

I like to encourage all testers and other team members to work on becoming wiser. We should look for the truth that may be out there, even when it conflicts with a belief we may hold.

What should you and your test teams do to become wiser? I recommend that you take a step back to see if you believe that the above problems are occurring on your project or within your company. If you find these kinds of issues happening on your team, you might consider taking actions from the following table.

Working to be wiser allows people to see both sides of an issue and provides more well-rounded testers who build skills and help projects produce products that delight. I encourage everyone to expand their perspectives, ignore groupthink, and try to become wiser in their team roles.