Why the dichotomy of testing versus checking is the core of our craft

Please note: This post is being updated.
In his Why the testing/checking debate is so messy – a fruit salad analogy, my good friend Joep Schuurkes posts an absurd dialogue in which two persons become confused because they cannot distinguish between apples and fruit. He claims the dialogue could still happen if apples is replaced with checking and fruit with testing.
He is trying to show that in the same way that apples are a sort of fruit, checking is a sort of testing. And that discussing testing *versus* checking is bullshit.
I think Joep is wrong, and I shall discuss why and how here.
A little “versus”
The core of the discussion is the little “versus” between testing and checking, which Bolton and Bach insists on. And I insist on it too: It introduces a dichotomy, which is not only important, it is even necessary.
And it is necessary because it shapes our thoughts about testing.
To be precise, it leads us to think on a conceptual level instead of just an activity level. Once we accept the little ”versus” between the two, accept the dichotomy, we can start thinking about our craft. We are no longer forced to only think about the activites we do.
And just as important: We can distinguish our craft from something that it is not.
It’s like the way more and more people discriminate between leadership and management. Once you accept that the two are conceptually different, something interesting happens: A whole new understanding of the act of playing ”the boss” reveals itself.
In the same way, when we start discriminating between testing and checking, the way we talk about what we do as testers, change. And we change.
A humanistic and value producing view on testing has revealed itself to us through this dichotomy:
Testing was, but is no longer…
Testing is no longer a necessary evil, only done because programmers are sloppy, don’t read requirements and make mistakes. Instead, testing has become a craft, carried out by humans. A craft that adds value to the product, the organisation and society as a whole.
We are no longer little machines working under detailed instruction. We are testers, and therefore everything we do, our job satisfaction and even the value we produce, depends on this very dichotomy.
I will not let the confusion confuse me
So why the confusion? Well, I think the confusion arises because we confuse concepts with activities when we talk our daily, ambigous language.
As a tester, I carry out checks when I test, but when I do, the checks I am doing are elements in the testing and the whole activity is testing, not checking.
But if, on the other hand, I program a computer to run through a number of input combinations to a software program, have my program verify the results by comparing them to something ”expected”, and produce a report of boolean results on the basis of this, the whole activity of running that and distributing the report from the computer program is checking, not testing.
However, letting this confusion lead us to discard the difference between testing and checking would be a pity. The dichotomy is core to Boltons and Bachs testing philosophy. If I reject it, I have to reject more or less everything they say about testing.
And worse: I will have to give up my profession.

PS: Joep tweeted to me that the only dichotomy he can think of with regards to testing is between good testing and bad testing. To me, the difference between good testing and bad testing is about performance. Good testing produces more knowledge and better knowledge than bad testing. Bad testers can improve and hopefully become good through training.
I could imagine a dichotomy for good versus evil testing, though. Evil testing would be testing that knowingly produce incorrect results, doesn’t test, but make up lies, and communicates untrue facts.

PPS: Another implication of the idea that there is a dichotomy is that if we for a moment assume that there could be something called ”scripted testing” or ”automated testing”, then it would not really be scripted testing or automated testing, as in someone really following a script in deail or something is completely automated by a machine. Then it can only be checking.
This is not because of any definitions of the words checking or testing, but because of the idea of the dichotomy. In other words: It is only when we seperate the two, that they materialise as real concepts.
On the other hand: If someone, who has hired me as a tester, but is not aware of the dichotomy, or who will not accept it, comes to me and says: Please set up an automated test suite, I will accept the order and know that what he really asks me to do is to set up a tool assisted test: A set up, where a tool does checking and I, the tester and user of the tool, evaluates the output of the tool and commuincates the testresults. And adjusts the tool in a forthgoing process.
I think Bolton and Bach will – in their latest terminology – call this ”tool assisted exploratory testing”, but the word ”exploratory” is really not necessary.