I don’t think at this point my credentials as a ‘testing geek’ are in question. But here is another example of how I translate most things into a testing lesson or idea.

picture of some go tickets

I commute into work on commuter railway. You can purchase tickets in three forms; a pass (daily or monthly) for unlimited travel between two points, a single ride or multiple rides (2 or 10 rides are available). It is up to the passenger to ‘punch’ their multi-ride ticket before entering the train. Enforcement officers randomly patrol the trains to check that people are working within the system — which works pretty good.

This month I am using 10 ride tickets as the holidays makes the savings granted by the monthly pass actually negative. Tuesday morning I punched my ticket and got on the train. On the way home I pulled the ticket out of my wallet and saw that I was missing a punch. I just thought I forgot to punch it on the way in or something (sometimes that happens as I rode with a monthly pass for years) even though I am sure that was not the case in this situation.

On Wednesday morning I punched my ticket (being a creature of habit I used the same machine) and happened to notice that there was not a new ride cancelled as there should have been. So I punched it again. Still no ride. Same thing a third time.

Then I looked closer at the ticket. It appears that the machine was out of ink. In just the right light you could see the indentation of the cancellation on the ticket but there was just a tiny bit of ink off to one side of the line. Ink plays a critical role in the whole process as bars down the side of the ticket tell the machine where to cancel the next ride. This meant that I could cancel 20 rides in the exact same slot of the ticket.

So what does this have to do with testing?

At the most basic level, a common testing oracle for all problems which is what you observe with your sensing.

  • Sound – The cancel machine did not do its beep-beep-beep indicating there was a problem and the machine did make the proper printing sound. (Which according to the transit authority’s website is “chunk”)
  • Touch – Once the machine finds the next ride to cancel it clamps onto your card so you can feel that it is doing something. If the machine is confused it will take the full length of your card so even if you are feeding it in while asleep (I’ve done that a couple times :)) you can tell when it is working.
  • Sight – This is where my problem originated. I did not physically look at the ticket on Tuesday to see if it was written. Had I done that, then I would have noticed a problem. Having identified this process problem I am modifying my routine accordingly.
  • Smell – Not contextually relevant.
  • Taste – Not contextually relevant.

Most software testing activities will involve Sight and Sound to a greater degree than anything else but it is pretty trivial to be able to think of situations where the behavior of the software is observable with the other ones as well.