Thinking fast and slow in Software Testing

Some time ago I read the book "Thinking Fast and Slow" by professor and Nobel prize winner, Daniel Kahneman, which is about the biases in our intuition, that we assume certain things automatically, in an instant, without having thought through them carefully. In many situations it is perfectly fine to act instinctively, but in others we should activate rest of the mind. In this blog post I will try to relate some of the topics that he touches upon in his book, to our field of software testing and development.

My initial idea was that I would fit most of the topics into this blog post, but upon revisiting the book, I feel that there are way too many topics of interest covered in his book, and by going into all of them, this blog post would most likely result in another book, rather than a blog post. So I will only cover some of the topics.

If you have not read his book, find it and set aside some time to read it. Read it fast and slow, it is truly an amazing book with a lot of insights. 

The two systems

In the start of the book, Kahneman describes our thinking into two systems. The first, System 1, thinks fast, automatic, emotional and intuitively, while System 2 is slower, requires more effort, is analytical, and logical. Some examples of System 1 are solving easy arithmetical problems like 2+2, localizing the source of a specific sound, or dodging a rock if thrown at you. System 2 kicks in if there are more complex problems to solve, where System 1 can not find the answer to quickly enough, like solving complex arithmetical problems (89*73)-(21*32)+(99*87), focus your attention or look for someone specific in a large crowd, or hear a familiar sound which you do not recognize at first. There are countless examples of these two systems, and they both have their pros and cons. In short, System 1 is instinctive, good in most low risk situations, immediate situations, and is based upon our heuristics, but is too simplistic in more difficult situations. System 2 is activated in more complex situations, or situations which we have not faced before, which requires some effort, that is why it is not activated constantly. In most daily situations we use System 1, and if System 1 provides a plausible solution to our problem, we in most cases automatically accept that as a sufficient answer, as "laziness is built deep in our nature". 

Although there are techniques on how to counter some of these biases, which are mentioned in the book, I think the best first step would be to be aware of them, and that you recognize them. We all use them unconsciously (or consciously) daily. “The way to block errors that originate in System 1 is simple in principle: recognize the signs that you are in a cognitive minefield, slow down, and ask for reinforcement from System 2,”

Here are some of them:

Anchoring

The anchoring effect is about our minds being influenced and assess irrelevant numbers or information not related to the problem we are trying to solve. One example is asking the question whether Gandhi was more than 114 years old when he died? Most people, given the anchor of 114 years have been set, will answer a higher number than if the question was asking if Gandhi was 35 years old when he died. This is because it is shown that our behaviour is influenced much more than we know or want by the environment of that moment. 

If we relate this to our daily work in software development, it is easy to draw parallels to user story or task estimation, where someone in the meeting for example states, "So do you think that this task will take more than 6 hours?", or 2-3 days, etc. It is easy to become influenced by anchoring effect if one is not aware of it, and try to "fight" it. 

Availability heuristics

The availability effect is about that we are prone to give bigger answers, or overestimated numbers, to questions that are easier for us to retrieve, specially if we can relate to them through a personal experience. For example if asked about the number of dangerous plants, or the risk of being mugged on the street, the ease in which we retrieve the answer influence the size of the answer. For someone who has experienced being mugged, they will usually overestimate and give a higher answer than someone who has not experienced that. If something is not closely related to you, you probably ignore the risk and under estimate. When a story or topic is repeated on the news over a longer period of time, it distorts our statistical "senses", so if stories about flight crashes appear constantly, you would probably rate the probability of a plane crashing much higher than it actually is, since this information is fresh and easily retreived in the memory. "If something is recalled, it must be important".

In software development we experience this daily, if a team has had releases where major issues have not been caught, the team is more cautious before next release, usually spending more time to test and verify areas where the latter issue was found. If the same team released and everything worked as expected, they will probably do the same as always, not bother with extra work, checks and follow the same process for the upcoming release.

Another example would be, in these days if you were to decide on an architectural style of your application, you would probably go for micro-service architecture, since this is what everyone is talking about. It is hip, popular, and seems to be going places, there fore it must be the right style to use if you are to build a modern application. Again, it is repeated so much that you are influenced by this.

