Lately the demand for automation testers is high compared to the demand of functional testers. Most of the time, a company only wants to have someone technical so they can automate their testing. So they ignore the fact that functional tester might not be needed since everyone can test (that is what they think or assume). And sometimes they just think that the tester can do both, which are testing their application at the same time as increasing their automation testing coverage.

I think the interviewer needs to know which kind of tester they want and focus on getting the tester with the right speciality. There are several different goals:

1. Your application is in the end of the development phase and there are sometimes new feature requests or bug-fixes. So it is needed to do some regression tests after each new implementation of a feature or a bug-fix.
2. Your application is a work in progress and still has long way to go to actually be a the end state. In other words, features implemented can change a lot of times till the end product. So you want someone to challenge your application and find obvious bugs and unknown bugs so that you have a bigger level of confidence in the application.
3. Your application is a work in progress and you need someone to automate the regression test so there is no need to have a elaborate manual regression tester for any features that have been implemented in the past.

So which one is your current situation and which one is your desired goal?

If you are in the first situation then go ahead, find someone that can automate the regression tests. He or she does not have to be a tester as long as he or she knows automation tools. It means that there are several regression test cases so the automation engineer can just pick it up and create script for it.

If you are in the second situation then you need a specialized tester. Someone that can really challenge your application from different perspectives. Someone that can question your user stories. Someone that can break your application. Trust me, finding a good tester is much more difficult than finding an automation test engineer.

If you are in the third situation then…dude seriously…get two people. One for the functional testing, requirement analysis, and some other type of testing and another one for the automation part. If you only hire one person then don’t expect much about the amount of coverage for your automation testing or the confidence level in your application. You need to sacrifice one of them. She or he is not a super(wo)man.

It will be useless if you ask someone that has knowledge of automation tools but they are not good in testing itself or even they think they have the knowledge but they don’t actually have it. Some people think testing is just following requirements and clicking stuff and some people think that if they have ISTQB or TMap Certification then they are eligible to know what testing is. And why it is important to know what testing is? Well you can read about it in my blogpost here.

Several times I have seen good candidates being rejected from hiring just because they don’t know about Robot Framework or Python or Protractor or TestNG or any other testing tools even though they have some (adequate) technical understanding. What I consider a good candidate is someone who knows what the actual testing is (not just the tools) and someone who knows how to proceed with it.

So in my opinion, it is non-sense if you just curious about his or her automation skill and even non-sense if you just ask for a particular specific automation framework. In my opinion, if someone knows how to work with Protractor or Cucumber, they will also be able to work with other framework such as Robot Framework or TestNG or others.

Thus, if you want to have bug-free (minimum bug) product then find a good tester, but if you want to accommodate Devops then find automation test engineer. If you want to accommodate Agile, please get two testers (especially if it is more than 5 developers and 2 week sprints).

 

Happy Testing!