We don't want some who's 'just a visual tester' - how do I make the case for a non-technical tester?

I work for a consultancy company. One of our clients is a small-ish company that builds software for corporate clients. They don’t have any testers in-house, which is where I come in. On some projects they need testing and they’re usually happy with my work so they keep asking for me specifically.

I really like this company so I’ve been exploring the possibility of making the switch and become their first in-house tester. Our own PM was interested but discussed it with the management and they had one major objection: if they were going to get a tester, they wanted someone who wasn’t just doing manual testing on the front end (which is specifically what they usually get me in for), but someone who’s more technical. I think the words they used were ‘we wouldn’t want someone who’s just a visual tester but someone who could get cracking on the back-end as well’.

Now, leaving aside for a moment that I don’t feel I’m ‘just a visual tester’ (what is a visual tester even), I didn’t really know how to respond. I’ve been ‘raised’ (in IT, I mean) to think that you don’t need to be technical in order to add value as a tester. The fact that they keep asking me for new projects seems to confirm this. At the same time I’m super aware of how I’m sorta lacking on the tech front and cripplingly insecure about it.

What’s your thoughts? Should I make the case for a non-techy tester? If yes, how? Or should I drop it and accept that I’m not a good fit for the company?

How would you, my fellow testers, deal with this?

7 Likes

There’s a lot going on here, and I suppose you need to think about what you want.

I’d say all testers are technical but in different ways. Some can read code, some can write it, some are good with tools made by others, some know a lot about databases or networking or whatever domain you work in. There’s the technicality of fields of mathematics and statistics and philosophy. So if you test the front end but also use a tool to inject test data into a database are you technical or not? Is that back-end enough on which to get cracking? Maybe they want security testing, or performance testing or automatic check code writing or something. There may be questions for the company - a good one can be “what does your ideal candidate look like”. Of course maybe they just don’t want to hire you for one reason or another - e.g. they already have someone they want.

When you’ve settled on what you think they want then it’s a case of whether you do fit that description, or could, or want to. If there’s a gap between what you can do and what they want then you can decide what you can offer, and what you’re willing to. If someone said they wanted a code writer instead of a tester I’d say “that’s not me”, but if someone wants me to learn their API I’d say “of course”.

When you’re straight with that you can decide if you want to work there. If you do then you can negotiate your options. There are things you can sell to them very easily - they know you and trust you, you are familiar with their software and domain, you are easier to price and people who know more about certain things can be more expensive, and you can sell your ability to learn and adapt to their needs. Sell what you can do, make them consider what they’ll lose by replacing you - things they didn’t think of until you said them. Sell what you are willing to do.

So basically your factors are

  • what’s your situation, do you need this job or can you walk into another?
  • do they want you to work there and do you want to work there (will you be working with good people in a good place for good pay, etc)
  • what can you do
  • what do they want you to do
  • what are you willing to do to bridge that gap and stay happy and motivated, and what you’re willing to promise
  • what can you sell them on

While I’m here I might as well point out that you are technical, but there’s a lot of kinds of technical. UI, UX, mapping system states, all technical. If you want to feel more technical take something you do and give a technical name. I made someone much more comfortable with using a “wait command” in some code by suggesting the name “stochastic reliability buffer”. Same code, new thinking.
Learning more technical things is a great way to become a more powerful tester, as is learning about mental models or test framing. In my experience taking powerful testers and training them up in the technical is far easier than taking technical people and training them up in testing. A great tester can test anything, and that often means pushing a lot of reset buttons when it comes to technical things with any new project.
I’d recommend looking at something you can do that you might enjoy and trying it out. A great motivator is ways to take the pain out of your work - being able to reset a database to a known state or inject known sets of useful test data can make your work faster and easier and provide more time for the fun stuff. And if you can do that and still think of yourself as “non technical” then that definition will just expand to fill the size of its container until you can move electrons with your mind.

I guess that’s my overview without further details, hope that’s helpful!

6 Likes

Hi Veerle,

