Mel's Rant: Non-technical Testing Is An Oxymoron

"The true delight is in the finding out rather than in the knowing." - Isaac Asimov

Somewhere in the the distant past, like a decade ago, manual testing wasn't considered non-technical. It was actually considered to be a very technical job in which someone doing the testing had to understand computers, operating systems, command line syntax to access everything from the directory to error logs, and a million other things that started appearing in the computing ecosystem.

Fast forward to present day, manual testers everywhere are being called non-technical because they don't practice automation on a regular basis. 

When did understanding computers become a non-technical thing? 

We don't call business analysts non-technical. They produce technical writing and information necessary for developers and testers to understand how code is supposed to be created and work. 

We don't call customer service reps non-technical. They deal with customers that are even less technical savvy than your average four-year-old on a daily basis. They manage to bridge the gap between the "helpful tips" people get from their computers, the internet, and the compatibility issues each system presents which they interact with. They have to know how to get to log files, operate a command line, understand where to find different parts of browsers including subtle differences between versions. 

Why has the notion persisted that manual testers are not technical? All testing starts with a manual effort, no matter who does it. 

The conversation we should be having, or asking, should be: "What is your level of technical ability?" If you can demonstrate a technical acumen, especially if you start off in testing and go into a business analyst role or start in a customer service background and go into a tester role, then you are technical. Your technical abilities should be based off of your skill set, and what you can do. 

The other part of the argument often is that anyone could read test cases and testing scripts and test an application or hardware. 

I don't think this is the case. Maybe in another ten years when we've all lived with computers from birth, then maybe that argument might be valid.

I think (the thought is based on conversations not actual proof) the idea comes from the game testing realm. Companies like Blizzard and Zynga hire testers who play the games. They don't necessarily hire testers to actually think like testers. But, they are still technical. They know the games better than anyone. They often they know them well enough to understand where the gaps are in the game, what breaks it, and what hardware is the best to run various games on. If that's not technical knowledge, then I'm not sure I understand the definition of technical. 

I've heard time an again that folks in a game testing role are not technical. I think that's an excuse to pay someone $12 an hour instead of a real wage. Unfortunately, the rest of the industry has bought into that idea.

I was phone screened by Zynga once. They were interested in having me as a tester. I described what I did and they went silent for a moment. The person on the other end spoke again and said that I was too technical for the QA role. I might make a better fit as a manager or a lead. I was surprised considering I had been a tester less than a year at the time. 

Their business model and practice requires a large amount of manual testing. That might have changed, but I doubt it. Because of the graphical nature of most games, manual testing will always necessary to companies in the gaming industry until they figure out how to automate random, interactive, graphical responses (which might or might not happen with machine learning - but we have to wait and see). 

I've interviewed with other places that have given me the equivalent of a developers test and was told I wasn't technical enough to be hired in as a QA. That's OK too. 

I am a coder by rote. I mimic patterns and copy/paste with the best of them. I have some fundamentals but I don't practice them often enough for me to completely avoid running to the internets to look things up. I at least I know where to find answers and usually what they are for. It's often been good enough for automation. It's maybe not good enough to start an automation framework by myself from scratch, however, I'm working on it. I'm getting better. Maybe at some point I'll be able to set up and tear down a whole infrastructure by myself with an automation framework and all the goodies included. Those are goals and I'll get there in time. I have faith in that.

The conversation we should be having in the industry as testers, and with people who are also in the industry but are in other roles is: where are your technical skills are at? Not "Are they non-technical or technical," because computers are inherently technical, period. The idea that you would call any position in a software development organization non-technical is crazy pants! Testing, even manual testing, is a technical endeavor. It might be the foundation of the testers skill set, much like using an IDE is for developers, but it's still a skill. And it's a technical one.