How do I identify fake Selenium testers?

There are things that can be done before the hiring interview, during the interview and after.


The tester gets a Java coding project from to be done in 30 minutes.

It does not have to be very difficult, even an easy one is good enough.

Such as finding all characters from an array that are duplicated.

Or checking if a sequence of ( and ) is well formed (each ( has a corresponding )).

The solution for this project should show if the tester understands the basics of Java and can write “easy to understand” code for a simple task.

If the solution is good, I ask for a GitHub repository (or a blog link) where the tester has sample Selenium automation code.

Looking at code that the tester wrote in the past shows you what code he may write in the future.

Good Selenium testers have sample code available for interviewing purposes so that they can prove before the interview how good they are.

When looking at sample code, I pay attention to
  • how the locators are designed
  • where are the locators stored (in the page classes, separate locator classes, property files)
  • if page object model is implemented
  • how page object model is implemented (to interact with the site’s features or to interact with HTML elements)
  • how short/long the page classes are
  • how many methods are in each page class
  • how easy to understand the test methods are
  • how long are the test methods
  • the automation framework’s layers
  • if utility classes are used as parent classes of the page classes (since utility classes are not following OOP principles)
  • if lots of static methods and variables are used (static and OOP are not going well together; also, static can be a problem for parallel execution)
  • if there are classes that implement functionality that already exists in the Selenium library (in other words, if the tester is interested in re-inventing the wheel)
  • how error handling is implemented
  • if there is duplicated code
  • if the code uses static delay


The phone interview is first.

This is an opportunity to understand how good the communication skills are.

And to assess more the programming skills by asking questions with different degrees of complexity.

The questions can be about the Selenium library and even more about Java.

Good Java knowledge is essential for good Selenium test automation.

This means much more than basic concepts since understanding of topics such as

  • polymorphism
  • interfaces
  • generics
  • predicates
  • annotations
  • streams
  • composition
  • code refactoring

is essential.

The in-person interview is next where the programming skills assessment continues.

I may show the tester some code samples and ask

  • what is correct
  • what is incorrect
  • what would he change and why


Finally, the practical test.

An end-to-end test needs to be automated with Java and Selenium WebDriver.

First, an automation framework should be created.

Second, the automation framework is used for the following end-to-end-test:
  1. open
  2. search for a keyword
  3. select a product that is available online
  4. add the product to the cart
  5. open the order basket
  6. choose to continue the checkout as a not-logged in user
  7. specify the user address info
  8. specify the payment type
  9. specify invalid payment info
  10. submit the order
  11. check that the correct error is displayed

I know, this process is complicated and time consuming.

But there are no simple solutions for complicated problems.

Better hiring processes are needed.

If not, you will keep hiring fake testers that are "professional test automation engineers" and either create a lot of bad code that will eventually be thrown away.

Or will create one test per month.

Why are Selenium automation jobs decreasing?


The market demand for test automation is higher than ever but the number of automation jobs is lower.

How can this be?

One reason is the "test automation" name.

Test automation is not a good name for this type of work.

Automated checking or tool-assisted testing (James Bach) are describing better what actually happens.

Automation does not automate or replace creative testing but just checks that simple and clear test cases work.

Because test precedes automation in the name, companies and testers thought that test automation is a part of testing and it should be done by testers.

Testers thought that test automation is the silver bullet for their careers and went ahead with the "learning phase".

After learning the bare minimum of Selenium and a programming language in less than a year, many claimed that they are automation engineers instead of manual testers.

And some companies, especially the ones without rigorous interviewing processes, hired the manual-testers-converted-overnight-to-automation-engineers.

These "engineers" started with enthusiasm to build automation projects and wrote code, lots of code.

Which in most cases was just a bunch of crap.

I have seen such projects built by automation "experts" who
  1. do not understand inheritance and composition
  2. have no clue how to use interfaces
  3. don’t know what page factory, loadable component or yes, maven are
  4. use maps instead of objects
  5. create test classes with thousands of lines of code and hundreds of methods
  6. create page classes with click/type/getText methods for each page element (again with thousands of lines of code)
  7. use static methods and variables heavily
  8. use utility classes a lots

These are testers that are experts at writing-VB-code-in-Java.

The only thing that matters for them is if the code works now.

It is less important that the code is inefficient, not object oriented, difficult to read and maintain.

It is also less important that the code fails randomly when executed in Jenkins.

If the tests fail, we just rerun them until they pass.

After a while, companies start realizing that things are not going well at all, especially when they have a few thousands of tests which fail with a 25-30% rate.

And, at this moment, they switch direction and hire either developers or testers who became developers.

In most cases, a good developer can do the work of 3-4 VB-in-JAVA automation experts.

So, see, it is completely possible that the business demand is higher but the number of jobs lower.

The market matures and filters out people who are not suitable or ready for automation work.

Pradeep Soundararajan (from Moolya) said somewhere on Quora that
Not all manual testers will disappear, only the unprofessional ones.

My opinion is that this is happening for test automation as well:
The professional automation engineers will stay, the other ones will fade away.

Contrary to what you hear from a lot of people, test automation is not easy and it is not for anyone.

To do it well, you have to learn a new job and become a developer.