As it often happens, one idea leads to another...

I was reading about prioritization and decision-making heuristics on Lee Merkhofer Consulting web-site, and this article triggered my interest to find more detailed source about Bounded Awareness. So I found article by Dolly Chugh and Max Bazerman in Rotman magazine (here is the link to PDF, see at page 23).

Here's how it begins.

"Economists and psychologists rely on widely-divergent assumptions about human behaviour in constructing their theories. Economists tend to assume that people are fully rational, while psychologists – particularly behavioural decision researchers – identify the systematic ways in which people depart from rationality. [...] In this article, we propose that awareness can also be bounded, and that this occurs when people fail to see, seek, use or share highly relevant, easily-accessible and readily perceivable information during the decision making process."

Perfectly applies in software development and testing, don't you think?

The authors cover with examples 3 common types of Bounded Awareness.

Inattentional Blindness

"..Information sits visible and available in the visual field, yet escapes awareness when competing with a task requiring
other attentional resources.
This phenomenon, known as ‘inattentional blindness,’ has become an important area of study for cognitive and perceptual psychologists. Its consequences extend to real, life-and-death activities. For example, an airplane pilot who is attending to his controls could overlook the presence of another plane on his runway. Similarly, cell phones can divert drivers’ attention, making inattentional blindness a likely contributor to car accidents." 

Change Blindness

"Change-detection researcher Daniel Simons of Carnegie-Mellon University has demonstrated that people fail to notice changes in the information that is visually available to them. Interestingly, they often cannot describe the change that has taken place, but do demonstrate traces of memory of what they saw before the change.

[...]

The possible influence of change blindness in decision making is evident in a study by Petter Johansson and his colleagues, in which participants were asked to choose the more attractive of two faces displayed on a computer screen. As participants moved thecursor to indicate their choice, a flash on the screen distracted them, and the two pictures were reversed. Nonetheless, most subjects continued to move their cursor in the same direction, selecting the picture they originally viewed as the more attractive.
Importantly, they failed to notice the switch and provided reasons to support their unintended decision."

Focalism and the Focusing Illusion

"'Focalism’ is the common tendency to focus too much on a particular event (the ‘focal event’) and too little on other events that are likely to occur concurrently. Timothy Wilson and Daniel Gilbert of the University of Virginia found that individuals overestimate the degree to which their future thoughts will be occupied by the focal event, as well as the duration of their emotional response to the event.

[..]

Using similar logic, David Schkade of UC San Diego and Nobel Laureate Daniel Kahneman of Princeton defined the
‘focusing illusion’ as the human tendency to make judgments based on attention to only a subset of available information, to overweight that information, and to underweight unattended information.

[..]

The implications of focalism are not limited to laboratory studies. The Challenger space shuttle tragedy, for example, can be better understood through this lens. On January 28, 1986, the Challenger was launched at the lowest temperature in its history, leading to a failure of the ‘O-rings’ and an explosion that killed all seven astronauts aboard. Before the launch, the decision makers at NASA examined seven prior launches in which some sort of O-ring failure occurred. No clear pattern between O-rings and temperature emerged from this data, and the launch continued as
scheduled. Critically, the decision makers failed to consider 17 previous launches in which no O-ring failure occurred. A logistic regression of all 24 launches would have led to an unambiguous conclusion: the Challenger had more than a 99 per cent chance of malfunction."

 

The examples in the article are taken from economics, management, and psychological tests.

I prompt you to share examples from your job in software testing. You can provide them here, in comments, or link to your blog post.

Chain reaction causality is where A causes B, C, and D, which then cause E, F, G, H, I, J, and K. It's a case where you have an event that has one or more effects, which in turn could have zero, one, or more effects, which (again) in turn could have zero, one, or more effects. That can go on indefinitely. If you've ever tested a rules engine, than you're familiar with testing systems like this. One simple event can trigger a cascade of triggering events.

When testing chain reaction relationships, you often need to use various tools such as decision trees or decision tables, state diagrams or sequence diagrams, or spreadsheets (or other tools) that layout various rules and what triggers them. When testing systems like this, often you start with simple scenarios (like our linear tests, if A then B) and build those out over time - making them more and more complex. You'll see this lead to test beds of XML or big spreadsheets of pre and post conditions for testing.

