I would like to know that if I want to represent myself as a good functional tester then in that case what points do I consider telling the recruiter? Because last time I had this interview and i got a feedback that I was very good and enthusiastic but they got a person who was technically more sound!
I recently hired on with a new company and wondered about this as well. After speaking with my former and current supervisors, I got the following advice and followed it.
- Know what you're talking about. Assuming the person interviewing you is a Test Manager or experienced tester, they know what they are looking for. They're ears will be open for key words and your ability to explain concepts and definitions. That's not to say that you have to know everything, but you should be able to explain concepts of testing based on your experience.
- Keep in mind, not all testing jargon and processes are the same across companies In my interviews, I recognized this, and simply stated, "In my experience . . .,". Any experience hiring manager will know that things are different across companies and won't judge your testing skills simply based on the fact that they don't line up with what their company does.
- Be honest I found this to be an ice breaker as well. If the person asked something about something I wasn't experienced in, I didn't stumble around and try to make up an answer. I said I didn't know. But, if I could, I would add in how I had contributed to something. For example, as a functional tester, you may not have actually written the use case which was used for your test script, but maybe you were involved in the design sessions. You want to show, in as much as you can be honest, that you may not know specifics, but you have a good solid idea on the process.
- Ask hard questions to the interviewer Asking them questions which may put them on the spot (how do manage tight deadlines? how do you cope with stressful situations? etc.) are uncommon and show you really care about the work and the environment.
- Don't be afraid to say "let me think about that". Although there will be silence, it lets you calm down and really think about what you do and do not know and formulate a solid answer. This also shows them you're not hasty.
That's what helped me. Freshen up on your skills and learn from each interview.
The best way to do this is practice functional testing and master the art. Once you do that you won't need to find back door answers to such stuff. Never try to pose yourself in an interview that you are not, because sooner or later you will get caught and that will affect your job. Learn the art and practice it so well that any question thrown at you on the topic, you will have at least a line or 2 to say!
Often in interviews, I'm asked "how would you test x, y, z?" and while I didn't plan it, I found myself giving a pretty stock answer each time. I'll start off saying something like this: "It depends - on the features, the requirements, the timeline, and any other relevant factors."
And then I'll start laying out specific examples. A web page that changes frequently could get by with manual functionality checks, backed by good production reporting and tracking of errors. A payment REST API is going to want comprehensive parameter checks and injecting various kinds of faults - confident, consistent results are important there.
At some point I'll start talking about driving architectural changes to help test, like using an MVC pattern to make business logic more testable. I also ask about their implementations and testing.
If you can comfortably get through all of that, then you're having a good discussion, you're colleagues, and in general its safe to allow the interview to go organically after that.
Getting a series of detailed technical questions and/or challenges can make this approach difficult to get started - all you can do there is be as educated as possible and hope your knowledge matches their questions. Fortunately this type of question seems to be going out of style.
Good Inputs Niels. Adding few more pointers
- Highlight your expertise in functional expertise in terms of bugs identified, tools used. Example - Web Service / UI / DB Testing using Tools (Open Source, Commercial), Custom Code
- Attempt to solve any problem / test scenario provided during interview. Co-relate this with your past learnings / ask questions when unclear
- Highlight your blog / personal notes. Learning is a continuous process. If you bookmark your learning's and share them. Some of your learning's might actually help you indirectly
- Before the interview, Build a good reputation. Your resume should highlight your exposure in terms of tools, projects, domains worked. Always look forward to expand your skills by continuous learnings / trainings
- Linkedin meaningful recommendations with specific instances / examples will also help people understand about your execution skills
- If you have passion for your job, you will not work within boundaries. Many times you may have worked in production to troubleshoot issues, identify performance bottleneck issues, Explain these instances to demonstrate your learning's in new areas, working across domains etc. I'm not promoting selling here, I am only referring to be aware of things you have done. Proving yourself in a Interview is not until your are selected but also proving you are a Good Hire
One of the first, and most important, questions that I would ask the interviewer is what level of testing the project/organisation has specified on the specific project that the interview is for and/or in general. If the project is a purely commercial utility then they will require quite a different approach to one that is safety critical and highly controlled. This also determines the "correct" answer to the question "What would you do if the software under tests fails one or more tests and your project manager asks you to disable those tests" - for a commercial utility that may be allowed if you are picking up extreme corner cases but for a safety critical project you should be ready to stick to your guns. I personally have many times faced this sort of pressure and never regretted digging my heels in and explaining why.
The real answer of course is to show that you really do know what you are talking about, care about what you are doing and can be worked with.
From my personal point of you, I expect the testers have in mind to deliver a service. The aim is to support development to improve the quality of their work.
Now, technical skills are for me the way to make testing more efficient:
- Technical skills will help for test automation. While tests are running testers are busy to increase the test scope.
- Thanks to the technical skills, it is possible to make the bridge between development activities and test activities. It improves a lot the communication and give autonomy to the testers
The most important is to have few technical skills which will make you more efficient. For example about tools: Selenium, SoapUI or JMetter, basic knowledge about Unix (all the time useful to check logs), a bit of SQL, programming as JAVA, Bash would be great but it starts to be more technical for functional people. Have nice knowledge in MS Excel for some analysis or reporting may be useful to be more efficient; Yes it is.