Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We're hiring a QA person and I am supposed to come up with some interview questions. The truth is, I don't know much about what a good QA engineer should know, much less what good interview questions might involve. Does anyone have suggestions?

Some information: The environment is two separate (but intertwined) web applications for the Microsoft stack (ASP.NET, SQL Server, IIS).

share|improve this question

closed as not constructive by MichaelT, Bart van Ingen Schenau, gnat, Dynamic, BЈовић May 4 '13 at 21:55

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

4 Answers

up vote 7 down vote accepted

Unless you have a lot of experience working with testers, read the first few chapters of Cem Kaner's "Testing Computer Software" to get a feel for the kinds of terms you want to hear: Boundary testing, error testing, happy path testing, functional, performance, security, integration, etc. If you can't speak the language, you won't be able to conduct a good interview.

Give them a spec for a small piece of your system. Ask them to test it. You are looking for organization of thought and their ability to come up with interesting tests. You want to see them break apart the areas of testing in an orderly way, and then drill down into each area, devising more and more interesting test cases. Really good testers can do this for hours with all but the most trivial problems, so you might need to cut them off and have them move on to another category to get a good feel for how they think.

Describe the behavior caused by a real bug in your system that was kind of hard to understand. Ask them what they would do if they saw this bug while testing. Here, you are looking for bug reduction - the ability to find the simplest set of circumstances that can reproduce a bug. This makes debugging much easier for devs, since they have a better guess about what caused the issue, and demonstrates a clear ability to problem solve and a clear understanding of what factors can interact to cause bugs. With your specific product, discussing a race condition might be fun.

Give them a simple command line program you hacked together (maybe seeded with bugs) and a simple spec, and let them sit down at the computer and play with it, with the goal of finding issues. Here you are looking for creativity and the ability to target trouble areas. They should test things like large inputs, small inputs, weird inputs, empty inputs. If they find a bug, ask them to try and figure out exactly when that bug happens (again with the bug reducing!).

Ask them what they would do if an SDE responds to a bug with "No Repro" or "Won't Fix", if they thought the bug is important. Here you are looking for someone who won't just be a pushover, but also won't be antagonistic. Reasonable responses include adding example scenarios that demonstrate more clearly the severity of the bug and then reopening the ticket, talking with the dev to try to understand why things were resolved this way before closing, etc.

Talk to them about your application at a high level. Ask them what kinds of testing they would want to perform. Here you are looking for general areas of testing like functional component testing, integration testing, performance testing, security testing.

If this is an SDET / automation engineer, give them some interview questions for devs with roughly 1/3rd to half their total years of experience.

If this is your first QA person, make sure they can self-start. Ask them what they imagine their first week to month of work to look like. They should say something about gathering requirements and setting up tools, then describe a reasonable approach to getting started on testing. You're looking for someone who doesn't need a boss to tell them how to start testing and can self-manage. If you already have QA staff, this is less important.

share|improve this answer
1  
And there's always the stereotypical MS test question . . . "How would you test this pen?" It's the SDET equivalent of, "Why is a manhole cover round?" –  Ethel Evans Feb 11 '11 at 18:06
    
+1 Great answer - especially including a test audition. Some folk sound great when they're talking, but the only way to really evaluate a tester is to actually get them to test. –  testerab Feb 12 '11 at 19:54
1  
Yeah . . . my first job out of college was landed because I was asked to sit down and test the calender app in Windows XP for 3 minutes, and I found an integration bug with MS Outlook. The person asking me to test made the mistake of letting me use his work machine, and apparently I managed to mess up his setup pretty badly :-p –  Ethel Evans Feb 14 '11 at 20:18
    
In your opinion, what about someone who's job is purely focused in test automation? ie: developers write their unit tests and their main focus is to automate and run those, generate reports, etc (more developing tools & systems, rather than manual testing or creating test cases). What should their specific responsibilities be and what would you expect of them from a QA perspective? What's the line between their responsibilities and those of the developers? –  K-RAN Jun 7 '13 at 1:02
1  
@K-RAN, the philosophy I like best for balancing dev and tester responsibilities for quality is "Devs start at the 1-foot level and testers start at the 10,000 foot level and they meet somewhere in the middle. If there are fewer testers, that somewhere will be higher up, maybe even at system integration; if there are more testers, that level will be lower, and maybe just right above unit tests." If you really are just looking for long-term tools and systems work - no expert opinion on quality of tests, actual testing, etc., then hire as if you were hiring a dev for that role. –  Ethel Evans Jun 13 '13 at 20:43
add comment

What I do when I've interviewed QA candidates is ask them to sketch out a test strategy for an application. I usually give them my phone and pick an app with limited features - or let them pick something they're more familiar with. When they list a high level strategy (some can't), I might ask them to drill down and list a few test cases.

Once done I might give them a scenario where we have limited resources and see how they prioritize.

I also ask them when software is good enough to ship, how to handle situations where PM or dev doesn't feel a bug is important but they do. Typical product development scenarios.

These are for non coding QA positions. Coding QA positions I give them a dev/test combo interview.

share|improve this answer
    
thank you for sharing your experience! –  kelloti Feb 10 '11 at 23:49
    
You're welcome. Good luck =) –  rreeverb Feb 10 '11 at 23:59
add comment

Ask them how they would design test plans. Ask them if they are experienced in using regression testing and how they did it if so. Ask them how they go about tesing a user interface. Ask them how they would go about testing data imports that don't go through the user interface (if you do such things). Ask them how they would communicate their issues to the developers and how they would check for resolution of the issue. I'd ask them about the most interesting (or hardest to find) bug they found and how they found it.

Before you start interviewing, look for some of the books out there on testing and bone up a bit on what a QA person should be doing. That will help you evalutae their answers.

Further you are also looking for a good personality fit. You don't want a QA person who is a pushover, but you don't want a bully or a jerk either. But you do want someone who will stand up to management when things are wrong and not just approve everything because management wants to meet a deadline. You want someone who will work with the developers effectively and who understands the requirements of what they are testing. Someone with some background in the type of application you are testing might be good. A tester with health care experience will know of things to test that someone coming from another field may not be aware of.

share|improve this answer
add comment

I guess you can't expect them to have any serious knowledge of technology - whoever has will most likely decline to work as a mundane tester.

The best you can do is to look for common things like attention to details, inquisitive mind, enthusiasm for experimentation and so on.

share|improve this answer
    
any favorite questions or specifics? –  kelloti Feb 10 '11 at 21:58
3  
This depends on where you live. I'm running into more and more developers moving to testing because of its unique challenges and better career prospects, but I'm in a very software-heavy area. Good testing is anything but mundane, and if you pay enough and have an environment that respects skilled testers as the equals of skilled developers, then you can get rock star testers who know their stuff. –  Ethel Evans Feb 10 '11 at 23:58
1  
That says rather a lot more about the kind of companies you've worked for than it does about testers in general. As Ethel says, you get what you expect - if you expect your testers to be mundane and pay accordingly, you simply won't attract really skilled testers. –  testerab Feb 12 '11 at 19:44
add comment

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