Innovation Tools: Pattern Recognition

By October 23, 2014 Skills 5 Comments
hiding cheetah

Pattern matching is the 6th in a series of posts about innovation tools, inspired by Dr Carol Stroheckers presentation during the CAST 2014 software testing conference. Pattern recognition is a fascinating area to study, and sadly I don’t expect to do the subject justice in this post.

Pattern recognition is the ability of an individual to consider a complex set of inputs, often containing hundreds of features, and make a decision based on the comparison of some subset of those features to a situation which the individual has previously encountered or learned. – Velerie M. Hudson

Pattern recognition is what James Bach is referring to when he talks about the Blink Heuristic during his Rapid Software Testing classes. It’s the brains ability to identify connections and discrepancies in sets of seemingly random or very similar looking data. It’s also an area of ongoing research for computer scientists attempting to mimic and codify this ability for use in machine learning, utilised in areas such as finance for transaction monitoring and stock market trading.

It’s apparently an incredibly difficult problem to solve and while carrying out my research I couldn’t help but be in awe of the brain’s ability basically to pattern match from birth – where no sooner have we emerged from the womb (and quite possibly whilst still inside) than we begin to identify patterns in sound and visual characteristics – learning to discern between familiar and comforting from different and scary.

Training machines to recognise patterns in the same way however is a phenomenally difficult problem to solve, demonstrated by the picture below:

Find the Q

Image from Pattern Recognition: An Overview – Prof. Richard Zanibbi

The image represents a problem known as feature search asymmetry, which is basically another way of saying it’s more difficult to find the absence of something (the missing tail from an O on the left) than the presence of something (the additional tail in the Q on the right). This is of course analogous to a problem we’ll be all too familiar with as testers (i.e. it’s easier to prove the presence of bugs than their absence).

It’s also the reason why automation can never replace the thinking mind of a human tester. Machines can only look for what they’ve been instructed to look for, and programming them to look for the right thing without encountering false positives and negatives is hard.

Pattern matching algorithm example

Image from Pattern Recognition – Rob Goldstone

Identifying an R in the sequence above is achieved by checking for the correct combination of lines, angles and curves – but results in several false positives. It’s a trivial(-ish) example, but it serves to illustrate the point. Most human beings can do this while barely even thinking about it.

Pattern recognition (from a cognitive psychology perspective) is a thinking process that is dependent upon the knowledge and experience a person already has. The ability of a person to be able to apply pattern recognition to a given problem or situation is a function of their exposure to experiences and knowledge that enables them to separate a signal from the surrounding noise. Less experience results in less pattern matching. More experience results in more pattern matching.

This indicates to me that it’s a skill. And skills can be developed.

Experts do not think less. They think more efficiently. The practiced brain eliminates poor solutions before they reach the conscious mind. – Kevin Ashton

In his book How to Fly a Horse — The Secret History of Creation, Invention, and Discovery, Kevin Ashton talks about how expert quarterbacks take less than two seconds to analyse how many opponents are attempting to prevent them from throwing a pass, while also analysing what formation they’re in, and ultimately making a decision about whether and where to throw the ball based on the relative positions, speed and directions of their team mates.

There’s an extract here and in it he identifies “selective attention” as a hallmark of expertise. Going on to talk about how Radiologists are also “experts in seeing things quickly”, carrying out an x-ray diagnosis within milliseconds in some cases.

All of this sounds a lot to me like what testers do. They look for patterns in how software behaves, distinguishing anomolous behaviour, outlying responses, missing features and misinterpreted requirements. Good testers are adept at separating signals from noise on projects and in organisations.

Great testers have learned how to take that signal (a bug by any other name), and turn it into information that adds value to people who care about the product under development.

So with that in mind, I started to wonder how, if I didn’t have it already,  I might practice and leverage this skill?

I came up with some rudimentary ideas below:

  1. Transforming test results into metrics may help us to identify behaviours or trends in the software under test or in our automation stacks.
  2. Capturing images of our software (e.g. during automated test runs) and reviewing it regularly may help to identify changes or bugs that would otherwise go unnoticed.
  3. Reviewing our own and the testing notes of others may help to identify beneficial or detrimental working patterns.
  4. Video recording and reviewing exploratory test sessions may help us to understand how we and others test, the skills involved (or missing) and how to improve them.
  5. Playing pattern matching or testing games such as SET or Zendo may help us to develop pattern recognition abilities (I’m terrible at SET, but for some reason pretty good at Zendo. What’s the difference?)
  6. Observing (and recording) our own behaviours by way of a journal might help to identify patterns of behaviour that are helpful (and to build upon them) or unhelpful (hopefully eliminating them).
  7. Observing (and recording) the behaviours, practices and processes of our team, project or organisation may help us to identify patterns that can be improved upon or that lead to dysfunctional outcomes.

Perhaps you’ve identified or implemented more? If so, I’d love to hear from you in the comments section below.

- Simon

P.S If you're interested in learning more about performance testing, checkout my Performance Testing 101 course here.


Leave a Reply