Take the 2-minute tour ×
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.

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)

share|improve this question
1  
    
Thanks, they are pretty good answers, especially the first one, just didn't come up in the list as I wrote out the question. –  Robin Vessey Jul 19 '11 at 1:32
7  
Note - in your job posting, you might not want to use "to QA" as a verb. Instead, use "to test". Candidates will like you for that. –  Joe Strazzere Jul 19 '11 at 20:11
    
As the answers you have already suggest, you could do with thinking carefully about what you're hiring a tester for. Have a look at redcanary.mypublicsquare.com/view/hiring-software and think about what sort of company you run, and what sort of tester would be a good fit for you. –  testerab Jul 21 '11 at 20:29
1  
Also note that you will get a much different application pool using QA Tester vs something like Software Development Engineer in Test (SDET or SDE in test). A QA Tester usually writes test cases and executes them manually or uses an automated test runner and has limited coding/software design skills. An SDE in Test would have the equivalent skills (and pay) of a full developer, but focuses on the ability of your system to be tested at all levels (test hooks, unit testing, functional, integration, performance, security, etc). –  Greg Bray Jul 25 '11 at 3:08
add comment

4 Answers 4

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.

share|improve this answer
add comment

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

share|improve this answer
    
The links are really good, thanks. –  Robin Vessey Jul 20 '11 at 1:01
    
Agreed - make sure you identify the holes in your team that can't be fixed by a process (instead of a person) & recruit to fill those holes. –  DuncN Jul 22 '11 at 21:40
add comment

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/

share|improve this answer
add comment

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.

Prioritisation

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. :)

share|improve this answer
    
I don't think the last test is right. A tester is not a manager, he should not have to deal with time issues. If the product is being released next week, well, so be it. –  l19 Jan 21 at 12:50
    
This all comes down to personal preference, I suppose. When I hire a tester, I want to find someone who will fight for product quality, who will speak up if they think it's necessary. I wouldn't want someone on my team who would sit passively and not challenge decisions that're going to lead to a poor quality product. If you have a strong management team, this level of awareness may not be necessary but I think it's better to assume the worst. (A true tester's mentality <g>) –  Dave M Jan 21 at 16:40
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.