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)
Tell me more
×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for
software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.
|
|
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/ |
|||
|
|
