What hiring managers want (QA Edition)
For those of you who know me and my opinion about those two letters joined together, fear not, I haven’t turned to the Jedi side or anything similar. It’s an honest clickbait attempt. You’re welcome.
I’ve been drawing a few conclusions from my personal experience with regards to a topic very familiar to hiring managers/product leads in tech teams: hiring/sourcing for Testers.
The premise being:
- some “product people/hiring managers” don’t know what they want to hire;
- some others want to hire a “QA” (bleh!);
- And some others want to hire a Tester.
The “product people” that want or feel the need for Testers in their teams, I would say, have a better chance to be a step ahead already of many other colleagues: it might be the case that they want Testers, implicitly knowing somewhat the difference of Testing as opposed to Quality Assurance or Quality Control.
A part of people can indeed be on the lookout for a “QA” professional - someone who, by the book is probably a very senior and experienced Programmer/Architect/Manager/Tester (one or two of the previous) - whom has the implicit power and knowledge to set up better design practices and/or procedures into the development processes, and then ways of checking and evaluating those against a few relevant expectations.
But for you that are reading, that may or may not know this difference already, and you tell yourself “I want a Manual QA” or “I want an Automated QA” … I’ll commit the feat of trying to guess something (which may or may not hold for your case):
What you want is a Tester. The Tester you want does not exist. But the Tester you need is out there.
And yes, I can say this with as much biased confidence as any logical fallacy: because I’ve “been there” so many times, and the “same ice cream flavor is always the same”.
Why? Well, one reason could be that technology degrades and we need more than ever someone whose part of their job is to hunt for “degradation” (usually testers). But the main reason is we’re not out of the woods yet - typical software projects are getting more complex, dumb, big, and rushed - and for the most part, the super hardcore “flow/tempo” usually means bugs, risks, shame, limitations… always right there on the first corner waiting for you. Ready to hit you with a towel.
So unlike my usual “rant” posts (I sure do enjoy ranting) - I’m going to make this one a bit different. I’ll still rant, but, I’ll assume you, the reader, are already magically convinced about the “QA professional” being different from a Tester. Maybe because you feel intimidated by my previously “dogmatic fallaciously confident guessing” attempt. Maybe you’ve watched my video about it. Or maybe you’re just curious to see what gibberish I wrote this time.
Being convinced of the difference, it suddenly might dawn on you: so… If what I want to hire is a Tester… what should I try to identify in a Tester, so I can check if maybe it’s a promising candidate to join my team?
What “Agile Scrum Delivery Product Owner Managers Inc.” want
Here’s what most hardcore modern projects nowadays need on a high-level (assuming they may or may not already have craftsman developers that have a strong culture of “testing” their stuff, coding away plenty of insightful automated checks, and providing a proper hunting adventure for craftsman testers), a Tester that can:
- Test without any supervision or guidance in an exploratory and hands-on experiential way anything (be it an API, a web application (front office and back office) on desktop or the browser in the phone, a messaging system, etc), and still find worthwhile bugs, risk, and confusion;
- Conduct testing efforts both in a rapid but at the same time efficient and resourceful enough approach, making plenty with very little, hunting down for the most crucial bugs and risks in the time they’re given… like a special forces tester;
- Provide meaningful evidence of testing, be it humane summaries of the testing efforts and risks for a release, or even a “no bullshit” straightforward approach to bug reports with important information for developers and product people;
- Interact with programmers and code (participating in code reviews, bug fixes, unit checks, code coverage, code quality tools, etc.);
- Is not afraid of going the extra mile – debugging issues/bugs, not conforming only on what is “apparent” but with the guts to look into logs, documentation, the code, the deployment, and monitoring related tools;
- Is not afraid to own a deployment/release process (if needed);
- (Optional) Can code and maintain scripts for plenty of different tasks, and also code automated checks and maybe code decent sanity or regression check suites for an API or a frontend application – with little supervision;
- Is combative, and not afraid to say the truth and signals problems in a critical but constructive way;
- Has a short-fuse bull$%&t detector, that will measure up to 3.6 in usual cases of absurdity.
- …
It’s not easy to find a profile on the market that is 100% on each of the above points. I’m personally way, way far from even getting to a point where I can say I’m decent at some of these. But, any good testers have their strengths in some of these, while being decent or promising on any other points they’re not good at of the previous list.
Maybe some of these are very idealistic or area focused. Sure enough, I’ll admit that someone may not know how to code at all, but that still won’t stop the person from trying to read code - reading code can be scary - but it’s not a forbidden art reserved for some. I’d encourage any non-coder to tag-team along with a coder any day of the week. Plus, if you know your way around tools that help you test, I would say you can go your whole life being a valuable tester without having ever needed to do extensive coding.
On the other hand: I would uphold the feeling from experience that testers that will not cause an impact in hardcore projects, at least an essential impact - typically suffer from not being able to take care of most, if any, of the above points.
When someone wants the above but the Extreme Perfect version
If you’re one of the 2 or 3 people in the world that has found this post and you want to hire a version of the Tester posted above, but the Extreme version, or the “Perfect” Tester, meaning you’re willing to go, not the extra mile, but the extra lightyear (which is a sort of head-hunting /talent-hunting I’ve never seen happening online publicly)… what do you do in that case? Well, this is what you may want to search if you’re on that quest:
- A Tester with decent/good command of the points mentioned before, plus…
- One that can play ball on these topics: Epistemology, Risk Analysis, Exploratory process, Sociology, Coaching, Usability, …
Here’s a downside: Let’s say I know personally and on contact-level, about 800 Testers. That would be like my “first-level” and “second-level” network. I can tell you that of that network, I know of only about 3 or 4 testers who are this Extreme version (and I’m certainly not one of them yet).
Here’s another, lesser-known downside, if you’re willing to live with it: such Testers usually have an abnormal or unusual level of integrity towards the craft of Testing to a point where they become “Sensei”-of-reference to some communities and at the same time “offensive/censored” in other communities. So, consider if you are willing to fall into condemnation by any sort of warriors on any side, independent of who’s right or wrong?
Extreme Testers are not readily available in the market to test (dumb) “latest tech <insert-business-here>
”, or to cover up for poor product and tech decisions, without necessarily solving them and run the risk of offending someone. Usually, testers like these are in the market of consulting and coaching and educating other testers.
So my advice: instead of even trying to hire one of them internally, and get a “Nope. Thanks.” reply:
- either don’t try to hire the “Perfect Tester”, since you’ll most likely get a fake, or…
- see if there’s any way you can, on the other hand, hire a decent/good tester, and then have that tester become an apprentice of an Extreme Tester. That way you may get all the good, without the flagellation of trying to find perfection.
When someone wants something specific
“What I really want is a Mobile or AI/ML or 3D or videogames
kind of tester!"
I see this pattern online where people sometimes think the Tester they need has to be an expert in a very specific topic. It might be the case. But I’d suggest being open to the idea that your specific complexity might not be that unattainable or impossible for any craftsman software tester coming from another context. If on the other hand, you’re sure you need someone specific, here’s a few things then I can recommend from experience:
- Check for curiousness: besides the expertise in the specific context, curiousness should be a solid foundational trait. If you have an expert for testing a specific limited area, it might just be the case that that tester will not be self-driven to approach testing problems that go outside of his normal operation reach - which means there’s a high chance some unknown parallel risks will never see the light of day, until surprising the project from out of nowhere. Or if by chance, the project area shifts dramatically - you might end up with a tester that neither fits or will be curious enough to adapt to the new context.
- Check for abstract thinking: plenty of the concepts we have to live with while say, being a “mobile tester”, are not that different if we switch areas. The problem being, are we able (or not) to maneuver abstractions of our area and other areas?
There are more points, but think of it this way: if you only check for “specifics” when trying to find a new “specific-area” tester, you’ll soon realize that you’ve hired someone who is no different than say, the typical Frontend/Android/iOS kind of developer who doesn’t know how to debug a failing CI job, or a failing API call, or failing cluster/infrastructure issue and check any kind of logs on backend systems. And the story is the same for any Backend developer on the other hand that only stays in a Backend area of operation and has zero understanding of the impact of their changes on any user-facing area.
My point being: if you’re an engineer or tester in software, sure, I admit you might not know the specifics or the lingo of anything outside your area, but you’re paying a disservice to yourself and the project if you’re not curious enough or capable of abstracting yourself from your area’s “specifics” if needed. And “if needed” is not when there’s no one else around to “do it” for you.
Sure enough, for example, if I was hunting on the web for a mobile tester here’s what I’d look for, If I had first checked on what is posted on the list above:
- Usually Mobile centered Testers add that keyword (mobile) to their job title or their description;
- Of course, the dead giveaway is if they write Android/iOS plus they mention more mobile-centered languages like Objective-C, Swift or Kotlin. Mention of one of these mobile check automation frameworks is also a hint at being more focused on mobile: Appium, Espresso, UI automator, Xcode Test, EarlGrey, …
- Mention of these tools could also be an indicator of someone who delves into mobile testing often: Charles proxy, Fiddler Proxy, Browserstack App Automate, Xcode, Android studio, adb tools, AWS device farm, …
- …
And there’s more. For a more cross-functional Tester, I’d check for different clues, the tiny differences from mobile being that you’ll try to hunt in descriptions a bit more about things like:
- testing APIs (Postman, RestAssured, API based libraries and tools, …);
- testing web applications (and any of the typical programming languages plus check automation libraries);
- and in some good cases, performance/load testing with resource to tools (jMeter, Locust, Taurus, Gatling, Siege, k6.io, …);
- …
Wrapping up
Now, the following warning goes without saying, and also my main problem with hunting for keywords and tiny clues to try to map out a broad profile of the “specific” tester I’m hunting down for: anyone can write any keywords they want on a resume or their online profiles and that still won’t mean anything practically. I’ve had to lead testers who never in their lives had “performance testing” keywords in their profiles to conduct on their own performance testing, meaning I had to teach some things, and they had to learn on their own some other things, but it was never a piece rocket science or some arcane wisdom. It’s never a meaningful problem. Usually it only is a problem, on the contrary, if people who have minimal understanding of what testing really is, still hold some things as “guru-level” knowledge bits that only gurus of some specific baloney would know, and then the same people raise noise about these things they don’t know (and often don’t want to know even after multiple patient explanations).
It didn’t practically make a difference if the keyword was in that tester’s resume or not in the first place. In my experience, and what I believe makes the difference every single time, is if the tester is passionate about learning, investigating, playing, deducing… So do yourself a favor, if you’re hiring a tester:
Don’t worry about specifics if there’s not a meaningful reason to worry about specifics … or you may just end up getting the “QA” you deserve and not the one you need.
Feel free to reach out to me with comments, ideas, and suggestions via any of my social media, or by email, which you can find in my Github account. Until next time, take care!