I recently spoke with a recruiter that was seeking candidates for a Software Tester role and it made me think that many of these conversations follow the same pattern:
Why are you leaving your current role?
What automation frameworks have you/do you use(d)?
Which programming languages have you/do you use(d)?
Are you comfortable doing manual testing?
The latter three bullet points are what I wanted to discuss in this post.
This narrative that manual testing is lesser than automation or that itâs something that must done begrudgingly is very prevelant in recruitment; particularly by recruiters that may not have any hands-on QA experience.
How do we move away from this mindset? I always go out of my way to say that manual and automation go hand in hand and that you canât really do one without the other but it does feel like some recruiters value automation over everything.
I would be keen to hear peopleâs thoughts on this.
This is really hard because recruiters interpret these concepts and topics through lense of others. Developers, testers they are trying to place. Hiring managers looking for folks. Our side of technical correctness, all those folks have different wants and their interpretation of these topics is coupled to those wants.
There is also a lot of depth and complexity just around âwhat tests should be automatedâ and there are a lot of opinions floating around out there on different aspects of it.
Recruiters just lack context (broad understanding and technical application) and will always be âbehindâ because of this.
Iâd love to figure it out though as this goes far beyond recruiters.
I never ask those questions. If a recruiter asks you this question then either:
she didnât read your resume
she read it but itâs not on your resume
So the recruiter should probably ask something like " how did you deal with X or Y on your project where you used A or B"
This is a common question yea! Same for âWriting test casesâ
Recruiters are going to ask this anyways. BUT what you can do about it is be ahead of them.
When you introduce yourself, you should already mention some frameworks you used, you should say Iâm not dirty of doing manual testing or writing test cases. Answer the common questions before they get asked, so youâll shine more into the deepdive questions. You can basically take over the conversation and start talking about something more advanced and show your real skills, why they should hire you.
I feel like an odd one out now, since I donât anymore see that asking these questions would be anything more than an opportunity of showcasing the necessary skills, as long as you answer with control of your own narrative - and that is what I would look for in a tester.
The ask of both automation skill and testing skill is a common one. There is no better word of explaining that testing skill is needed than use of the words manual testing because so many people who know how to automate donât know or want to test. We have now also manual programming to describe writing code without use of genAI tools.
The narrative we build with these three questions really matters.
Correcting the terms âtesting frameworksâ and âmanual testingâ frame a narrative of word policing, which tends to be testing at its worst.
Having understanding of differences of frameworks and languages, and being able to frame a modern test automation with these questions is quite relevant to understand while recruiting. Even with a candidate that would not center automation in their testing approach.
With manual testing at the end, it gives the testing skill and emphasis of conclusion. It gives one a chance of expressing the ideas of how one targets quest for particular type of information.
It has not been 10 years for me on understanding that my past ideas of automation were not helping me or my organizations. I realized that narratives I could choose that would warn about limitations of automation would be time away from succeeding with it, and being able to combine these skills is what is sought after.
What would be different if we believed that recruiters know what they are doing when they ask these questions - I have at least come to realize they understand a lot more than what we give them credit for.
I apologise right now to any recruiters, but Iâm done with recruitment agents. I realise that limits me but its those type of questions Iâve just had enough of. When its clear that the recruiter has no idea what theyâre asking, the employer is telling them what to ask because they donât understand what they need but they have an idea on what you should ask about recruiting testers or theyâve gone so far down a path with their team they feel the solution is to recruit another one of the sameâŚaaarrgghhh!!
To me hereâs the crux of it in my mind. All Iâm interested in is:
âWhat is your Quality problem?â
âWhat are you hoping to achieve in your software development and how far off that target are you?â
The answers to those questions will then direct my next questions and my interest in the role.
What recruiters fail to recognise is that testers provide solutions to those questions. The solutions may indeed be manual testing, automated testing, additional tools, maybe even new working practices etc. but always weâre asked questions about the skills tick list to gain entry.
Iâve never had a recruiter work in my interests, its always been get past the tick list and Iâll tell the employer they have to have you. If you tell the recruiter youâre not interested theyâll tell you youâre missing out on a âgreat opportunityâ and try and cajole you into reconsideringâŚfor the commission.
Maybe its coz Iâm at that stage in my career where the âquality problemâ has to interest me firstâŚbut thats usually what you find out last once youâve played the recruiters game. Iâm old (ok âexperiencedâ) and tired of playing that game
Hello @eamond15 As a manual tester, I completely relate to this concern.
The assumption that âmanualâ testing is somehow âlesserâ than automation is frustrating because it overlooks the core purpose of testing, ensuring quality from a userâs perspective.
Manual & Automation are not rivals; Automation is great for speed/effciency but it canât replace human intuition, exploratory testing and real-time adaptability-things that are crucial for catching usability issues, edge cases and complex bugs.
A well-rounded QA needs both.
I have worked on projects where automation helps speed up regression, but manual was what actually identified critical UX flaws that scripts would have missed.
The real challenge is changing this mindset in hiring, instead of viewing manual testing as a checkbox, it should be recognized as an equally skilled discipline that require deep thinking/patience/user-first approach.
The best teams understand that quality isnât just about writing scripts- its about the product, user and risks.
As a current tester and former recruiter, I have to say that my experience has been different to yours. Perhaps thatâs down to the types of jobs we apply for, and the content / structure of our CVs. They may ask that question about âmanual testingâ because your CV reads as though your focus / interests are in writing automation.
As for moving recruiters away from any mindset, I donât really think thatâs for us (as essentially the product theyâre trying to sell) to do. Recruiters are service providers to the clients who pay them to find suitable candidates, and as such theyâre usually just a proxy for the mindsets / attitudes / misconceptions of the people youâd ultimately end up working for. If theyâre not willing to see another way, I donât feel the need to convince them for free. Itâs another thing if Iâm actually hired to change mindsets, processes and such.
There are, of course, some recruiters who are more engaged in the testing space and try to have those conversations with their clients, but if someone doesnât want to be convinced, the recruiter either has to give in and do what the client wants, or forfeit the payment they would have received from placing someone.
That being said, I think one way you could stand out is to highlight the skills behind the tools, explain the impact youâve made, and show how youâre able to quickly learn any other tool they might need. You could also talk about how you decide which tool / approach / method is most appropriate, and lead into how you devise testing strategies, for example.
What Iâm trying to say is that there are reasons those questions are being asked, and thereâs more than one way to answer them.
hi @Eamond15 Recruiters often refer to automation as golden standard, but at the end it is just a tool. Automation is not going replace critical thinking, creative test design and strategy ⌠Its not about automation or manual, but actually really is about problem solving . As a skilled testers we need to asking right questions, identify risks, ensure quality that tool might be able to do coz it requires intuition, context awareness as well⌠Sure Automation helps us to scale our repetitive tasks, is it solving the problem for sure, then good, if not we need to be thinking creative approach for the testing challenges⌠In this case u can reframe your conversation with recruiters around problem solving
Thanks for all the responses so far! Iâm going to try reply to them all individually shortly but I just wanted to clarify what I was trying to say in the original post.
Some people have mentioned that these questions are an opportunity to introduce yourself and talk about your experience, which is completely fine and understandable but it wasnât strictly the problem I had.
Willing and able to complete small % of manual testing as and when required
to help improve product is an example of something Iâve seen in a job description. The way I read that statement is that manual testing is something that is âbelowâ the main responsibilities of the job (automation) and must be done begrudgingly rather than being a key component of testing.
I definitely agree that this goes beyond recruitment and recruiters.
I think there is sometimes a lack of understanding on what a testerâs role is and also, every organisation has different expectations and requirements for their testers so itâs definitely a bigger conversation.
Unfortunately, many companies use recruiters or hiring managers that donât have all the context required for the role so donât often get to ask the right questions (âHow do you go about choosing what to automate?â for example) or give the right answers.
@kristof@maaret I wanted to reply to the both of you in the same post, if thatâs alright as I think your responses had similar themes.
I understand what both of you are saying with regards to controlling the narrative and using these types of questions to give more context to your career. I just wanted to say that this is something I already do when speaking to recruiters. Especially when introducing myself.
Youâd be surprised how many recruiters donât read your resume correctly I still have some ask me how things are going at the company I got made redundant from.
This wasnât what I intended with this post. I hope you see my other post where I tried to clarify what I was saying.
This makes sense however, I find the question often framed as âwould you be comfortable doing this?â rather than âwhat is your experience with manual testing?â
I love this, Gary! I wish more of these conversations were framed around questions like this. As a candidate, youâll learn if itâs the right kind of role/environment for you.
This has often been my experience as well. I feel like I have so much more to offer than âcan you automate? can you use x tool?â This is why I try to talk about ways of working and implementing quality processes when I speak to recruiters. This shows that I see my skills beyond just doing testing which is often what these conversations discuss.
In my experience, they havenât read the CV at all because if they did, theyâd see I have a mixture of both automation and manual testing throughout my career. Of course, they could be asking the questions as a prompt for me to discuss my experience but it doesnât always feel like that. It usually feels like theyâre just going through a checklist for the role.
This makes a lot of sense and I agree that we shouldnât be trying to convince people for free. My only problem is that sometimes, the needs of the team arenât always properly relayed to candidates by recruiters and good people can miss out on good opportunities due to bad recruiters.
I agree that problem solving, identifying risks and ensuring quality is what we as testers are there for. I try to make that as clear as possible whenever I speak to recruiters!
I think youâre absolutely right on both points - a lot of the times, recruiters are going through a literal checklist and donât really understand what the team needs / whether what theyâre asking for will actually result them in finding the person they need.
I recently changed jobs (I am a Software Test Analyst), and was surprised when recruiters would ask me how proficient I was in programming languages, like Python, Java, C3 etc. I am not proficient in any of these, and I donât think you have to be, to be a tester. I am not a Developer. I test, find bugs, yes an understanding is needed, but not proficiency!
One recruiter was surprised when I refused to do a Java test for them.
I think recruiters need to do a bit more research into the role, and understand the differences between testers and devsâŚ
It does often feel like there is a misunderstanding about what makes a good tester and what skills are necessary for specific roles/organisations.
Very often when I ask about the steps in the interview process, Iâll hear things like âtechnical testsâ, âtake-home coding/automation challengeâ and even âlive coding challengesâ.
The role wonât be a âsoftware engineerâ based on the title or job description but the way itâs assessed is for a software engineer. I suspsect this is because some recruiters or companies expect applicants to come from a Computer Science background when this is not always the case.
Do you mean during an interview? Itâs impossible. Companies should move away from this mindset, and then they should guide their recruiters.
Thatâs quite simple - if youâve worked for a while as a programmer, SDET, or QA automation engineer in full-time positions, itâs highly likely that you wouldnât be happy with cross-browser testing, localization testing, or similarly simple and monotonous manual tasks. Even if these tasks are somewhat interesting, itâs obvious that you may prefer writing code. So, thereâs nothing unusual about this question. Itâs a good starting point for discussing real tasks that you may need to handle in a particular team.
As a manual tester, I completely relate to this concern.
I still have some ask me how things are going at the company I got made redundant from.
