June 8, 2010

Blink Tests In A Blink

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.


  1. Nice collection of tips, Joe. I don't think we've ever noted WinMerge before as a blink tool, but of course you're right.

    Here are a couple more examples: any kind of speeded up or slowed-down playback is a blink test too. At one client who had a huge test lab, testers would run a long-running automated stress test on hundreds of machines at once. Periodically they would walk rapidly down the aisles of monitors, observing them with soft focus. When problems triggered a popup or dialog bog, they'd be quite easy to spot.


    ---Michael B.

  2. Dear Joe,

    Nicely drafted.. and abt Examples-> perfect & too good.

    Yes, of course We do blink test (simply we don’t realize/ name it ..)

    If we realize then we can often use it as a lethal testing weapon.


  3. Michael - thanks, and a nice example.

    "any kind of speeded up or slowed-down playback is a blink test too" - While I have used speeded up playbacks, I don't think I've seen a case of a slowed-down playback in this context? Any examples where a slowdown is used as a blink test.

  4. Venkat - thanks. The more I think about blink tests, the more I find ways to use them.

  5. Nice summary, Joe. Great examples, too. I may be citing this the next time I get accused of suggesting "untried" ideas or techniques. ;)

  6. Thanks, James.

    Thanks, Pete. I'm convinced that almost every testing idea/technique you can imagine has already been tried by someone, somewhere. Most of them may be "unreported", but usually not "untried".

    I know I try many techniques that are new to me, as often as time allows. Most of them fail, but that's how learning occurs.

  7. nice work Joe........

  8. Thanks, Pete. Rather than accusing, folks should be praising you for suggesting new ideas and techniques. Otherwise, how can you learn and grow?

  9. very interesting, very easy to use

  10. http://www.Saeedbaba.com

    Hi ! I Like your Post It is very Helpful