How to avoid 3 common mistakes when hiring your first software tester
How to avoid 3 common mistakes when hiring your first software tester.
Save time & money by ducking these startup mistakes with testers.
We’ve all seen the hires that looking back make you cringe a little inside. How could we have not seen the reflags??
If only we knew what we know what, we could have avoided the headache.
I’ve been right there and this is particularly relevant when making your first software testing hire.
While there are a multitude of areas you should be looking at when making your first here (top three traits, laid out here), in this post I’m focusing only on three common mistakes that startups makes in their first hire.
1. Lack of CoSQ knowledge
CoSQ, or Cost of Software Quality, is a philosophy that software quality needs to be measured as a cost to your company. Good software quality systems can create efficiencies & poor can create drains.
It is tempting to hire a software tester that you think could hop right into your development cycle and start hammering away at those bugs. After all, that is the job correct?
At its core, software testing is about finding bugs, but your first hire will be responsible for putting in place the systems & tools for cost measurement that are needed to effectively track investment v. output.
Areas like time defining test plans, meetings with dev on findings, & the cost of bugs in production need to be reported, analyzed, and fixed.
If your first hire doesn’t have a basic understanding of this system, you’ll soon find your team working hard, but no with ability to understand if it is efficient.
It’s simple to screen for this during hire, simply ask about the system that the tester may have operated in the past. Did they have a role in designing it? Were they responsible for reporting?
2. Bad communication
Bad communication comes down to one of two causes. Either A. the tester genuinely doesn’t know what good communication looks like B. the tester is a tad lazy with the details and leaves the time hanging.
By nature, testers often are not the best at communication. Great testers often prefer computers over humans, prefer activities like excel over meetings, & in general at the most talkative bunch.
This doesn’t excuse poor communication.
If you have a tester that genuinely doesn’t have any idea how to communicate effectively with the rest of your startup team. I’d recommend you have the check out this article, how to communicate with your startup team.
Great ways of screening for this simple involve asking during the interview process. Lay out where a bug was found & some of the parameters of the test. Ask the candidate to provide you an example of how they would report the bug.
This should be second nature to any tester. Particularly in the interview process.
The second situation is often must harder to detect during the interview process and become a major pain. Lazy communication is a massive inefficiency.
A tester’s number one job is to isolate the cause of what might be creating the issue and then offer a very specific use case to the development team.
Yet, many testers as they become more comfortable start to slip when it comes to communication. The best way I have found to identify whether this is a tester’s weakness is to ask very specific questions related to communication during the reference checks. Listen for red flags or gaps that are not I’m 100% stunned by this tester’s communication.
3. Ability to pick up complex applications
There are many testers who are great at specific skillsets but struggle to pick up complex domain knowledge.
Many startups get intrigued by a stunning looking resume, only to be confused that the testers is taking months to understand your system.
First off, this could be emblematic that you have to work on the usability of the system, but just as often is the case this tester is great on paper but there is a reason they are applying for your job.
Just because the tester did work with Google, doesn’t mean that will be a good fit.
There are very easy ways to watch out for this. The first would be get the tester into your system before ever making the hire. Ask them to take actions that you would expect a basic customer service person to be able to pick up.
If you don’t feel comfortable using your own application, find a common online application that is free. Ask the tester to take certain actions in it.
Save yourself a ton of time & hassle & make this part of your interview process.