In a recent discussion I questioned whether this was a myth based on the testers Iâve known and worked with over the years.
Working in software development, using mobile phones, computers and tools every day to test. Being surrounded by perhaps more technical developers for years we automatically learn and become more technical over time.
Now non-coding testers are a bit different given we usually have a lot of strong coders around us to cover those skills but to be non-technical in software development for any length of time seems a bit of a stretch for me.
Even when Iâve recruited non-technical people into testing in the past for the other skills and experience they bring to testing its usually only a few weeks before Iâm suggesting building technical knowledge, âTechnical testing 101â was my go to recommendation for those new to web testing for example so they quickly become technical.
Perhaps less technical than some of our team mates but still able to have those technical discussions.
Whatâs the view on this, any non-technical testers out there?
Unless you use ânontechnicalâ as a synonym for âdoesnât write codeâ, which I donât think is a good synonym, then no. Critical thinking is what I would consider a technical skill and, as you mentioned, software is inherently technical so if youâre testing such systems, youâre technical regardless of whether youâre writing code.
I would refer to myself as non-technical, in the sense of non-coder and I quite happily leave âcodingâ to the experts.
Does that mean I donât know what makes a good piece of software? No.
Does this mean we should kneel to the âtest automationâ gods and deem ourselves unworthy? No.
Itâs easy to feel inferior when the business puts extra value on the technical aspect. I still get that vibe, but then I like to remind myself that I have so much perspective on quality as a whole that many test automation experts donât have.
To work in software we have to be technical, to care about software, to understand good UX and to see risks. This is being technical to me and we see it more in ourselves when we start talking to people who donât work in software.
Iâve worked with a lot of manual testers who excelled because they really understood the product or domain. They would frequently catch more bugs than equivalent automation testers because they correctly recognized specification bugs (i.e. the wrong thing done in the right way) and in many products those bugs dominate.
They didnât usually get enough respect or have as much financial leverage though. Automation testers can take their skills to another company operating in a different domain, whereas manual testers with extensive product knowledge will find those skills to be less portable and even if they are more useful they will be treated with less respect and paid less.
Iâve often thought that there should be a technical track for testing (automation) and a product track, because the skills used in both are very different and often highly divergent. The former is more of a specialized developer whereas the latter makes more sense as a kind of product manager or deputy product owner or something.
As a non technical tester I have had to work hard to up my game in this area, usually by understanding the domain in which the software sits, howâs it deployed, where do logs gets stored etc. By doing so I can have good conversations with developers and cloud engineers.
The quote I like to use here to describe this is âMy ability to understand something technically is not limited by my inability to codeâ. Might be a bit strong as I have created very basic automated smoke tests (nothing if, else driven), I do believe that it holds true.
Non- technical testers can gather together and leverage not just in the testing of a system but to explain it to others as well. That doesnât mean that theyâre Product junior, rather bring deep system knowledge to be able to find bugs and suggest improvements.
I also do not think it is healthy to label non-coders as not technical. There is a real need for what we usually call non-technical testing. I am finding far too many software creation issues with design, with UX, fun surprises with performance, and just plain cases of requirements not mapping to what users really asked for. None of which requires understanding of application architecture.
Good platform knowledge is required, sure, but from the perspective of an advanced end-user not as a coder. Still a tester, but doing more of the âprocessâ and big-picture stuff that the âscript-jockeysâ stay out of.
Far too often Iâve been called or seen others called ânon-technicalâ in my career. Often this translates directly to confidence in writing code, but not always.
What I do know, is that plenty of people entered the Testing role via User Acceptance Testing, and came from a business or support background. This means they may previously not have been in the âEngineeringâ or âTechnicalâ department. And some people also make great careers, being expert testers, without writing code.
Why do I think itâs a problem to call such folk ânon-technicalâ? Because I think this is a loaded term, similar to âmanualâ vs âautomatedâ Tester, that infers some kind of âless thanâ because people are not programmers.
Within the world of Software Testing Experts, some people are highly technical, some who do, and some who donât work with code, who all make huge contributions. Also, a Tester may become more and more deeply technical during their career.
One final thought, there are (at least) two different dimensions to think about your current level of understanding of a system:
Technology (could be an analogy for technical), this knowledge is often transferable between projects that use similar technology
Product Domain, this is specific to the business area and is often transferable across technologies, but is less often transferable across projects
Why is this context important? Because both have heavily technical sides to them, some are more business and product-focused and the others are more technology-focused. At any given time, a team member may have more or less current understanding in one or both dimensions, and by working together you can share knowledge and level up as a team.
When I read technical vs non-technical I thought of a scripted/exploratory continuum.
Testers can be more or less technical. Any of the levels of technicality continuum can be good for different purposes and contexts.
What disadvantages a tester is that the market requires a larger array of skills(where the tester can do many things basic/ok), and a lot of the time they canât recognize good testing.
I am lucky to be able to choose when I want to be technical and when not. And both have some nice outcomes to them.
While non-technical, I view more the business side of things, the user and his potential pain, the marketing, sales, commerce and other similar departments that depend on the same product. I find the highest number of problems(although many are that interesting).
While being technical, it highlights the flexibility to reach different things, to go deeper, and to support developers with many things around quality. However, this slows me down and shifts my focus to maybe less important things(from the business/revenue perspective).
I remember at Testbash Autumn 2023 in the talk How DVLA Automates the guys there use the term âhuman-led testingâ rather than âmanual testingâ. I really like that.
Itâs more respectful and to some degree, quashes this whole argument.
What @hitchdev said. I have experienced testers so well-versed in the product that they were in fact âProxy product ownersâ - knowing more about the product than the system owners. Sometimes the business domain is full of knowledge that cannot be easily codified. Currently, I see this mostly in the domain of IT systems based on laws for public services, where rules and exceptions are prevalent. Ministries who ask for a system donât have testers but expect their vendor to test all the details even so. This could be one version of a non-technical tester
This is interesting, I did not really expect many responses to categorize themselves as non-technical on the basis of coding ability alone.
That was the myth part I was partially suggesting, that it comes from those outside testing and testers that did not grasp the other technical skills, discussions, tools and abilities required by testers.
Why would you not just go with non-coding as opposed to non-technical that could lose sight if all your other technical skills?
Yup! I am a non-technical Tester and I have been doing this for over 20 years now. Believe me I have tried over the years to get into coding and I have somewhat accepted the fact that this is just not me - Because I began testing long before it was a technical role, I bring a lot of analytical know-how to my job and it has so far proven to be invaluable
This is something Iâve observed with our professionâI feel like as a group testers tend to not be very good at marketing ourselves. I donât say that to knock anyone, but when I see patterns of companies paying testers less than developers, and also seeing many testers cling to terminology that paints themselves as low-skilled, âlessâ technical than developers, and deserving of those lower pay scales, it frustrates me. Then when some testers try to suggest not using ânon-technicalâ or âmanualâ or other such words with those connotations to describe ourselves, I see the suggestions often misunderstood on an attack on the work people do instead of the actual intention of elevating how we describe ourselves to force other disciplines to take us seriously.
I started as a non-technical tester and I think in a way I still am. Even though I picked up some coding and automation skills over the years I still approach everything differently. I love working in a team where Iâm not forced to be a technical automation expert with people who value a different perspective. We actually try to have a more and a less technical tester in the team.
We have a whole dev team thinking about the technical implications, assuming behaviour based on code. Often the impact and result of code changes were misjudged and I found bugs where there âshouldnât have been anyâ. Iâm also representing our non-technical users and make sure the product works for them.
Unfortunately ânon-technicalâ is seen by many as something negative. People donât want to be non-technical because of this. But I think itâs an important aspect of testing. Instead of renaming it or changing the definition I think we should improve its perception.
Perhaps instead of thinking of the technical aspect of testing as coding, it should be the ability to explain what we are doing; to test with purpose.
One reason people might think testing is not very skilled is that anyone can âdo what we doâ - which is true, to the extent that anyone can stumble upon a bug and report it. But usually they are not applying techniques in order to search effectively for bugs, and arenât digging into the bugs they find in order to provide useful details. If you are not involved with the testing process, or directly dealing with its outcomes (eg fixing bugs), then you might not appreciate the difference.
Also donât forget there are also lots of valuable aspects of being a tester that I would say are non-technical, like communication, appreciating the wider scope of a project or advocating for the user.
