Sources Of Testing Power

I find the Rapid Testing movement interesting because it is completely opposite how I learned to test yet matches quite well with what I actually do. Testing was taught to me as a process where you:

1. Inspect the specification for your feature.


2. Draw up an exhaustive list of test cases for that feature.


3. Prioritize the test cases.


4. Execute each and every test case in priority order.

Usually my process looks something more like this:

1. Inspect the specification for my feature. Where sometimes the "spec" is actual running code.


2. Play around with the feature for awhile - in my head when I have a spec, with the actual feature when I am looking at existing functionality.


3. Get a sense for what parts of the feature my customers are most likely to use, and for which pieces are most likely to work incorrectly.


4. Start banging the first test area, usually with a general plan of attack and sometimes even with an explicit set of tests.


5. Find bugs or things that make me go "Huh?" or interesting bits of functionality I hadn't noticed before.


6. Test around and dig into those bugs and double-takers and interesting bits to learn more.


7. Look over at my clock because my calendar program went "ding" and realize that it's time to go home.

Sometimes I worry that I'm approaching things all wrong. After all, when I make a decision, aren't I supposed to gather loads of information about it, carefully distribute and balance that information, and then the right answer will just be blindingly obvious? I'm so not doing that! I'm making spur of the moment decisions and running with them. So am I being a bad tester?

Thanks to Sources of Power, by Gary Klein, I can now say that I am making Recognition-Primed decisions. Gary and his research team have interviewed whole bunches of fireground commanders, military commanders, nurses, and the like. You know, people who are constantly making important decisions, like ones that affect whether someone lives or dies. What he has found is that while the formal decision processes can be useful for newbies, these types of situations are far too chaotic and fast-changing for formal processes to be effective. What happens instead is that an expert's experience in a domain enables them to see a situation through prototype-colored glasses - they can see through the specifics of a particular situation into the prototypical situation behind it and thus quickly determine the most typical course of action. Rather than comparing multiple options they pick that first one, run a mental simulation to determine whether it will work in the current situation, and then either select that option if it works or move on to a different option if it doesn't. Thus these experts can quickly find a workable solution rather than be stuck in analysis paralysis. They don't try to find the best option, simply one that will work. Nothing guarantees that their simulation will work, and sometimes they will be wrong. When that happens, or the situation changes, they iterate and move on.

Sounds a lot like testing, no? If this sounds anything like the way you work, I think you will find Sources of Power fascinating. Or if this sounds anything like the way your testers work, this book will help you understand them a little better! <g/>

Posted by The Braidy Tester at 07:30 AM  Permalink