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?
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!
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
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.
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.
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.
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.
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.
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.
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.
Hey Alexander! Thanks for the reply 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.
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).
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?
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?ā
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?
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.
@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
All the discussion in this thread is shockingly similar to what I personally believe (therefore everything said here must be true )
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:
Do you code in any language?
Do you use Postman, JMeter, WireShark, SOAP-UI?
Do you know what is an RDBMS, Elastic, XSS volunerability?
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
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.
)