views:

547

answers:

5

I have to interview automation testers, with experience in commercial tools like QTP, Rational Functional tester, open source tools like Watir etc. What interview strategy should I have?

+1  A: 

You might consider a "hands on interview", i.e. set up a computer with the tools you are looking into and let the applicant perform some tests that you specify.

HS
+2  A: 

Ask them what benefits they provide, what things aren't the tools good at. If they are familiar with more than one then what are the differences, similarities, which one they prefer and why.

Ask them what they did using the tools. Keep asking specific questions about the work they did.

Tim
A: 

I found a list of 100 QTP questions here.

ryeguy
+5  A: 

Very good questions to start with are. (Please replace QTP with the software of your choice)

  1. What can I test with QTP, and what can't I test?
  2. When should I use QTP, and when should I not use QTP?
  3. At what stage of the project should I use QTP?
  4. What sort of problems can you encounter when using an automated testing tool?

They need to understand the limitations of the software they use. QTP is very good for regression testing, with a stable platform (GUI). If you're continually having to fix the tests because something fundamental has changed, it may not be worth implementing the tests.

As for their experience, concentrate on what they have done. I've interviewed testers for 'Expert' positions, who haven't actually used the software in question, but their CV implies that they have.

Their approach to automation is very important, just like it is with coding. A reuseable, understandable test suite is a lot more useful than a obscure, badly coded one.

  1. QTP is usually used for functional testing, for testing user interfaces, not for stress testing, unit testing, performance testing.
  2. You should only use QTP when the GUI is stable enough to support testing. If the application is not stable, then the rework for the tests outweighs the benefit to the team. Another example would be multiple platforms, if the GUI was similar enough that the scripts could be re-used.
  3. QTP is usually used for regression testing, or testing on a number of platforms. This usually means closer to the end of the project.
  4. Timing problems (QTP is quicker than a human, it may not wait for a combobox to be updated, whereas a human does), problems with data, a human tester can cope with slight differences in data, fragility of the process, you can't work around a problem like a human tester can.

The above are guidelines, I'm sure you can develop te conversation from there :-)

MatthieuF
That's weird.No hard questions. Only basic soft questions that have 100's of answer patterns on the web."Timing problems... problems with data... you can't work around a problem..." Surprise, surprise. Google about custom synchronization and data models.
Albert Gareev
yoosiba
@Albert The point about interviewing is that you want someone that can give you intelligent answers to soft questions. I agree that there should be some technical questions, but for me it's important that I think the guy is intelligent and fits in with the team. I really dislike attending interviews where they expect me to know every last detail. I much prefer to have someone on my team who knows how to find things out. Things change so quickly with technology that you can't know everything.
MatthieuF
@yoosiba I wouldn't ask about arguments of a method. Answering won't proof you know programming. Can you develop an algorithm? What about sorting a matrix based on given requirements? How you'd refactor your code? Communicate a bug? Fix it? Report on fix?However, programming skills are not everything. That's merely a half. Other hard questions to be asked are about GUI recognition, Test Flow design and implementation.
Albert Gareev
@MatthieuF You put it really classy here in comment. And yet there could be plenty of hard questions that require intelligent answers and can not be pre-memorized. Ability of finding things out matters only in combination with ability getting things done. And you might be expected to know (i.e. have a solid experience with) because a Client doesn't have a luxury waiting for you to learn and master certain technology. They want to be sure you have done it in the past, and you succeeded already.
Albert Gareev
@Albert completely agree.
MatthieuF
+1  A: 

I feel you also need to ask about

  1. the methodology he used while
    testing, like Data driven, keyword driven
  2. Whether there was a framework ;if yes, the features of the tool that were sacrificed inorder to be compliant to the framework standards.
  3. Advantages of using a framework
  4. Automation test strategy.