What interview questions should a developer ask a tester?

Question

We have some interviews coming up whereby we're recruiting for a quality assurance role. The purpose of developers being involved is to understand whether hte person will work well with the development team.

What are the most important question(s) a developer should ask a QA person? I'm looking for practical questions more than fluffy open questions, your thoughts?

Answer 1

Unfortunately, sometimes, the fluffy open questions are the ones that give you the best view of a person.

Whatever technical questions you ask (and these depend a lot on your development methodology so I can't really help you there, they should be tailored), you should always establish how the potential candidate will work in a team environment.

You need to establish that:

• the person will work well in the team.
• the person will take responsibility for working with development to get bugs fixed, not just "Here's a bug, go fix it, then get back to me".
• the person's ego will not get in the way of the team's work (such as fighting over the classification or severity of bugs). I find this is usually more of a problem with developers getting defensive about "their" code.

I find the best approach in interviews is to present scenarios and ask the candidate what they think, for example:

• it's 4pm Friday afternoon and Bob, a developer, has agreed to work back to fix a high-severity bug. We need a tester to validate the fix and you're the only one available but you had a dinner arrangement. What would you propose?

Just on the answer to that question alone, you could evaluate whether the candidate:

• is useless ("Sorry, I can't miss dinner").
• thinks outside constraints ("Are there really no other testers available?", "Can I validate it on Saturday morning?", "Can Bob work some other time on the weekend?").
• is adaptable ("I could put off dinner just this once").

and so on.

I cannot stress also how communication skills are important to the developer/tester relationship. Have the tester generate a rough bug report (any bug they want to) and discuss its adequacy (exact steps, expected behavior, actual behavior, ...).

Answer 2

Some of the key items that we look for in software quality people:

• communication - can the candidate write/email/speak in a clear and concise fashion so that other members of the team can understand the defect they have uncovered
• problem solving - Here is where those interview puzzle questions come in handy. With these types of questions, its more important to learn how a candidate will attack a problem versus how close they come to determining "how many blue cars are in the US".
• responsibility - It is important to understand whether or not the candidate will follow through. This one is trickier to find the true answer for since people are enthusiastic during interviews and may agree to a lot, but not really mean it. Past stories from the candidate about how they handled a problem or issue may be helpful. Bonus points if the issue got worse for the candidate and they stayed on top of it.
• technical expertise - The required level for this item will vary depending on the tester: will they be writing automated tests? Manual testing? Automated tests require at least some degree of technical expertise while manual testing would require less. Either way, having a tester that is at least familiar with the technical aspects of an application can be very useful when it comes to working on an issue.

Answer 3

I think this really depends on the sort of tester you are looking for. Are you looking for someone to push the buttons and tell you it doesn't look right or are you looking for someone who can understand the technology or even the code and find the deeper bugs? As a developer on the interview loop I would imagine there are traditional QA types also available. If so, they'll ask the typical test questions. You need to get at how technical they are and how they'll interact. With that in mind, try some of these sort of questions:

1. Programming questions. Look at the resume. Do they know C#? Javascript? Ask them to code something for you. The more they know, the better the bugs they'll be able to file.
2. Process questions. Do they understand source control? Have they used it? Do they get the concept of a build? Are they familiar with unit testing?
3. Software development questions. Do they understand what a dll/assembly/jar is? Do they know how memory works? Do they understand the difference between user and kernel mode (or whatever is appropriate to your domain)?
4. Technology questions. How well do they understand your domain? Do they understand what motivates the widget industry? Do they know what widget customers are looking for? Have they ever used a widget?
5. Do they understand their bugs at a deep level? Ask about their favorite bug. How much detail can they tell you about what went wrong?
6. Can they stand up to you? Is this the sort or tester that will back down when dev pushes on them or will they fight? Ask them about a time they tried to get something done and met opposition. How did they react?

Answer 4

A developer can check by giving him a scenario which should check the following

Attitude

Do the tester posses a probing attitude? Give him a scenario and check how many valid question is he/she asking?

Skills

Several skills related to testing are required in each project that you work in. it includes requirement study, test design, test execution and so on. Check how good is the tester in understanding the requirement.

Knowledge

Check the breadth and depth of the tester in the field where you are going to recruit the tester. Even if the tester is not working on the current field, check how much does the tester know about that field.

Approachability

Give the tester a scenario like there is a client issue and the developer is on leave for the entire week. The issue needs to be escalated urgently and as a tester it came to you to find the root cause of the problem. How will you approach in such a situation

Answer 5

Apart from the deeper answers in this thread, there is a simple question that often gets overlooked:

Can you act like a normal, or non-experienced user?

Now, this seems silly, but it gives a very good insight. If the candidate says yes, quite frankly, they're not what they appear to be. No person who works in the field of Information Technology in a development (in particular), analysis or test role can do this; simply for the fact that we are way past the level of an inexperienced user. The answer you should then look for is:

No, however I can create test cases that can accurately map to a "so-called" normal users behavior.

Or a derivitive of this. This shows some important information.

1. They are realistic
2. They can think outside the box
3. They are willing to perform the proper methods set upon in QA

This is what I have found at least.

Hope this helps in one way or another.

Answer 6

My suggestion would be to consider somewhat open-ended questions like this:

If I walked up to you and said, "Could you test this new thing I did?" what would your first few questions be?

Here are a few thoughts I'd have in asking that:

1. Is there mention of specifications or requirements? If there aren't any, how does that impact testing?
2. Do they want me to pair with them so they can know what I did?
3. Do they want to know what I did?
4. Do they have time to do this and ask how long I think this may take?
5. What kind of testing are you expecting: Comprehensive, smoke test, hallway usability?
6. What kinds of tools will be used to do this?

In recording a bug, what is the minimum information you believe a developer should have before fixing it?

This is the type of question where depending on what kind of background they have will likely be a factor in their answer as a few things to note would include the following:

• Reproducibility - Can you get this in a predictable way?
• Steps of reproducibility
• Is this a code, data, network or other type of bug?
• How bad is the bug on some scale?
• Environment - what do I need to make this happen again? Are there specific browsers, operating systems or other things I should have?
• What is the expected and actual results that illustrate that this is a bug?
• Software version - This was found on what build of the system?

I mention most of these because that is what I'd be thinking in asking that in terms of what parameters do they initially have when given a vague question or request that should have more details but which details matter is the rub. I'd also note how long of a pause was taken at giving an answer where I'd say 15-30 seconds is OK, anything less and I'd think it was an anticipated question and if more than that is needed then there should be a request for a couple minutes to think about it, as the whole point is that when this situation arises what is the expectation on each side?

Another idea would be to mention what software development methodology you use and then ask what challenges are there related to QA with using this approach? For example, if developers use TDD how does that impact QA? What if it is a more waterfall-like approach? What you want to see here is how well can they think on their feet as well as what kinds of follow-up questions about what is used are asked as really if I say we use Scrum, how well does that define the implementation of the general concepts of Scrum, really.