This discussion has been going on for a very long time, and it won’t ever end, it won’t end. I repeat that because it’s reality, such a discussion will never end. But that’s OK.

I consider myself a student of testing, over the last ten plus years I’ve formulated a mass of thoughts on testing. One of those happens to be the believe that there is a huge difference between what a human can do and what a computer can do, in the context of testing. One of those distinctions is labelled by some as checking and testing. The distinction being that when we automate a check, it’s a fixed algorithm, unable to observe anything other than what’s it’s instructed to. Unable to change its behaviour or flow other than the flows that have been coded. Therefore, it’s checking the flow of the steps and some outcome/behaviour at the end. However, when we test, due to the fact we’re humans and have the best tool out there, the brain, we can observe all, we can change our focus hundreds of times a minute. We can observe in real time and adapt accordingly. Now sure, for the AI/ML fans, sure computers are showing some signs of this now, but they won’t be in the regular development teams office any time soon. But that’s not the point of this post.

I believe this distinction is universally agreed by any student of software development, and especially testing students. So, we end up at our choice of words and their importance. They do carry some importance. Others have written far better pieces on that topic then I can, so we won’t go in to this.

So, let’s look at this from my angle:

I don’t care what words you use.

I actually don’t. I do not care. I’ll never correct you. I’ll never reply to your blog post going ‘I think you mean checking’, ‘excellent piece, but by the way, automation cannot test, that’s checking!’. I won’t do that.

What I will do, is frame my responses to match my own views of testing, because in my testing world there is testing and checking. Those words are congruent with my view of testing. Therefore, when I write or talk about testing, I use those words, they fit my current beliefs of testing. They fit my models of testing. My models. They may not be in your beliefs or models of testing, and that is OK. In fact, it’s more than OK, it’s awesome, it’s awesome that you’re aware of your own models and sharing those with a wider audience.

You will hear me say ‘automated checking, you will hear me say ‘automation in testing’ and you will hear me say ‘automated check. You will also hear me say, ‘I’m going to use my language for testing during this talk, so if you hear me say the word check and you’re unsure what I mean, replace it with test and say it back to yourself’. I make a similar statement when I say tester these days, ‘if I say tester during this talk, I mean anyone who does some testing, not the role’, but I digress. You will also hear me say the words above without making such a statement, but hey-ho, on we go.

You will hear and read people saying automated testing, you will hear and read people saying automated checking, but allow yourself to process them against your models, let you brain change checking to testing, or check to test, or vice versa and continue the conversation, continue the learning.

Now I do tailor my language for who I’m talking to. If I’m talking to a fellow student and I know their models are similar to mine, I’ll choose my words accordingly. This allows us to get straight to the heart of the discussion. If I’m talking to a client, I’ll use their language, as this will make them more comfortable and allow me to truly understand their problem and needs. Overtime I may introduce some of the words more congruent with me, but only if it brings value and helps us solve the problem(s).

So on we go, I say check, you say test, I’ll say test sometimes, you’ll say check sometime. Be congruent with your own beliefs and models, but at the same time, bend a little bit, flex here and there, I believe such an approach will improve all of us, and in turn, testing and software development.