How to find a good tester?
In What does it mean to be a tester? I have mentioned that I’ll write what to do to find a good tester. So this will be basically it.
In a linked article, I wrote about the qualities that a good tester should possess. Today, I’ll try to explain why IT companies hire testers the wrong way.
Let’s start by defining how testers are currently hired.
Typically, the process looks like this: a company posts a job ad, which usually includes:
- Years of experience
- Knowledge of tools (Postman, Soapui, GCP, Salesforce, Azure, Jira, CRM, docker, etc.)
- Language proficiency
- ISTQB
- certification
- Mindset
- Experience with SQL, API, etc.
- IT degree or related education
- Other things related to the specific project.
What’s wrong with this, and what’s actually useful?
- Years of experience => I don’t have any complaints here, when I worked for a year, I had a completely different (more limited) perspective than when I worked for 5 years. And after 12 years, my perspective has changed again.
- Knowledge of tools => I might get in trouble for saying this, but in my opinion, this is the worst thing recruiters do. At the same time, I realize that it’s the easiest thing to check. But let’s look at it this way: there are 2 types of tools:
- a) Tools useful in testing (Postman, Soapui, Jira, etc.) => I haven’t encountered a tool that took me more than 2 weeks to learn (to a usable level). And considering that, at the beginning, you ask for access to jira/repo/etc, which can take 2 months (Yes, in one project, it happened to every new team member, the charms of corporations), there’s usually plenty of time to learn the system.
- b) tools used by clients (Salesforce or other CRMs, etc.) => it’s even simpler here, if it’s a tool designed for use by ordinary people, it must be simple by definition, so learning it won’t take anyone more than 2 weeks…
- Language proficiency => Absolutely necessary. Learn languages, if only to be able to use Stack Overflow.
- ISTQB => This is probably the most overrated thing I’ve encountered. I got my certificate in 2015 and since then I’ve only used the knowledge gained there during job interviews. In everyday work, absolutely no one has ever asked me if I’m doing test cases for Boundary Value or equivalence partitioning. It’s only important to cover all cases. I can agree that for junior positions it makes sense, because there is indeed knowledge there about how to create appropriate ranges, but for anyone with more than a year of experience, these things are already natural and it doesn’t matter much what they’re called. It matters if candidate can set them correctly.
- Mindset => I completely agree, curiosity is the key.
- Experience with SQL, API, etc. => I have a similar opinion here to the tools from a few lines above. I completely don’t understand this requirement because throughout my career I almost haven’t encountered a task that would require writing the JOIN, 90% of the SQL knowledge needed for testing is ‚select * from xxx where date > yyy order by id desc’. Of course, there are more complex queries. But the ability to use SQL documentation, or Stack Overflow, or God forbid ChatGPT, solves these problems in 15 minutes. And to make it even funnier: When it turned out that I actually needed some more complex script, it’s usually a repeatable thing, so once you write it, it’s enough to save it for the next time… With APIs it’s similar. Understanding that a given endpoint sends a given text in a given format using a given method to receive a given response in a given format is again 15 minutes. And if there’s also a swagger with documentation in the project, then it’s unclear what needs to be learned at all.
- IT degree or related education => for a junior it will be useful, higher up it doesn’t matter, only experience counts.
- Other things related to the specific project => This may or may not make sense, but it’s not up to me to decide.
But to avoid just complaining, what would I propose instead?
As I mentioned in the first article: a tester should be a person with the curiosity of a child. So you need to find curious people and see how they solve problems. How to do that? Test candidates, not conduct interviews about theory. If someone is to be a tester, they should be able to handle any task that is presented to them. And based on how they cope, you can assess how good a person you are dealing with.
At this point, it’s worth noting the elephant in the room: For years, testing has been the ‚easiest’ way to enter IT, attracting people with salaries. In my opinion, this has done a lot of harm to both these people and the testing environment. To these people, because if someone memorized ISTQB, passed the interview with flying colors, and then ended up in a project where they actually had to test, they probably went crazy or started talking to HR about changing positions. And to the environment, because by attracting people who don’t want (or can’t) to test, it causes the quality of tests to drop, and this causes product owners or company shareholders, not seeing the added value in testing, to start ignoring them.
So now let me describe what a standard tester interview looks like that I conducted:
- I always started with a task (example in the picture somewhere nearby)
- The task was the same for everyone: ‚Here’s a task. Work however you want. Find the bugs.’
- As the candidate started to solve it, I started observing how they behave, how they approach the problem, if they ask questions, etc.
- After the task, we moved on to a conversation about what they found and questions that also focused more on solving everyday situations than on reciting formulas.
- And very importantly, all questions about situations/all possible bugs had many possible answers, based on these answers you could assess how experienced someone is.
But wait, what does this give us, how I did the interviews?
It gives so much that instead of a standard tester job post, I would propose: Ask the QA Lead/Manager/Senior Tester, or whoever knows about the project, to prepare a task more or less related. It doesn’t matter if it’s a find-the-bugs task, or a ‚propose-a-solution’ task, or any other. The important thing is to give candidates a chance to show how they think, how they approach problems.
Once you have the task, the job ad should look like this:
- task (with a deadline for submitting solutions)
- years of experience (although this is optional, only if this person would be the only tester in the project), if there are already testers in the project, I would prefer to hire someone who will solve the task perfectly than someone with 5 years of experience but a poorly done task.
- language proficiency (if required)
- information about the next steps (there must be an awareness that after solving the task at home there will be another technical interview, where there will be another task performed, to make sure that they didn’t cheat in the first one)
What’s the benefit?
- People who will enjoy it will get into testing
- There will be fewer candidates, because those who don’t want to solve the task won’t be testers due to lack of curiosity. I would rather expect the task to be solved by testers who are not interested in the job, just for fun.
- The company will find people who will be able to learn testing very easily and for probably much less money will be able to find people no worse than the current ones with many years of experience.
It turned out longer than I thought, but I hope I clearly explained what I mean and where the problems are.
Konrad Rafałko eMeReF 
Dodaj komentarz