Testing and checking

Let’s see if we can think and reason about these two terms using an analogy.

Orienteering is a group of sports that requires navigational skills using a map and compass to navigate from point to point in diverse and usually unfamiliar terrain whilst moving at speed. Participants are given a topographical map, usually a specially prepared orienteering map, which they use to find control points.

So, a person who is participating in an orienteering competition uses a map to navigate to different checkpoints as fast as possible. Isn’t that similar to what an automation tool does in a code base? Quickly running through a system and performing checks that have been predefined by someone else?

Now imagine a person who is still in an orienteering competition, still has the same map with the same predefined checks but who while running from checkpoint to checkpoint also carefully looks around at the surroundings. And perhaps even deviates from the shortest route to the checkpoints on the map if something interesting appears. So this orienteer might still care about visiting all the checkpoints but will also care about investigating and documenting observations made while exploring the area where the competition is being held. Doesn’t that sound similar to what a tester does? Deliberately scouting the system while using skill and critical thinking to find valuable new information?

So checking can answer the following question:

“Did you or did you not find the thing you were looking for?”

Added note 2017–06–13: An important distinction between checking and testing is that checking can be automated.

And testing can answer this following question:

“What did you find when you went looking?”

Side note:

An automation tool can of course be used to help probe and explore something while testing something but that doesn’t make the testing automated.

End of side note.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.