I stumbled across the term ‘trained intuition’ in a mailing list post a couple weeks back in a reference to Malcolm Gladwell’s book Blink. Having finished it, I’m more or less convinced that any tester who wants to know how and why they do things a certain way should have read it.
Blink is about how our unconscious brain picks up information and processes it long (in thinking terms) before our conscious brain can do either. Let’s do some example comparisons
- A curator at a museum has his staff ‘hide’ pieces they are considering buying in places where it will jump out at him unexpectedly so he will get a fresh, sudden view of it. This removes a lot of external influences on his opinion of the piece and lets him concentrate on what he is supposed to be concentrating on; the piece. I’ve come to realize that I find the best / greatest quantity of bugs in an application’s interface when I first encounter it rather than when I have been living with it for some time. I’ve also seen obvious bugs that I missed reported by external testers, usually within the first little bit of them having the product. So does this mean that we should test the interface first? Not necessarily, but if you don’t, what Blink tells us to do is write down any ‘gut’ feelings we have about it when doing our first testing. There is usually something triggering that response. Also, when preparing testing assignments, should leads assign interface testing to someone who was involved in the mock-up creation?
- Thin-slicing is when ‘our unconscious is able to find patterns and situations based on very narrow slices of experience’. This strikes me as being what we refer to as a ‘sanity test’; test little bits of different parts of the app and form an opinion. Sometimes the tests are automated, so feelings and guts are removed from the equation, but often they are done manually as well. And sometimes the build just doesn’t ‘feel right’.
- Thin-slicing and trained intuition also comes into a hybrid play in deciding when you have done enough testing, or at least I think it does for me in my Rapid Software Testing-ish approach I use. Based upon my experience and learning, I reach a point where I am ‘comfortable’ with a feature / release. I know I haven’t found everything, but it meets some internal criteria I have developed. This internal criteria and the ability to become comfortable is what I consider my trained intuition which is fueled by the thin slices I get from testing.
- Mr. Gladwell spends an entire section discussing the Millennium Challenge in which the ‘bad guys’ handily beat the US military might in a war games exercise. The drubbing came largely because the ‘rouge leader’ reacted to situations and gave his leaders the ability to make decisions as compared to the bureaucracy and over analysis of the US military. Swap ‘testing’ with ‘war’ in war games and I think we have a powerful metaphor on our hands; the use of rapid testing techniques and exploratory testing lets us use our trained intuition and react to information as we discover it our testing as compared to making exhaustive risk catalogs and hundreds of test cases that must be run to achieve our testing goals. You can only find a bug in the software by testing it*; sitting in a cube somewhere writing test cases which will likely be based upon old information by the time you get to actually testing is not only wasteful, but dangerous.
* I’m talking testing here, not requirements or design review
- In another section, he talks to some researchers that made a taxonomy of all the possible combination of muscle movements in the human face (up to 4 muscle groups being involved). The word taxonomy jumped out at me as I had seen Cem Kaner present recently where he discussed risk taxonomies that affect software. His presentation is not online yet (as far as I can tell), but here are two papers his students’ did on the subject: here and here.
- One thing that I found interesting, but haven’t mapped to software testing in any meaningful was the explanation of why time seems to slow down when you are under stress. I had read previously that it had been a documented effect of stress and have experienced it myself when involved in a car accident (drunk driver with no license due to previous DUI ran a stop sign hitting the baby’s door then fled the scene) but it was the first time I had seen the physiology around it explained.
Blink is one of those books which was constantly ‘ah ha!’ moments and aligning ideas I’ve had for some time now and in talking to others who have read it they experienced the same. Understanding why you do things is an important and necessary first step to improving how they are done. And improving things is what being a tester is all about.
You can buy it from Amazon here.
For another review / article on this book, see Michael Bolton’s article Blink . . . or You’ll Miss It
Hi Adam,
Nice post. Though I haven’t read the book but after reading your blog I might do it soon. In terms of relationship between time and stress, dont you think its exactly opposite at least in terms of software? For example, if you are approaching a tough deadline (stress), time seems to run much faster than normal course.. Probably it could be because of the reason of stress or what we are doing during that time.
Yes, time might appear to run out, but that might be because you are more concentrated on what you are doing (a la http://en.wikipedia.org/wiki/Flow_(psychology) ) and you are sick of the project and just want it over. The time slowdown due to stress is a near instant condition that you really don’t want to be in all the time (blood leaves the extremedies, involuntary bowel contractions, reduced sensory input)
Exactly!! On thinking more about this, I could think of something related to software as well.. for example some useless meeting or waiting for automated suite to finish execution (may be… you can not wait to see results produced by it).. there could be many more situations like this if we think more and find the right context to use this..