I run a software development company, I am considering hiring a QA person, what are the traits I should look for in a candiate? And what are the traits I should avoid? (extra credit for how you can test for these traits)
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
I'm a workmanlike Tester who's had the good fortune to work with some excellent people over the years. When I hire people, there are some key characteristics I look for:
Eye for detail
This is the obvious one. Testers need to be able to see the little details that others miss. You know those Facebook questions? The ones that go:
Spot the mitsake : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
A good tester will see these right away.
Knowing how to test
A tester will need to be able how to quickly determine how to efficiently test a range of new services and products.
During an interview, I'd pass the candidate a fountain pen and say "Test this". More importantly than their answers would be how quickly they stepped up to the task and started to disassemble its function and construction.
Dealing with conflict
If you're lucky, a tester will be constantly finding ways to improve your product. Part of this task is to go to a Development team and to tell them that they've made mistakes. If this isn't handled appropriately, it can lead to problems down the line.
In the same interview, I'd hand the candidate a piece of paper with a logic puzzle on it and say "How would you improve this question?". The logic puzzle would be a standard one but it'd be worded badly, would have typos and layout issues.
This is one that I've learned the hard way. The interviewee would need to demonstrate that they knew how to structure their testing efficiently to target the high risk and/or value areas of a product.
I'd give the candidate the description of a large project with a few problem areas (high volume areas, ones that have been announced in the press and one with new developers) and ask them to sketch out the first few weeks' work.
Knowing when to stand up
Sometimes a tester will be given something impossible to do. I try to hire people who are willing to say "no" to me, to challenge when they think something is unreasonable. For this, I use the simplest question of all.
"The development team have written a new integrated communication service covering e-mail, text chat, file storage and file transfer. We will be demonstrating this at a conference next week. How would you approach this project?"
If they don't say "Advise that the time scales are too short", they lose marks. :)
Just as you would for any other role in your software development company, you decide what you want the new hire to be able to do, then seek people qualified to fulfill that role.
If you already know that you want to hire a "QA person", then you must have some sort of idea about what this QA person will do?
There are no magic traits/questions here, just as there is no magic for other software roles. There's no trick to hiring, just hard work.
Look for a candidate that is technically capable of filling the role you have in mind. And look for someone who would be excited to fill that role for an extended period of time.
If neither you nor anyone in your group has any experience working with professional QAers, you should talk with people who do. This will help you hone your job description, and help clarify what it is you will expect from your QA person.
These might help: http://strazzere.blogspot.com/2010/04/what-do-qaers-and-testers-do.html http://strazzere.blogspot.com/2010/04/testers-and-developers-at-fog-creek.html http://strazzere.blogspot.com/2010/05/slideshow-optimistic-developers.html http://strazzere.blogspot.com/2010/04/optimistic-developers-pessimistic.html
This is going to sound crazy, but... it depends.
What you want from a tester who will be doing a whole lot of routine, pre-defined tests (one hopes this isn't the case, but sometimes it is necessary) manually isn't what you want from a tester who's going to need to handle a highly dynamic system.
Assuming you're looking for someone who will be good with the latter, I'd suggest you look for puzzle/problem-solving experience (and ways to test this are many and varied, including pointing them at a website with known problems and getting them to report what they see as the killer bugs after some set time testing it. That gives you a quick-and-dirty thumbnail on the person's ability to prioritize bugs as well as their ability to find them. (I wouldn't put more stock in this one than 'quick and dirty', because interviews are high-stress situations and not everyone does their best at this kind of challenge when they're stressing over whether or not they'll do well in the interview).
Then you can ask them how they'd communicate the problems they found. That gives you a thumbnail on whether or not the applicant is going end up being seen as a valued team member or a bloody nuisance by your developers.
The next test of the tester I'd suggest is to give them some generic software design documents with known problems, give them time to examine the documentation, then ask them what they think. Here you've got an honesty test (in that you probably don't want someone who will try to give you the response they think you want), a tact test (can they tell you it stinks in a way that doesn't make it sound like a criticism), and you can see if they're good at picking out gaps (In my not at all humble opinion, picking out gaps in a specification is a critical skill for a good tester - because no-one wants those gaps to find their way to production). This is really more of a filter between the good and the not-so-good, and between the most adaptable and least adaptable. Someone who's very good but slow to adapt may not find the gaps, where someone who's a bit faster to handle new material probably will.
All of these are thumbnail suggestions to get a quick impression of how your applicant performs at some key tester-like activities. They don't substitute for experience or know-how, but they can be a useful supplement. Again, my opinion only, not to be taken as the Infallible Truth.
I hope this gives you some ideas.
You should be getting the tester to "think like a tester'. The way I like to do this is to give them a scenario and then have them come up with test cases for how they would test something.
If you want some examples, Trish Khoo and I covered this topic at length in this episode of our testing podcast ... http://www.testcast.net/archives/show-03-do-i-get-the-job/