Michael Bolton and James Bach define Blink Test (or Blink Oracle) as follows:
"A blink test is any test that alters someway of viewing the application—size, time, position, focus, or sensory mode—to take advantage of people's ability to spot patterns (or pattern exceptions) quickly. Like snap judgment, rapid pattern recognition is something that testers use all the time. It's not always reliable, it's often improved by removing information, and it can be improved by changing the observer’s context."
You probably already do some blink testing without even thinking about it.
James Bach says "I apply blink testing any time I can arrange to be confronted with a blizzard of data: comparing screens (I glance at a million pixels, then at another million pixels, and in an instant I see the tiny difference between them), scrolling through huge log files, or watching an extremely rapid process take place. Anything that seems overwhelming to take in triggers me to consider a blink test."
Michael Bolton says "I've been using blink tests for my entire testing career. When we soften focus and flip quickly between two screens that are supposed to be identical, any difference between the screens shows up as a noticeable flicker."
Blink tests use everyone's innate ability to quickly recognize patterns, differences in patterns, and "movement" to look at a large amount of data and quickly discern: copyrightjoestrazzere
- what is going on here?
- what "jumps out"?
- what is different?
- what is unexpected?
For example, the applications I test often produce log files that have a lot of useful testing and debugging information contained within them. While the logs can be very long and might be time-consuming to read in detail, a blink test can often help you quickly hone in on issues that merit further analysis. For this blink test, I sometimes use BareTail.
BareTail allows you to highlight lines containing particular strings (such as "ERROR"). It also allows you to rapidly scroll through a large log file, and see any patterns, omissions and unexpected occurrences with very little effort.
When I'm testing a browser-based application, I may want to check that a prior build and the current build are rendered the same - even after a change to the CSS. For this, I might load one build in one tab of my browser, and the newer build in another tab. Rapidly switching between the tabs using Ctrl-Tab makes any differences jump out.
(An aside: While preparing a snapshot for this blog entry, I was using the Google home page in two tabs of IE. I noticed that the new "Change background image" link gets placed in a different line on occasion. This difference is easily spotted with a blink test, but I had never noticed it before. Is this a bug with the Google page? Is it a bug with IE?)
Even when you are expecting changes, blink tests with browser pages can be handy. When we were releasing a UI change to a website involving many pages we needed to ensure consistency of these changes across many page of documents, for many of our clients. To make checking of all these pages more efficient, we used a WinTask to bring the two versions up in side-by-side browsers, one page at a time, followed by a dialog box that basically asked "Does this look right?" The testers were then able to rapidly view many of these side-by-side comparisons, while the WinTask log recorded their comments.
One of the test automation techniques I use often is to have the test script dump information for each web page it visits in a text file for later analysis. That way, I end up with a folder of text files. Comparing this entire folder of information to a prior version of the same files is very easy to do with a tool like WinMerge.
WinMerge give us two levels of blink tests - at the folder level, it quickly indicates which of the files in the current folder don't match the corresponding file in the baseline folder. Then, it allows us to drill down and compare the mismatched files themselves - providing a nice way to visualize the file differences.
Recently, I've had to check some large datasets for "reasonableness". For this task, I've found that Excel's Data Filter provides a handy blink oracle.
I load the data into Excel, select all, and have Excel auto-filter it. Quickly scrolling through the filter's dropdown list shows me if something unexpected exists in that column.
A while back there was something odd happening while I was running an overnight automated test. At some point, my scripts went awry, and got out of synch with the website. I added more logging, more error handling, etc - yet I still wasn't able to prevent the problem, nor to pinpoint the issue. So I decided to use TimesSnapper Classic to "watch" the screen for me in my absence.
When I came in the next day, I was able to very rapidly scroll through the periodic snapshots that TimeSnapper created, pinpoint the time when the problem occurred, and see what was going on. This type of "time-lapse photography" has proven useful on several occasions.
Even a simple Windows command prompt DIR command can very rapidly tell us something about a folder full of files.
If one of the files is much larger than all the rest, it might be worth digging in to find out why.
Blink Tests might be worth a try for you as well. It makes spotting differences child's play. As the Sesame Street song says:
One of these things is not like the others,
One of these things just doesn't belong,
Can you tell which thing is not like the others
By the time I finish my song?
Did you guess which thing was not like the others?
Did you guess which thing just doesn't belong?
If you guessed this one is not like the others,
Then you're absolutely...right!
Some of the tools mentioned:
Also see:
 | My name is Joe Strazzere and I'm currently a Director of Quality Assurance.
I like to lead, to test, and occasionally to write about leading and testing. |
