Is there any well-defined process to be followed in evaluating a candidate for manual testing?
A list of basic testing questions (Why do we test? When do you stop testing? What is regression testing) would be useful for ensuring candidates have the right skills or mindset for testing... but you may get more value from asking questions about themselves to figure out how well they'd fit within the team, company, and culture.
If they're new to testing, ask; Why would you enjoy testing? Can you tell me why testing is important? What do you do in your spare time?
If they're experienced, ask; How do you keep up with technology? What are your goals or aspirations? What do you do in your spare time?
I've always interviewed the person and not their experience - because you can teach them new skills, but you can't teach them personality.
One of the most commonly asked interview questions is 'Why did you choose to be a QA/Tester? Why not a developer?' And if you answer with 'I am not interested in coding/Not able to code' may land you a rejection. Automation is as much important part of QA as Manual Testing and other processes. If you are not interested in coding/cannot code, this gives an impression that you are not even willing to try to learn code, which employers do not envy. Even if are not able to code, convey to the interviewer that you are willing to learn automation if required.
The other questions may be-
- What is regression testing?
- What are SDLC and STLC??
- What is bug life cycle?
- Difference between issue, bug, error, and fault?
They might also give you some real-life cases and might ask to write testing scenarios.
You could ask, "How would you test a soda machine or other common appliance?" This is an open-ended question that looks at their approach to testing. You can judge the candidates approach to requirements definition (Is it a soda fountain or a vending machine?), workflow breakdown (Assuming it's a vending machine, payment -> selection -> receive product), exception handling at various points, esoteric requirements that aren't visible to the end-user (can the owner change things in order to distribute water in oddly shaped bottles but soda in uniform cans? Advertising panels?), handling bugs, and many other aspects of testing and QA. The idea is to use something that is common enough in everyday life that the candidate will know how to use.
I would take two public facing applications like Facebook & Amazon and will ask the candidate to design test strategy(with few sample test cases) for both applications based on his knowledge as an end user of them.
I will try to figure out what and where he finds them different from testing perspective and how will that affect the overall test strategies that will give me an perspective on his overall understanding & maturity in QA.
This question alone with follow-ups may suffice for an complete interview.