I think it depends a lot on what kind of work the new tester has to do? For example, should the new tester test batch processing in a backend system? Then the new tester might need some skills in the field of DB2 and OPS related tasks. Or should the new tester be concerned with testing API’s? Then the new tester may need more skills in the field of tooling, such as SOAP UI etc. I would therefore explicitly ask them about the kind of work that must be performed.

What I do think, is that the new tester always must have test skills and you have them as I can read :wink:

Maybe nice new discussion…what are test skills?

2 Likes

Wow, Chris, thanks so much for taking the time to write such an elaborate reply. Yes, that was very helpful.

I sort of also object to the term ‘technical’ being used to mean ‘can read and/or write code’, but at the same time I never really feel qualified to actually contest it. Let’s just say I feel I should be able to grasp some of the intricacies of how sftware is actually built, assembled and released and I just don’t, not really. I feel that this is something this company would require of a tester they hire full-time (rather than as a consultant) so I guess that’d be a hard no.

At the same time I feel this is a culture shift they might be able to make. They have a few different locations which are all semi-autonomous, I’ve worked for all three. The mother location is very firm on not hiring ‘non-techies’, the other two locations have both expressed interest in the past.

I feel I could probably add value with the knowledge I have now, but the previously mentioned crippling insecurity kind of prevents me from selling it. If I end up disappionting them, it’ll have been my own stupid fault for selling them something I was never able to deliver.

I really like your list of ‘my factors’ which actually help me think about this in a more structured way - I guess because I enjoy working at this company so much, I’ve been approaching it from a personal and emotional level, rather than from an ‘applying for a job’ kind of perspective.

2 Likes

Hey Silvio, thanks so much for your thoughts.

I think your very last point is actually the mostg important one: what are test skills? I feel I should have a clear answer to this and yet I don’t always have that. When I took courses like Rapid Software Testing I felt I got the answer, but it’s hard to summarise into a concise answer.

As for what I would be doing, that’s the tricky bit - they’re not actually looking for a tester, at least not actively, they don’t have a position open. What they do have is a relatively expensive testing consultant who works on their projects if and when needed (c’est moi) and has been for 2,5 years. At this point I feel that they’d get better value for money if they actually just hired me - they would get all of my skills all the time, not just on the occasions where they need front end testing, and at a lower hourly rate - but they would also be stuck with me.

2 Likes

Hi Veerle,

You are welcome :wink:

I think there is too much focus on test execution nowadays. In other words, to much focus on the checking part, the HOW (which tools, frameworks, etc) and less on the WHAT. So for e.g what should be tested? To what depth should we test? (test coverage)? Which risks are covered by which tests? Which initial documentation is used and do we all have the same understanding about the client needs? Is forward requirements traceability possible? Etcetera. I think these are all very important questions that you should be answered and able to answer if you have the real test skills.

3 Likes

I would not look for or recommend to a customer a non-technical tester, the reality is if we are testing technology we should be technical.

The challenge is what does technical mean? To some its a straight forward can the code the automation regression tests as that is their biggest risk and unfortunately a lot of the industry propagates this view so its often hardly surprising when clients expect the same thing.

Technical though means much more, most of the highly technical testers I encounter often have only basic coding skills and their focus is often the much bigger picture of risk rather than the narrow focus on regression risk only.

Many clients need help understanding what good testing looks like and the value it can add beyond the basic checks, I naturally use language like discovery, exploration, experiments and risk when I talk about testing, some clients really get this but I still encounter some who cannot get passed the regression risk automation focus only.

If you have already been testing for this company how often do you talk about what you are really doing with them, talking them through your testing, your thought process, the tools you use to investigate a risk etc. In my experience once a client understand this better its easier for them to see the often much higher value in a technical exploratory tester even if they cannot code. Testing for me is all about asking good questions, about half my questions I’m not asking the product itself but asking risk questions to the team, if I get the response, ‘that’s a good question, we have no idea about that risk’ then that’s a massive part of the value testing brings and I can then volunteer to investigate that risk.

