A pet peeve of mine is someone referring to a tester as non-technical. Business analysts are not referred to as non-technical. UX and UI folks aren’t referred to as non-technical. How did testers get this non-technical tag? How can we advocate for ourselves as testers in a technical role without turning into developers?
I think this stems from what I call the “Any Warm Body” school of testing: the (sadly) large number of businesses and hiring managers who seem to think that the primary qualification for a manual tester is “breathing”.
These are the people who seem to think that if their business analysts and other skilled staff can provide a detailed enough set of test cases, they just need someone who can follow orders to test their software.
Tragically, I’ve encountered testers whose only experience has been in this kind of environment who couldn’t cope with being expected to explore the application and use their intelligence to make decisions about how effective the application was. They needed written rules to tell them what to do.
I think as long as manual testers are both “Any Warm Body” script followers and intelligent, technical explorers of software, we’re going to have this issue - and at least some of these intelligent, technical explorers will turn to automation to try to get some more respect from the rest of their co-workers.
The real challenge? Convincing people that script followers aren’t what they want.
Yeah, this is also something that makes me just scratch my head. I admit, when I was younger, I was asked to help categorize what’s a technical tester from a non-technical tester. What I’ve come to reach is that shouldn’t all testers be technical! I mean, we don’t just find bugs by randomly performing actions on our AUT. Sorry to disappoint, but there’s method to our madness. We design tests, we explore, we figure out where the breaks and misses are, we look under the hood when we can (and if we know how it would help us test), we investigate bugs found so we can provide more meaningful bug reports, we give suggestions on how to improve the application, we test with or without written specs, we work around constraints wherein we have to figure out how to simulate stuff, the list goes on and on…
In my experience, some people are used to talking to developers who will use “technical language” to talk about design patterns, interfaces, generics, classes and often people nod and smile trusting they know what they are talking about.
Then along comes a tester. The tester understand the details of what the developer is saying, but replies in simple English!!
So are seen as non technical…
Its like saying an French to English translator doesn’t speak French just because they are only speaking English to you.
Ah, yes. Translating from “programming geek” to “user”. Since testers often wind up writing part if not all the user documentation this is an important skill, but using it is not always seen as a good thing by those who would prefer to keep “programming geek” exclusive to programming geeks.
Then you hit the opposite side of that issue: the management type who thinks that if it’s not in fancy technical language, it can’t possibly be smart enough.
Not that I’m even a little bit cynical.
“Convincing people that script followers aren’t what they want” to me is “Getting people to let go of the comforting idea that testing can be abstracted away, simplified, made very cheap, made very transparent and reportable up the chain of command, made highly auditable, repeated… and then getting them to face the harsh reality of complexity and all the extra fear, worry, cost, work and responsibility that may entail”.