In RST, we make a distinction between testing and checking. We distinguish between the two to keep humans at the centre of testing work. Tools can be enormously helpful to testers, but there’s more to testing than checking the build; and testing is something that only human beings can do.
Testing is the process of evaluating a product by learning about it through experiencing, exploring, and experimenting, which includes to some degree: questioning, study, modeling, observation, inference, etc. A test is an instance of testing.
Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product. A check is an instance of checking.
A check is a specific part of a test that can be done entirely mechanistically. The check (or some set of checks) is that set of behaviours in the middle of a test that the machine can perform: the key-pressing and mouse-clicking and the looking up of desired results.
Behaviour, in the parlance of Harry Collins and Martin Kusch (The Shape of Actions), is essentially observable, describable physical movement over time. An action, Collins and Kusch say, is behaviour plus intention. A check can be expressed in terms of behaviour, but a check is always embedded in a test of some kind. A test is an action.
All the way through a test, both before and after the check, there is intention to find a problem, to probe a risk, or to become alert to some condition. There is also intention in the design of the check, in the encoding of the check, and in decision-making about when to run the check — or checks. Then the checking happens; that’s the part that the machine handles.
The check — the algorithmic, mechanistic procedure — finishes, producing output that we might call a result. But it’s not the result of the test; the test doesn’t end when the check does. For something to qualify as a test, there has to be human evaluation and interpretation of the output. If the outcome was a failure, or “red”, there’s a problem somewhere in the product, or the check, or the environment, or the relationship between them. That problem must be interprested. If the outcome was a “pass”, or green, no problem was flagged by the check—but for the purposes of a test, that outcome must be interpreted and evaluated critically to avoid being fooled by an unreliable check. Are we satisfied that that check is sufficient to address the risk or concern or condition that we want to be aware of? The check doesn’t incorporate that, but the test does. That is, the intentions before and after the check are required for a test.
