How not to hire a good tester

The job market is boiling. Nowadays it looks like everybody needs a tester. And you too want one, of course.

So, you want to hire a tester, ideally a good one.
But there is a problem: you know almost nothing about testing.
What do you do? Look for advice?
Nope, you don’t have time —and much less the humility— to do that.
You are going to do exactly what you shouldn’t do to hire a good tester.
And you are so skilled at doing so, that you act impromptu.
Anyway, I hope you don’t mind letting other organizations know the steps they need to scrupulously follow in order to do the same as you.
Please, let’s share with them a short guide on how not to hire a good tester!

Let’s start with the job description.
Make sure:

• it is filled in with as many references to automation as possible
• special attention is drawn to programming languages and frameworks
• everything related to automation seems exciting, challenging, rewarding, etc.
• nobody notices that you actually think that testing is something that everybody can do, especially machines or monkeys
• exploratory testing is not mentioned at all (after all, you, as the hiring manager, are a strong believer that exploratory testing is evil, just because it is not scalable —by the way, exactly like your management duties, coding, and many other activities which involve thinking…)
• testing techniques are ignored (just as you ignore their existence)
• soft skills are not taken into account at all (after all, the testing mindset is not even a thing)

Once you have a candidate to talk with, let’s follow with the interview. (Please, take into account that, should a candidate have passed your first filter, they might be either a not really good tester or a great tester willing to test your recruitment process.)
At this point, make sure:

• the applicant is interviewed by someone who knows nothing about testing (this is actually a win-win —or maybe lose-lose?— strategy, since both parties can easily convince each other they are the best option to choose)
• the term manual is used to diminish “not automated testing”* (as though testing could be performed using our hands more than our brain)
• the candidate is encouraged to showcase how many programming languages and frameworks they know
• the conversation only focuses on “automated testing”* (the moment the candidate mentions things like exploratory testing, testing techniques or testing mindset, you know you don’t want this person: how do they dare to test your recruiting process?)

Once you have selected your candidate, let’s make them work for you. (Please, take into account that, should a candidate have passed also your second filter, they might still be either a not really good tester or a great tester —and actor— willing to test both your recruitment process and your work environment.)
At this (extremely sensitive) point, make sure:

• this employee understands their goal is to automate all the (really bad) test cases you already have, since you want to responsibly take advantage of something ruthlessly written in the past by someone with no testing skills
• any conversation with this employee constantly focuses on “automated testing”* (the moment the tester mentions things like exploratory testing, testing techniques or testing mindset, you know you need to fire this person as soon as possible: how did they dare to test both your recruiting process and your work environment? Anyway, let’s wait until they automate all the test cases…)
• any suggestion made by this employee in order to improve the software development process and the related testing activities is coldly rejected
• any attempt to change something in your test strategy is automatically dismissed —it doesn’t matter you know almost nothing about testing: after all, as you are the boss, the test strategy is up to you
• any effort to educate you and the rest of the team about testing is strongly resisted

Last but not least, remember that, at any point, you can always play the wildcard: “You know what? This tester is not what we wanted. Let’s fire them and start again with the recruitment process…”

(*) By the way, there’s not such a thing as “automated testing”. If you don’t believe me, ask Michael Bolton.

A cautionary note for the reader.
What’s more, in case you actually hired a not really good tester, now they might be automating your (really bad) test cases, just for the sake of making them run faster…