Cute Heuristics

When I was told about exploratory testing by Matt and Dan, they spoke a fair bit about heuristics. Somewhere along the line I got the impression that these were ephemeral things one had to learn to become a good tester. Without them we were lost.

Listening to James Bach speaking about them it became clear that the term meant something slightly different.

I'm going to try and distill my idea of what they mean to a tester at the present time and hope that any errors I make will be highlighted by someone or other!

So, looking at the info I've garnered thusfar, a few common themes are obvious.

Heuristic as a problem solving tool:
To my understanding, a heuristic is a replicable method (?) or approach that is used to direct one's attention when in learning or discovering. (From wikipedia) Another term you hear a fair bit is the "rule of thumb".

The concept is that you use a heuristic to give yourself an idea of where your testing is going to take you. This could be something like "Software has failed before when I pressed the enter key repeatedly" so I try that in this case. It's neither hard nor fast but it's useful in the absence of any other directive.

Heuristics as fallible:
A point that was emphasised by James was that these tools were loose and suggestive rather than directive. They suggest a plausible path to take while testing and give some indication of a possible outcome (I'll revisit this later and work through my reasoning and see if this statement is correct).

The brilliant thing is that the heuristic is a dynamic thing so using one that ultimately fails to give you an expected result is not a disaster. While it hasn't given you any information about the product under test, it can give you some useful feedback into your preconceptions and expectations.

One point worth noting: I asked a question about why I used 32, 63,64,65 and 65535 as inputs when testing number input boxes. James made some good points about it and also pointed out that many higher level languages wouldn't fall into these traps because the compilers and interpreters would handle them. It was only when I spoke to Josh after the lesson that I realised that my bias towards these numbers was based on the numbers of ECs on an SNT and the numbers of SNTs to RPs in Ericsson AXE10s. The thought that I was using a 7 year old heuristic that had never been subject to any questioning or modification gave me pause for though.

Heuristics as a library of experiences:
It strikes me that something that I've been bad at in the past is consciously analysing my observations to see if I can take something more from it and apply it in a future situation. I may have been makins some inferences based on half formed heuristics but I never thought "Hey, I should think about this the next time I start testing"

That's me for the moment, I'll revisit these blogs frequently to see if I still believe the stuff I've typed. Feel free to disagree with my thoughts and gimme some feedback. Later