Confirmation bias

Confirmation bias is the tenancy to interpret, focus on, remember, search for and find confirming evidence to support your own belief while overlooking counter examples. 

There are several examples that can be drawn parallels to in software development when it comes to confirmation bias, everything from discussing latest buzzwords, deciding level of automation, tools to use, and test strategy and approach. If you for example want to push for going towards microservices, it is easier to find information that support your believes than to try to find examples of why it is not a good idea to use this. You will probably be satisfied to find the information that support going towards microservices.

Sunk-cost fallacy

This is a phenomenon where people continue to justify increasing investment in a previously made decision which, despite new evidence, turned out to be a bad decision. 

This one is also something that I think we often see in our field, like choosing to use a tool, a framework, go for a certain architecture when designing the service we are building,  or automating tests on a certain level and later in the process when/if it turns out that the decision was not so good, we will most likely stick to our choice, invest more money and time to make the decision work, instead of re-evaluating and scrapping the original decision. In the tool example, you can use a lot of time to learn the tool, invest money in licenses, training, etc. and then since we already invested this much in the tool, we need to continue to use it even though it does not provide us a good return on the investment. Instead the better thing would be to scrap the tool and for example evaluate other tools. Same goes for the frameworks and architectures we have chosen, in stead of re-evaluating and re-designing, we tend to stick to the original decision. For the test automation example, how often do you remove tests that has been automated? My guess is; almost never, even though they should be removed once they do not provide any value to the team. If they are failing too often, are too brittle, redundant due to evolvement of other tests, etc. 

The hindsight illusion

This one is also called "I knew it all along" effect. Tenancy to look back at certain past events as being more predictive than they actually were. Most example that many can relate to is the financial crash in 2008, where some had a hunch or guesstimated that something will happen, and once it did happen, they turn their hunch/guess into a "fact", where they actually did not know and did not have any evidence of predicting this. The same thing would be for me to state in 2016 that Norway will not qualify for the World Cup in 2018, and when they did not qualify to claim that, "I knew it all along", since it happened. 

Turning to our daily work, I my self have experienced this several times, for example in the past when we released very seldom to production, 3-4 times a year, on one certain release, we had a meeting in order to make the decision on whether we should release the current version or not, I wanted to give it an extra day or two of testing, but we decided to release it anyway. I had a hunch or a gut feeling that we missed something, but I did not have any hard evidence on what it might be. All of our automated tests/checks had passed, we did additional verification with certain datasets as we always do, and everything worked. Still I remember the hunch or gut feeling that something was not right. Looking back to it now, it could be that we never would have found that issue even if we had 10 days extra of testing, anyway the version was released and it turned out to contain an issue which affected quite many customers, so we were forced to make a emergency fix. At that time, after the release when we discovered the bug I had the hindsight illusion or "I knew it all along" feeling. 

As mentioned in the beginning, there are a lot of very interesting topics that are covered in this book, and that could be tied to our everyday software development and testing. To end this post, I will list some of them here, if interested in any, look them up! I will definitely try to learn more about these and see how they apply in our daily work.

• Halo effect
• Conjunction fallacy 
• Substitution
• Optimism and loss aversion
• Availability cascades
• Framing
• Cognitive ease
• Coherent stories
• Judgement
• Law of small numbers
• Representativness
• Cause over statistics
• Narrative fallacy
• Illusion of validity
• Intuitions vs algorithms/formula
• Planning fallacy
• Loss aversion
• Endowment effect
• Two selves
• Peak rule end

Disclaimer: Please note that the examples from Kahneman's book are based on scientific experiments and facts from a number of studies, my examples are based on my experience and thus could be biased due to the limitation of my experiences, and they are not part of any study. Also be aware of any cognitive biases in the article...

Resources

• https://www.amazon.co.uk/Thinking-Fast-Slow-Daniel-Kahneman/dp/0141033576 paper copy 
• https://en.wikipedia.org/wiki/List_of_cognitive_biases 
• https://www.perforce.com/blog/kahneman-and-thinking-about-testing