I should add though I also at times get imposter syndrome regarding how technical I am, perhaps due to not really getting any buzz at all out of coding but also because I am comfortable asking for developer help when I feel they can do something much better than myself, I learn from that but it still often makes sense for people to focus mainly on their strengths.

2 Likes

Hi Veerle!

First of all - each company, each individual manager, and a team - are completely different.
Some of them know which value the tester can add. Some aren’t.

Personally, I’ve never been faced with such a term as “visual tester”. Maybe, the manager is not so mature as a specialist. and has something like a “snobbism” around the term of testing: “Each test engineer should be with Master or Ph.D. in Computer Science! Otherwise, they are not qualified!”.

In this particular situation you can do the following:

  • ask a manager which kind of skills they need from the tester? Which type of work do they need to be done? What are their mid-term plans for the product? If it is automation - what kind of backend/frontend tests do they need?
  • if you really want to join THIS company - you need to get the required skills. There are plenty of free courses and masterclasses here at the Ministry of Testing.
  • but remember - there are a lot of other companies on the market. And these companies want testers with a different set of skills.

Anyway good luck. In case of automation or technical questions - I am always eager to help. :grinning:

2 Likes

Ah here that’s the thing, I think the people I work with directly know exactly what it is I do, it’s those people who expressed an interest in me possibly joining. It’s higher up where the idea of getting a dedicated tester who can’t code doesn’t seem to appeal whatsoever.

In order to convince the upper management, I’d have to engage them in a conversation about testing but that seems terrifying because I don’t actually really know those people. Hearing what they think about testers (which is apparently that if they can’t code, they’re not adding value) it seems a bit daunting going in there tooting my own horn.

Anyway, thanks for your thoughts, I’ve got a lot to think about.

3 Likes

The company I work for took me on five years ago precisely because I wasn’t a “technical tester”. They already had five of those; I came along and offered them a range of skills in business experience, user behaviour, and years of knowledge about running business systems going all the way back to wholly paper systems which nonetheless processed data. (I’d been in testing some 20+ years at that stage.)

I wouldn’t necessarily be a good choice as the only tester in a company, especially if the company was doing innovative coding work. But if a company has a team of testers, and their product is user-facing, at some point or another they will benefit from having someone on the team who can say “What will users most likely do when the system does that thing?” And if the most likely user reaction takes them down a path where the software doesn’t deliver the expected outcome, then the company’s product has a failing and is at risk of not meeting user needs, no matter how technically brilliant it may be.

And that’s a route to lost sales or worse.

2 Likes

Hey Alexander! Thanks for the reply :slight_smile: I think there’s definitely an amount of snobbery going on, although not necessarily in a malicious way, I think. The ‘techie’ thing is also very much in their culture, they’re very big on being a bit geek chic, like, one of their slogans is We’re die hard nerds and they seem to have a shared definition within the company of what nerdiness entails (it’s very Star Wars and commodore 64 heavy). I think that testing doesn’t really fit in that culture because it’s not… traditionally geeky or something? They usually get me in on projects where the client specifically asks for testing to be done on their side and they can’t go without.

But the teams I work with are usually happy with my work so I’m like, if you keep asking me clearly you do see some value in testing…

Anyway, your point about ‘do I really want THIS company’ is a really good one and it’s something @kinofrost also brought up so I’ve been thinking about it.

I guess in a way I do want this company, but at the same time I’m starting to think that I don’t want to be in a position where I have to justify and defend my presence and added value all the time, which might cost more energy than it’s worth. I guess for now I’d do better to look for a company that shares my view of what makes a good tester, at least until I feel more confident selling myself with the skills that I have, not despite the skills that I lack.

2 Likes

Thanks for this Robert! I needed some rubber ducking and the Club has provided. Your comment seems to confirm: there are companies that want, need and value ‘non-technical testers’ and I might be better off looking for one of those. I guess at the moment I’m just not a good fit for this particular company and that’s OK. I shouldn’t be taking it personally (which, to be fair, I think I kinda was).

