…..How it could be so this world has come to be

Part 2 of my series on Michael Bolton‘s (F)EW HICCUPPS mnemonic.

Explainability. We expect a system to be understandable to the degree that we can articulately explain its behaviour to ourselves and others.

Do we understand the product that we are testing? Do we need to? If so, how much?

I previously mentioned in Said you’re running out of time….. the value I have found as a tester, understanding how a user would use the product that I am testing. So you could say that I have quickly and cleanly answered my opening questions, stupid blogger.

But, really understanding something and being able to articulate said understanding to someone outside of your domain, or at the very least, your development environment, can be somewhat of an art.

My eldest son has recently become a threenager, and one of the benefits of that is that you are frequently asked ‘why?‘ and more often than not, any answer I give is presented with the same question in a seemingly perpetual loop.

Tactics then are required.

Either I lie, which could have consequences later:


Or, I attempt to meet him at his level to better explain something so that he can process it in his little developing mind.

I try to approach it in a similar way to communicating over a network. If I broadcast at a baud rate beyond that which the target is able to receive data, an error will return (hopefully). Therefore I need to channel my inner child and try to explain things at their level.


It is possible to get this wrong, however.

My son has a fascination with rainbows, and rather than going down the road of leprechauns, pots of gold and unicorns, I attempted to explain the science of refraction simply.

This came down a simple enough explanation:

sun && rain == rainbow
sun && !rain != rainbow
!sun && rain != rainbow

I then followed up with:

mummy && daddy == you
mummy && !daddy != you
!mummy && daddy != you

However, I was informed that this approach is probably a tad ill-advised.

This does all come down to communication and knowing your audience and speaking their language. Metaphors, visual aids and real-life experience can all be excellent ways of articulating functionality without requiring to go in-depth, code level examples.