“A heuristic is a fallible method of solving a problem or making a decision”

– Cem Kaner, James Bach

Heuristics are wonderfull things. They are tools, principles, ideas, practices,… to tackle a problem. When you encounter X problem Y heuristic can be used to try and solve it.

Y heuristic can fail in solving X, then maybe heuristic Z can get it done.

A few examples:

• A hammer can be used to drive in a nail in a piece of wood. However, when you have to drive a nail into a concrete wall a different approach is advised. A drill can usually make things easier for you, but sometimes the hammer can get the job done anyway.

• When solving a jigsaw puzzle, starting on the edges is a heuristic. Looking for same-coloured pieces is another

• Looking for a certain file on a server can be done in quite a few ways:
  • Using the search option
  • Asking someone who might know its whereabouts
  • Manually going through the whole Active Directory
  • …

Many testers handle a great many heuristics. They do this intrinsically. Even though they are using these heuristics, they find it very hard to explain them to the non-testing professional.

It hurts the general perception of our profession when we are asked to explain the intelligent choices we make, but can’t. “Well, I just started to randomly click around the application and suddenly the system froze and errors were flying all over”… is better explained as: “I used a click frenzy heuristic (or any other name you wish to give it) in order to find out how the application would react to a click load generated by one user. In my experience I have found that applications tend to have a chance at behaving strangely when doing this.”.

What may seem as an unstructured, randomized process to non-testers, usually makes perfect sense to us. If we could only explain this decently…

A heuristic in use:

The tea test heuristic. I used this to find the first blocking issue in my professional career.

I was testing a mobile device ambulant nurses were using to register their patient visits.

The client was complaining that the device was going into a freeze on a regular basis. This bug wasn’t found during development of the device. However simple it was found.

 What do nurses do when visiting a patient? They bring their device, log in, maybe register that they started the visit and then look at their patient.

 What does the system do? It gets turned on, maybe a few things are registered and is then tossed aside for 15-30 minutes.

 It should go to sleep, or at least stay in the state it was left at. It didn’t. An error message sprung up for 30 seconds, which was unnoticed by the nurses, and then disappeared. The system froze.

I found this bug by logging in and further doing nothing. Went to grab a coffee. (yes, coffee is also viable as beverage when applying a tea test) Returned and found the device in freeze.

Clearly, the system was failing to stay in idle state. My next test timed the whole thing, caught the error message and showed where the problem was.

Heuristics help us to explain our craft in an intelligent way. They are usually explained by metaphors, examples, demo’s or stories from our days at work. Using heuristics to explain the way we think and work shows that we have thought about it. They help us build up our model of testing and how we see the world.