2 Likes

A clear indication of team and company maturity - is how they treat testing and testers.
A mature engineer will be happy to get any help or additional thoughts on how a particular piece of code or system may fail.
In order to perform testing effectively you need either full support from management or to gain credibility in the team. And in such a company, the only way how to get this credibility - is to have coding and technical skills at the same level as other engineers. Otherwise - yes, it will get a lot of mental and physical energy to justify any testing-related decision.
Is it worth it or not?

2 Likes

I’m gonna guess probably not. Thanks :slight_smile: I needed to hear this.

2 Likes

And another thing: sometimes, I’ve found it easier to have conversations with devs who know that I don’t have the same technical depth of knowledge as other testers. It enables me to ask the daft question: “Is it me, or is it supposed to do that?”

2 Likes

Sorry Verlee, a little late to the party…
your description of the company rang a bell with me, I have encountered that “grading” of testers often. Manual testers are considered the lowest on the latter, testers proficient in automation are higher up. I suspect because someone who works on code is “closer” to a developer or could be simply redeployed as if testing is something that is ultimately unnecessary or at least several steps lower than developing.
As for knowledge of a manual tester, I think there are skills and, even more important a mindset that developers are more unlikely to have. As for skills you probably know the application better from the view of a user which ultimately is the only view that counts. Also you would know how to (and see the importance of) writing bugs in a way that others can comprehend and read, something that is not that common. As for the mindset a tester is someone that’s interested to see how well a software runs not for example how it was build (developers), on what machines it runs (admins) or how well it’s sold (marketing). The ability not just to test a requirement but to have a look “left and right” of the requirement - does it all work too when I switch resolution/OSs/etc and so on. That, to my experience, is what makes us testers better suited than other departments to do quality management.
If your company is just looking for a cheap developer or doesn’t really see the value of a test (perhaps they are required to do it because of regulations) than maybe it would be better to look elsewhere?

2 Likes

Hey Lars, that’s totally OK, it’s nice to get some more thoughts and feedback after I’ve been able to mull it over for a few days.

Here, the more I think about it, the more I think you (and some others who have suggested similar things) are right. As I said in the original post, I don’t think it’s necessarily bad intentions or malice, but it’s true that the company doesn’t have testing as part of their culture. That in and of itself might just mean that it’s not a good fit. I guess I’d sold myself on the idea of possibly working there so much, that I kind of stopped weighing the pros and the cons.

And thanks very much for your reaction, it’s made me reassess what skills I do have as a tester and what value I can add. And that’s a good starting point for thinking about what I want from my next job.

2 Likes

@veerle Just wanted to add that I’m willing to bet you can talk about testing in a far more technical way than the management you described, particularly if “visual testing” was the best they could come up with. You have the skills and knowledge as evidenced by the team continuing to ask for you. Own it :wink: :clap:

3 Likes

Preach!

And I guess I could really do with this kind of encouragement, so thanks, it’s really appreciated :slight_smile:

2 Likes

All the discussion in this thread is shockingly similar to what I personally believe (therefore everything said here must be true :slight_smile: )

I can’t really add to the “approach” and “concept” side.

What I feel, from what you said about the feedback you got is that they are looking for a tester that implements automation tools.
“More technical” MAYBE means they want a manual tester that understand the technical implications of the product features and usage.

But MAYBE they just mean they want some automated testing?

I can suggest some tools that you could relatively simply add to your arsenal but it’s better for me to know about you some more first:

  1. Do you code in any language?
  2. Do you use Postman, JMeter, WireShark, SOAP-UI?
  3. Do you know what is an RDBMS, Elastic, XSS volunerability?
  4. Have you written any Selenium (WebDriver), RestAssured, Cypress, pytest/junit tests?

Also important to know, that new place you are aiming for, what does the product they offer do?
Are they are Python shop or a Java shop or C#, etc?

I think you will anyway need to adjust your pose a little to proceed with them. I will be happy to help :slight_smile:

1 Like