Blink testing exercises
Blink testing, as described by James Bach and explained by Michael Bolton, is an oracle heuristic based on “snap judgment” effect.
Try catching “bug” (an odd character) in patterns below.
I arranged them by difficulty I had. Feel free to put your experience in comments.
In full-screen view all characters are 10pt capitals, as in standard Notepad window.
Easy difficulty
(click to see full-screen in a separate window)
(click to see full-screen in a separate window)
Medium difficulty
(click to see full-screen in a separate window)
(click to see full-screen in a separate window)
Hard difficulty
(click to see full-screen in a separate window)
Impossible difficulty
(click to see full-screen in a separate window)
Copyright notice
I maintain no copyright on the idea of such puzzles or the patterns used. I saw many of them on the Web on free resources, and I received some of them as fun stuff via mail.
What I did was creating the patterns of same size, and saving them as images, to prevent cheating through source code view.
5 responses to "Blink testing exercises"
With my (older) eyes, the only way I could spot the difference in the last image was to paste it into Paint, and Zoom in to a Large Size image.
If my tests consisted of detecting inconsistencies in these sorts of images, I wouldn’t use a lot of blink testing…
[ Albert’s reply.
Joe, thanks for sharing your experience and problem-solving approach.
Connecting back to your question about puzzles, approach is more important than result, isn’t it? ]
Nice post.
I found the medium and hard easier to solve than the 1st two puzzles. Or maybe it was just my eyes getting used to the images :o)
[ Albert’s reply.
Andy, thanks for the comment.
For me, it also takes some time to get my eyes into defocused mode. ]
“approach is more important than result, isn’t it?”
Perhaps in puzzles and games.
But not in software testing…
[ Albert’s Reply.
Depends on what to see as a “result”.
I’m talking in terms of number and severity of bugs that might be found.
Testing is never ending story but we always have to stop because of time constraints. We never know beforehand what types of bugs and how many of them there are in the build that we are about to test.
However, one approach might be more productive than another. Ergo, approach is more important.
Thanks. ]
This was a fun exercise, but I wouldn’t call it a blink test. Blink testing (as I understand it) is using the eyes and brain to discover patterns in large amounts of data (I use this to decipher large log files often).
This was more of a “stare test” – which I also find valuable – particularly when debugging in order to try and notice what small bit of change /within/ a large pattern I can notice. When I talk about / teach debugging, I often refer to the old Hocus Focus comics as a form of debugging (the best debugging is often “Debugging by Thinking”).
I found them all – my eyes hurt by the last one, but it still only took a few minutes. I’m sure younger testers (with better eyes) would do well at this.
[ Albert’s reply.
Alan, thanks for stopping by and sharing your expertise.
Off course, these exercises are not blink testing per se, as an odd character is not a bug itself. But an inconsistency often indicates a problem, and blink testing is one way to discover them.
“Debugging by Thinking” (I thought of it as “imaginary code execution”) is one of Old School things that I’d want to see used more often [by other people]. I learned DbT hard way (used to write drivers in 80×86 Assembly), but it always was of great help to me since then, in programming AND in testing. ]
This is interesting puzzle. Initially I stared at the images but no way to find that odd character.
I closed my eyes and tried to figure out similar character and I could immediately point out the odd one :)
Maybe little bit thinking (brain) is required to get fast solution.