“Clear as a bell and sound as an old engineer”

A baker bakes bread, but also cakes. There’s different types of bread, different types of cakes. There’s big cakes, white bread, multi-cereal and many more.

It’s pretty easy to, generally, explain what a baker does.

A plumber is one of those guys that makes sure your house functions correctly and if it doesn’t he might be able to help you. His specialty is the water system. How it comes in and how it goes out. Don’t call him if you have problems with electricity, network or if your roof collapsed. There’s other guys that do that.

It is possible to explain what a plumber does to a child.

A tester is someone who tests. There’s all kinds of things that can be tested. There’s software, hardware, someone’s way of thinking, any object, any plan or strategy, there’s all kinds of tests to question just about anything. Some testers refer to them as test cases, others think them to be test ideas. “Heuristics” is an interesting notion too.

If a tester were a baker and a test is a cake it could take any form, colour, shape, consistency, dimension and degree. it would also matter what plate it would be displayed on, which tools could cut it, how many pieces it could possibly be cut in, the temperature it could function in, how the cake would react if you’d throw it at a person.

Testing is infinite
Testing is going for full coverage
Testing is an activity that serves a project
Testing is a necessary evil
Testing is a cost

Reading the “explanation” above clearly doesn’t bring home the point.

I find it incredibly hard to explain what I do to just about anyone.
In this order: Kids, family members, my partner, developers, colleagues,…

I found that testing itself is easier than explaining how you test.


I have identified three different kinds of people that I find myself explaining:

– People that are interested and have basic knowledge about the world
you work in, such as a colleague.

– People that aren’t really  interested and don’t have the basic knowledge
about the world you work in, such as a 6-year-old.

– People that  are interested but have no knowledge of testing
or software development.

In order to explain difficult matter to any of these people you could use metaphors.
On this website you can find a collection of testing metaphors to explain certain test strategies and test activities.
Metaphors are most powerful when linked to knowledge the listener already has.
I sometimes use the analogy of how the process of building a house could very much benefit from a tester. Using this analogy with someone who has lived in a tent his whole life and has no idea about the inner and outer workings of a modern house will not benefit from this metaphor.

Showing a kid how you are playing a life size and much more complicated game of “Mastermind” or how you both could test his new pokémon game is much more powerful.

Metaphors and heuristics resemble each other in a lot of respects. Most of the heuristics found here are adapted into metaphors in order to better explain the abstract ideas behind them.

People often patronize testing, since the activity is seen as repetitive, simple and boring. This is true for a form of testing. The one that computers can do, to a certain degree. There is much more to testing than the general perception.

It is our responsibility as a professional to enlighten them.
Training this skill and learning to do it well will surely benefit you as a tester, but also the people you work, or might work, with.