http://www.askoxford.com/concise_oed/criticize?view=uk

—Michael B.

Actually, literary/film critics don't criticise, they critique.

Those are wonderful observations. Thank you.

—Michael B.

@jason…

Why not use "scripted testing" vs "sapient testing"?

That's a good question. To me, it's like the exploratory/scripted continuum. A scripted test might consist of nothing but checks, and it may be performed by a machine or by a human. When a machine follows a script, it's guaranteed to do nothing but checking. When a human follows a script, the human has some choices. The script may also guide the human, rather than controlling him; it may afford the opportunity for the human to use some sapience. The tester may choose to be guided entirely by the script (in which case the tester would be doing nothing but checking), or the tester may choose to observe and report on things that are not explicitly specified, in which case the human is mostly checking, but doing some testing as well. What's it like to you?

@Cem…

I'm not telling people that what they're doing is trivial, but I am asking them to consider the cost and value of tests and checks in their context, and I am strongly advocating a balance of focus in their own work. Moreover, I'm asking the people who manage testers (and the people who train them, and the people who write about testing) to consider what they're asking for, and in what measure. The Agile community has strongly emphasized the value of checking at the programmer level, the role of checking in support of refactor, the significance of automated checks at the integration level (and sometimes at the system level). For quite a while, the emphasis on checking appeared to dominate the discussion of testing—the most egregious example of which was Chapters 19 in Testing Extreme Programming. "No manual tests" is, to my mind, in general, extremely bad advice. Yet (again to me, and again in general) "no manual checks" is a reasonable proposal. Why waste human time, effort, and intellect on something that can be done rapidly and accurately by a machine?

"You'll never get this distinction past the ISTQB or the Agile Testing mailing list."

I'm more optimistic than that, at least in the case of the Agile Testing list. (Mind, I'd have to rejoin it if I were to be involved in the discussion. It may be time for that now.) As for the ISTQB… again, I'll cite McLuhan: I don't want them to agree with me, I just want them to think. I believe the distinction could be helpful in allowing us to be more specific about the activities and ideas surrounding our craft. The ISTQB says that it's in favour of that. If people aren't interested in it, they're probably not paying attention to me or anyone else on the issue, so… no loss.

I'll have more to say about TDD in a future post, but for a quick summary: I agree with you. While the activity of TDD is going on, I think it's fair to call those xUnit thingies tests. They become checks when they're no longer at the forefront of our attention; when they become part of the ground, rather than the figure; when they're performed without the sapient activity that surrounds them.

@Sunjeet…

I'll have a reply for you in a new blog post. It's here.

A tester does confirmatory tests as part of testing ,so does that mean a tester should not do that ?

Should testers shun checking ?

why not call checking as "confirmative testing" ?

checking might be brainless but i believe it is required and testing builds upon checking and enhances it.

example -
A bug comes to me which is claimed to have been fixed by a dev.

I primarily do 2 tasks –

1. I confirm that the exact problem is fixed – by exaclty executing the steps mentioned in the bug report –
by this I confirm that the bug and only that bug is fixed or not

Brainless ?…yes …. a machine could have done the same …yes
BUT
is this required …YES lovewe might not be deriving new quality value from it but we are CONFIRMING existing quality info from it

2.Task 2 i do is …i look out for side effects …regression…new test ideas …execute more tests etc i.e. all the pillars of ET…

but more questions arise then …

1.How is task 2 useful without 1 ?

2.Should i tell my lead/mamager…buddy I am just a tester find a checker to do this ! or get a machine to do this ?
if a machine needs to do this who i going to code/script a machine to do this …wont that be a tester himself ?

3. If 1 dont do task 1 …there is a possibiliy that I might not arrive at the ideas mentioned in task2 !
Might not get lighting bolts in my head ?

Most people don't like being told that what they are doing is trivial, especially if (a) it is trivial and (b) they don't want to change what they are doing.

You'll never get this distinction past the ISTQB or the Agile Testing mailing list.

(For clarification: I have a lot of respect for TDD, and teach this as a required course to our undergraduate software engineers. The unit tests developed this way are often referred to as design / development aids and change detectors rather than as traditional tests. The distinction between testing and checking is very different in that context. The distinctions that I think you're making, and that I'm commenting on, are in terms of the larger-scope system testing effort, which is widely and badly done via checking.)