When is testing not really testing?

By testing I really mean checking. I've long championed a view that testing as a reference in software development is misused. Not always I might add but a little too often.

A recent discussion with a colleague around test/quality role capabilities raised this very issue again and prompted me to take to the keyboard for clarity of thought.

"Surely it's just semantics" you might say or maybe "you are just being pedantic". Well actually no. It is, in my opinion, the key to really understanding the value and role of both 'testing' and 'checking' in software and subsequently a doorway to becoming a more effective/valuable team member. It also helps understanding of the value and limitations of test tooling.

It is a widely discussed topic within the testing community. The revered James Bach and Michael Bolton have written a number of blog posts and articles discussing as well as building it into the 'Rapid Software Testing' methodology.

The article that really reminded me of the importance of this question is a ThoughtWorks article by Rouan Wilsenach passed to me by my aforementioned colleague.
https://www.thoughtworks.com/insights/blog/qa-dead

This article discusses the role of a 'tester' in a modern software development team and the why really understanding your role and what value you can bring to the team is so important.

I have regularly had discussions with people suggesting that to be an effective tester one must be engaged in automation or writing unit tests. Sometimes those discussions insist a need to be able to write tests in Python, Ruby . I don't disagree that these skills are "advantageous" and can help engage in certain team activities however this in itself does not enable a tester. The ability of a person to understand a product and subsequently challenge that product are what really enables a tester. The ability to understand what is being asked for in features and then think 'but what if.........' enables a tester.

Why is that?

Put simply, automation (code, UI or otherwise) can only CHECK what it is told to CHECK. That isn't going to change until AI really is AI. In a 'cross functional' development team I would expect an abundance of technical ability and people ready to write code. What a team really needs to ask itself is whether it has people with the ability to challenge what is being asked for, challenge the team, challenge the product, ask all the 'what if.......' questions, to find flaws from concept to completion where others wouldn't. In other words, does your team have someone who can really TEST the product.

Similarly I am fully aware that the world still has many software delivery teams that throw software over an invisible fence to test and expect testers to run through a plethora of functional test scripts to say it’s all ok. Again I would emphasise that what is actually being done is CHECKING that something works how we think it should work. I'm not suggesting this is necessarily a bad thing (although I would question whether there is a more effective way of doing that checking), however the actual art of TESTING comes in how we come up with those scripts. Are you really trying to understand and challenge the product/change or just tick a box to CHECK something works as expected.

By all means check things are working regularly but ensure you are really testing the product right from inception first.

It might appear to be a subtle variation but understanding the value of testing versus checking and how they/you can ultimately add the most value to your team should lead to a much brighter and happier place.

I'll leave you with a self portrait!