Blog

On Patterns and Blinking and Puzzles and Expectation (Rhythm of Testing)

On December 26, 2011, in Syndicated, by Association for Software Testing
0

Our family has a lot of traditions around the winter holidays, Christmas and New Year.  One tradition is working on a massive 1,000+ piece jigsaw puzzle.  We see it as beneficial in many ways.  When the kids or grandkids are around, for them to participate (“become engaged”) this thing that we are doing, they need to slow down.  I’ve yet to take any pleasure from assembling a puzzle that can be whipped through in an hour or two.

Our puzzles tend to take a week or more to be completed.  We’ll start them one evening, then each day tinker a bit as each person has a few moments.  In the evening, we try and set aside 30 or 40 minutes to work on the puzzle together.  We’ve found it a great extension of “dinner table conversation” where we get caught up with each others’ day. 

Oh, we both like doing puzzles too, which is perhaps the biggest reason why we do them.

So, this year’s puzzle was a photograph of a Scottish castle, no I don’t know which one, with hills and mountains and things in the background, a bit of water near the castle (hard to tell if it is a river or a loch or merely a fair sized pond.)  Like a lot of the better, or harder, puzzles, there were many bits that, well, looked a lot like other bits. 

In sorting out which bits are which, you need to look for subtle differences – small changes or variances in the overall image.  So, this last week, I had a portion that I was sure were part of the castle’s battlements – the tops of the walls or towers.  Then I noticed another piece – JUST like the one I had in my hand. but a little different.  There was a small line in the piece I had that was not in this new piece.

I blinked.  Literally.

The portion I was working on was indeed part of the battlements – but the reflection of the battlements in the water – not the actual “top of the wall” stuff.  I was reminded of a defect I had spent time trying to track down on a recent project. 

I had a set of expected results and behavior, my “oracles” – and the results – what I was actually seeing, were really really similar, but not quite what I was expecting.  It looked right, but something did not feel right.  What I was expecting, based on the described behaviors and expected results, was generally what I was seeing. But something did not feel right.

It was kind of like the puzzle pieces.  One looked like what I expected it to look like.  The other was, well, different. 

That got me thinking about other things. 

How many times are we certain that what we expect is really what we should expect?  Is it not possible that the expectations are the “bugs”?  What is it that makes the “expected results” “right”?  Even when you are the one who created the “expected” results, how well do you really understand the software?  Do you have a certain understanding as to what the changes will result in? 

In my case, my “expected results” were what was at fault – both in the puzzle and the testing. 

Once I realized my mistake in the testing, it became much easier to move forward.  I will never know about the puzzle, I’m afraid.  The orange tomcat who lives in the house with us decided that he had enough of us assembling the puzzle.

I believe, but am not certain, that we found all the pieces after he scattered them from the table.

Should we try and put that puzzle together in the future, I expect we’ll find out about any missing pieces.

 

Comments are closed.


Looking for something?

Use the form below to search the site:


Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!