This is an experiment. I’m trying to figure out my understanding of what the word ‘Heuristics’ means to me and whether it’s helpful to me and my craft: Testing.
Therefore, I’ll rehash an old story of how I found a bug and annotate the heuristics used in Bold and see what I can analyse from that afterwards.
Any guidance, ideas, intuitions, sources are very much appreciated.
Finding a Memory Leak
It was past noon. I’d been testing an application that wasn’t too complex for quite a long time. I knew it’s ins and outs and I felt myself getting bored.
I remember going through the customer files rather methodically one by one, click,… click,… click , without a clear aim. You could say I was randomly exploring.
Until something didn’t feel right. Call it surprise, intuition, something was wrong.
I noticed a pattern of loading times slowing down almost unnoticeable. I can’t put to words what triggered it for me. Was it an Observer-expectancy effect? Was it my negative mindset that sharpened my senses? I haven’t got a clue, but I felt I had to focus, zoom in.
I chose a tactic that was less boring than meticulously clicking my way up. Selenium IDE isn’t the best of tools, but it fit my purpose perfectly. I recorded my click and copied it a thousand times. I monitored the behaviour with developer tools, pressed ‘play’ and went for a coffee. After a while, I could identify that it went terribly slow because I could see the latency increase. Eventually I saw it ramping up until it crashed. Pairing with a developer we could conclude that there was a serious memory leak.
Implicit and Explicit heuristics?
A heuristic is “A fallible approach to solve a problem”
The teachings of RST and BBST and possibly how ‘heuristics’ were meant in the science books would identify all the bold phrases as some variation of a heuristic. I’m sure many other heuristics played in my mind that I don’t have words for yet.
However, notice how the first part of my story is almost completely based on hunches and feelings. Something directed me to find this bug and it wasn’t intentional.
In the second part, I took matters into my own hand. I had a goal, I chose a tactic and was able to measure my results. Other tactics, could have been clicking the button myself for the umpteenth time and miss out on a coffee. I might have asked a developer to look into it straight away and maybe had time left for two or three coffees.
I can’t know for sure whether I chose the correct heuristic or tactic for that situation and I’m sure as hell “# of cups of coffee drunk” isn’t the correct way to measure that success.
We can’t go back in time and compare results of heuristics used vs. the ones not used. Though I’m pretty happy with the results of the one I set up.
The Question Remains
Are the ‘Implicit heuristics’, (i.e. feelings, patterns, biases, hunches) which can’t really be controlled, measured,… useful to call heuristics? They fail, yes. They help you notice things, yes. But do they solve problems?
Are ‘Explicit heuristics’, (i.e. repetition to find boundaries, monitoring for abnormalities, pairing to increase understanding) worth a dime without their implicit counterparts?
It’s not up to me to answer these questions. Yet I find it intriguing to ponder over the matter.
Isle of IT 
I don’t think “getting bored” is a heuristic as such. Paying attention to being bored might be one. A feeling is not a heuristic; having a feeling is not way of solving a problem. But you might use a heuristic while reacting to a feeling.
Intuition isn’t a heuristic, but I think the concept of “intuition” (by which people usually seem to mean “I don’t know how I know that”) can be explained in terms of heuristics that we acquire and apply through experience and inference.
I urge people who are interested in heuristics to refer to the literature: Kahneman and Tversky; Herbert Simon; Gerg Gigerenzer; Billy Vaughan Koen are the standouts, from my perspective.
LikeLike
Thank you Michael! Yes, come to think of it, feelings aren’t heuristics. Acting on them, learning from them with purpose are probably better ways of phrasing that. Though I can easily see how those can be mixed up.
Going through the process of writing it out made me realise there’s a whole lot more to the “observe” part of the process. So much to learn, so much to digest and internalise…
I’m reading Discussion on the Method by Koen per your recommendation. It’s proving to be very valuable, not only in understanding Heuristics. Thank you.
LikeLike
The part of the process which would best compare to a heuristic would be your decision to automate the process and track the performance. As there are alternative methods to perform this task, E.G. pass it to a developer with your minimal observations and lack of hard evidence, continue to manually perform the task until you are convinced one way or another about your hunch there is an issue, you chose the method which would provide the fastest and perhaps clearest path to testing your hunch.
Call it the path of least resistance or the quickest path to a coffee break heuristic. Either way, your exploratory testing lead you across a path which you observed a pattern that did not fit your expectations. You applied a heuristic to identify that pattern and were able to uncover a critical issue before a customer.
LikeLike