Recognizing when you have a chain reaction is a critical first step. It allows you to first try to decompose the problem into smaller parts. It's also often the case when testing this type of causality that you need to think about testability features. So much is happening that you feel like you need more visibility (logging, visualization, etc...) to help you understand what's happening while you're testing.

For more on this topic, see the section on scientific thinking and precision in the Miniature Guide on Scientific Thinking.

Negative feedback causality is where A causes B, and B has a counter effect on A. Over time, the two will develop an equilibrium. A testing example of this might be an application server's load distribution mechanism. The more requests a specific server in the cluster gets (event A) the higher it's load profile. The higher your load profile, the less attractive you are to the load distribution algorithm (event B). That means you'll get fewer requests from the load distribution algorithm. Over time, a theoretical balance in load is reached. In practice, the system continues to change, constantly taking into account both A and B as it works to obtain equilibrium.

If I suspect A and B have a negative feedback relationship, than my test cases look very much like they do when I suspect a circular relationship. I'll come up with test cases where I control the starting states of both A and B, I'll need to verify both A and B, and all the problems with measurement still come into play. Again, test setup and observation has to take these problems into account.

For more on this topic, see the section on scientific thinking and precision in the Miniature Guide on Scientific Thinking.

Circular causality is where A causes B, and B causes more A, which causes more B, etc... It's a classic example of a positive feedback loop. Once put in motion, it continues where A and B grow over time. A testing example of this might be load testing a news website with a widget for "most popular stories." If you look at a news story X number of times, it becomes popular. If a story is in the "most popular stories" widget, people are more likely to look at it. This makes it more popular. Etc...

If I suspect A and B have a circular relationship, than I'll come up with test cases for:

• where A is some known input, and B is at some known starting state, verify B is some expected result and verify A is affected according to some expected result


• where A is close to some possible limit, and B is at some known starting state, verify B is some expected result and verify A is affected according to some expected result


• where A is some known input, and B is at some known starting state close to some possible limit, verify B is some expected result and verify A is affected according to some expected result


• where A might be a stressful input, and B is at some known starting state, verify B is some expected result and verify A is affected according to some expected result


• where A is some known input, and B is at some known stressful starting state, verify B is some expected result and verify A is affected according to some expected result


• where A is ... etc...

If you contrast this with linear causality, you can see that we now have to control for both inputs A and B, as well as look at the affects on A and B. There's also a potential measurement problem with circular causality. If the feedback loop is fast, you might get multiple interactions before you have time to measure the effects. So test setup and observation has to take this into account.

For more on this topic, see the section on scientific thinking and precision in the Miniature Guide on Scientific Thinking.

Linear causality is where A causes B, but B has no affect on A. Establishing causality in systems can be more difficult than it might look. For example, I can assume that if I click Search on Google's search page, that the results that are then shown to me are caused by me clicking search. Clicking on the search button is event "A." It causes the results to appear, event "B."  It this case, I believe that B does not affect A. But I don't really know that. What if the results shown to me are dependent on how many times I've clicked the Search button? For example, what if Google decides to charge for searches and it starts to limit it's free search results based on how often you search?

This is important because when we assume we have linear causality, it affects our testing. If I suspect A causes B, than I'll come up with test cases for:

• where A is some known input, verify B is some expected result


• where A is close to some possible limit, verify B is some expected result


• where A might be a stressful input, verify B is some expected result


• where A is ... etc...

In a linear causality relationship, we often only vary the A input. And if it really is a linear relationship, that's appropriate. Our expectations for B are dependent on our A input. You wouldn't spend time controlling for B's impact on A in a linear relationship. In many ways we have to be able to assume linear causality for many items. We have a lot to test, and understanding relationships like this allows us to move efficiently from test to test. You can't take the time to question causality for each any every relationship. It wouldn't be practical.

However, if you don't know for sure that something's a linear relationship (and many things aren't, in future posts we'll look at circular, negative feedback, and chain reaction causality) than it might be worth some time investigating. It's been my experience that a lot of really critical bugs get missed because of this assumption. You can address it a number of ways. You can talk to people on the project team, making your assumptions around causality explicit and seeing if anyone refutes you. Or you can do some sampling and run some tests to show that something in fact linear (that option is more expensive, so use it sparingly).

For more on this topic, see the section on scientific thinking and precision in the Miniature Guide on Scientific Thinking.