Not everybody can test

It has been, of late, an interesting time to observe LinkedIn posts. Amongst the popular themes are  “manual testing” and “not everybody can test”. While the term “manual testing” annoys me, for the moment, I’m a little over that discussion. Let’s look at the “not everybody can test” proposition. I’m uncertain if I’m about to take a step into testing heresy or not, but here goes.

Let’s start with some definitions of “test” (taken from https://www.thefreedictionary.com/test)

1. A procedure for critical evaluation; a means of determining the presence, quality, or truth of something; a trial:

2. A series of questions, problems, or physical responses designed to determine knowledge, intelligence, or ability.

3. A basis for evaluation or judgement:

Now one courtesy of Michael Bolton and James Bach

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modelling, observation and inference, output checking, etc.”

We’ll start with the “not everybody can test” claim. Let’s put this one to rest really quickly. The members of my family all undertake critical analysis, ask questions, solve problems, evaluate information they are presented with. I have 2 members of my family (beside myself) that actively study and learn about the “product in front of them”. I’m going to suggest at this point that just about every human on this planet tests as part of their navigation through each day.

I’m being deliberately obtuse or silly you say because we all know that “not everybody can test” has software testing as it’s context. That’s  an interesting response as non of those definitions I’ve noted include “software testing” within them and the original statement failed to include that. Cool, let’s change the statement – “not everybody can test software”. This too is problematic. Sit anybody in front of a piece of software, ask them to interact with it, and they’ll start testing. I seem to recall companies running usability labs basically using this approach. Those people are using and learning about the product, expressing feelings about how easy or hard it is to use, whether they want to keep interacting with the software or not, whether they feel they are achieving outcomes that are useful for whatever purpose the software is intended to serve. Ask people about the software they use and just wait for the opinions to flow about what they like and dislike about particular programs. These opinions are formed by testing the software as it is used.

What, you’re now telling me they’re not IT professionals and well, you know, that whole thing about “not everybody can test” is about IT professionals. OK, there’s a bit of goal post shifting going on here, but sure, let’s continue. I’m lucky enough to have worked at a company recently where a number of developers took their testing very seriously. I currently work at a company where the same can be said. They test in considered ways and think beyond unit testing (which is a type of testing). They work hard to make notes about what they have tested, potential problem spots and keep the test team appraised of what they are finding. Their goal is to, at a minimum, find those defects that are obvious or easily replicated and to provide useful information when deeper testing is undertaken. What I can say from working with these developers is that  they are indeed critically evaluating their work, learning about it, forming hypothesis, finding and resolving problems. So, it seems to me, they are testing based on the definitions above.

Say what, you’re still not happy, I’m still misinterpreting the sentence? Oh, right, so now you are telling me “not everybody can test software in ways that are thoughtful and structured to help discover valuable information for stakeholders”. At this point we could still debate nuances, perhaps tweak the statement, but now I’m starting to get the picture. When you say “not everybody can test” you really mean something far more specific? You mean that testers require a set of skills to do their job in an excellent manner. So my question then is why did you start with the premise that “not everybody can test”? Would it be better to instead propose that software testing is a set of skills, abilities and attributes not possessed by everybody? Might it be more useful if instead of telling non testers that “not everybody can test” you told compelling stories about what it is you do and bring as a tester that helps your company deliver excellent software to your customers. Would it be more effective to tell your testing story?

My final questions. Can you tell your testing story in a way that is meaningful and informative? If your answer to that question is “No” then perhaps consider if this is the next skill you should develop. If your answer is “Yes” then perhaps test out your testing story on someone that is outside of IT. See if they understand why testers are so important. Maybe your story needs some honing. If you want testing to be elevated to greater heights then some of that upward momentum is driven by your stories. Are you ready to tell your testing story?

A big thank you to Lee Hawkins (@therockertester) for reviewing the blog pre publication. If you don’t know Lee’s work you can checkout his blog at https://therockertester.wordpress.com/

 

Advertisement