Q: How do I identify fake selenium testers?
I generally pair with people.
I want to understand the level of their expertise so that I know where on the team they can add value and how much support they will need.
I choose the following common tasks that I would expect them to do on the real job:
- review parts of the actual application under test and tell me in general terms how they would automate it, which areas of the application seem risk (or harder) to automate than others, and why
- build CSS selectors (or XPath) to locate elements of the application, we can test these from the dev tools with the Find functionality in the DOM view
- review actual test code for existing @Test methods and the abstraction layers and identify what looks good, what could be improved bad, where the risks are in the code.
- add some synchronisation code to an existing @Test method to make it more robust and then explain how to abstract that synchronisation so it doesn’t have to be copy and pasted into each @Test
- create some simple @Test methods for part of the application and then refactor it into a simple abstraction layer - whatever they choose it to be.
When you work through this you will see which parts they find easy - then you can quickly move on to the next activity, and you can learn what questions they ask and how familiar they are with the dev tools and libraries.
The only way to be sure is to actually see the person do the activity. And for the person doing the interview to evaluate them correctly, the interviewer also needs to know how to do the activity.