The non-technical tester, is this a myth?

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?

5 Likes

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.

7 Likes

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. :smiley:

5 Likes

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.

4 Likes

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.

1 Like

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.

2 Likes

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.

2 Likes

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.

3 Likes

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

1 Like

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?

2 Likes

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

4 Likes

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.

4 Likes

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.

1 Like

Here are at least 4 further kinds what testers can be aside (not) technical:
administrative, analytical, social, empathic

Others kinds of tester are there: User Expert, Developer

2 Likes