How to Learn Selenium WebDriver in 3 Days

or How to Learn Selenium WebDriver like a JEDI

I like Star Wars movies.

I still remember seeing the first episode, A New Hope, at the cinema, back in the 1980s.

Since then, I watched it and the following 5 episodes, produced by LucasFilm, many, many times.

The new ones, produced by Disney, are still good (much simpler though) especially Rogue One and The Last Jedi.

There is an interesting difference between the old Star Wars movies and the recent ones.

In The Last Jedi, Luke Skywalker agrees to teach Rey just 3 lessons about the force. She needs to learn how to be a JEDI to be able to fight the imperial army and yes, Kylo Ren.

The lessons happen fast and only bits of knowledge and wisdom go from the teacher to the student. Not much skills as Luke is now a wise old man instead of a JEDI knight as before.

Just 3 lessons are enough for Rey to discover her potential and the mighty force. Having the force, she lifts a huge pile of rocks that stops her friends from running from the imperial army.

Unfortunately, as the episode title explains, the last JEDI disappears so in the future, there are no more JEDIs to teach about the force.

No more lessons about the force but probably the lessons are not needed any longer.

If Rey can learn the force in 3 lessons, maybe she can explain it to others in 1 lesson or maybe in just a few sentences.

The force is no longer accessible to a few but to all.
You just need to put your mind to it and there it is.

Now, why shouldnt we be able to do the same with Selenium WebDriver?

3 lessons.

It is not that hard.

The secret of the force is in how the study material is broken down per day.

Day 1
learn about html, xpath, css, browser dom, eclipse, java basics, unit testing.

Day 2
learn about object oriented notions like classes, objects, inheritance, composition, interfaces, polymorphism, generics, predicates, reflection, streams.

Day 3
learn the page object model, page factory, loadable component, slow loadable component and a few other design patterns.

And that's it, we are there, we can lift our own automation rocks.

This is totally doable if you are a Star Wars believer.

Everyone can do whatever they put their mind to.
Everything is easy to do and learn.
Everything is accessible to all of us, even the force.
The JEDI knights go away and who need them anyways?

Now, the old Star Wars episodes are a little different from the new ones.

In The Phantom Menace and Attack Of The Clones, the process of becoming a JEDI knight is explained in detail. You had to start your training at the JEDI Academy at a young age and complete it.

Then, a mentor would guide you through real life experiences until you are ready to pass the JEDI trials for becoming a knight.

No one became a JEDI in 3 lessons or 6 or 15.
No matter how skilled, talented or gifted.

Instead, the trainee would go through a long, difficult and intensive education with both teachers, peers and mentors.

This would totally work for Selenium WebDriver as well.

Selenium WebDriver learning is basically learning how to code which is best done with teachers, peers and mentors.

So Star Wars is a viable source of inspiration.

You just have to watch the proper episodes.

Watch The Last Jedi and believe that 3 lessons are sufficient.

Watch The Phantom Menace and understand that 6 months is a better time range.

What are the risks of taking selenium

This question took me by surprise.
Risks of taking selenium?
Are there any risks?
Am I in danger?
Am I sick from too much Selenium?

Read along.

Of course, there are risks.
But first, a few words about benefits.
Selenium is a mineral.
It is taken into the body in water and foods. People use it for medicine.
Selenium is used for diseases of the heart and blood vessels, including stroke and “hardening of the arteries” (atherosclerosis). It is also used for preventing various cancers including cancer of the prostate, stomach, lung, and skin.
Some people use selenium for under-active thyroid, osteoarthritis, rheumatoid arthritis(RA), an eye disease called macular degeneration, hay fever, infertility, cataracts, gray hair, abnormal pap smears, chronic fatigue syndrome (CFS), mood disorders, arsenic poisoning, and preventing miscarriage.
Selenium is also used for preventing serious complications and death from critical illnesses such as head injury and burns. It is also used for preventing bird flu, treating HIV/AIDS, and reducing side effects from cancerchemotherapy.
And the risks?
Selenium deficiency is very rare in the United States and Canada.
Selenium deficiency can cause Keshan disease (a type of heart disease) and male infertility.
It might also cause Kashin-Beck disease, a type of arthritis that produces pain, swelling, and loss of motion in your joints.

Now, joking aside, what are the risks of taking, sorry, learning Selenium WebDriver?
You are a manual tester.
You want to learn test automation, meaning programming and Selenium WebDriver.
Some of the risks that you are exposing to are
  1. you may find that you don’t have enough motivation; most people have high enthusiasm initially which, when confronted with the challenges of learning programming, goes away bit by bit until it is over ; so one of the risks is that you start learning, then stop it and feel like you failed
  2. you may realize while learning Selenium that you like it so much that you dont want to do manual testing any longer; i know people who after learning some automation did not want to go back; so another risk may be that your manual testing days are over but your automation days are started
  3. you may get to a point where you will be willing on learning Selenium and programming not only during your work hours but also at home; so you will be risking some of your free time (and your family’s)
  4. you may be risking some of your friendships if you make progress with your automation learning; some of your tester friends who cannot do it may not be positively impressed by you doing what they cannot
  5. finally, you may be risking your career and your job; when you learn enough programming and automation, you may stop being a tester and become a developer; you lose your tester job but gain a developer one

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.

Test automation - from theory to reality

If you have been reading about test automation in magazines, blogs or books, you get the idea that automation is nice, easy, straightforward and beautiful.

Because all these talk about theory, most of the time. 

Theory is always like a finished, simple, beautiful, well designed, professionally-done building. 

In theory, automation is about having 

  • independent tests
  • tests that create their own data and delete it after being executed 
  • dedicated test automation environment 
  • tests that run in parallel 
  • tests that use simulated external dependencies 
  • tests that run in 3 minutes  
  • good code written by professional people

This all sounds great and makes you want to get started with test automation tomorrow :) 

And how is test automation in reality? 

Have a look at this construction. 

Automation in real life means in many cases

  • dependent tests; if one test fails, multiple other tests fail 
  • tests that use manually created data; the data is also different from environment to environment; 
  • shared test automation environment; the tests are created and executed on an environment used as well for manual testing 
  • tests that run in "parallel"; instead of having tests executed in parallel on multiple Jenkins slaves, you have tests executed in "parallel" on the same slave 
  • tests that use real external dependencies 
  • tests that run in a few hours 
  • bad code written by non-professional people

Theory and reality are never similar. 

To get from reality to something similar to theory is difficult and takes a long time. 

But it is worth doing, that is for sure! post - How to deal with windows authentication popups

If you dont like Bugs Bunny, maybe you should not continue reading.

What is the first thing that I do every morning at work?
Check the results of the automation scripts executed in Jenkins over night.
I want to know how many scripts passed or failed because of the work done in the previous day.
Most days, some scripts pass and some fail.
But recently, most scripts failed.
This was very unusual so I looked into it right away.
All failures followed the same pattern: the scripts failed on opening the site in the browser.

A day in the life of an automated tester

What does an automation engineer do?

What skills does he need?

How does a work day look like?

What problems does he face?

How are they solved?

What else except writing code is involved in test automation?

Are all automation jobs the same?

Test automation jobs are as diverse as the manual testing ones.

Many things can be different between 2 automation jobs:
  • application type: web site, mobile app, windows application or a console utility
  • programming language: automation is done mostly in Java and C# but also in Ruby, Python and JavaScript
  • automation library: open source (example: Selenium WebDriver, Appium, Robot Framework) or proprietary (UFT)
  • how the tests are designed: unit tests, behaviour integration tests, etc
  • project's design: page object model, page factory, keyword driven are just a few different models that can be used for automation

Test automation jobs can focus on different things.
Some create the automation project from scratch.
Others create tests for an existing framework or redesign existing automation frameworks.

Every job is about solving problems.

This series of articles aims to describe a day in the life of an automated tester, the problems that the tester has and their solutions.

Everything that follows is about a fictive job but inspired from reality.

Thanks for reading.

Day 4 - Page Object Model
Day 3 - About Automation Test Data
Day 2 - What Type Of Automation Job Is This?
Day 1 - First Day Of A New Job

The good, the bad and the ugly of test automation

Each manual tester that I know wants more excitement and challenge in his day-to-day work.

Because, lets admit it, manual testing gets boring at times.

So the testers look at the next best thing such as test automation.

They imagine a day when, having enough knowledge and skill, the manual testing will be traded with test automation.

Which will be exciting, challenging, interesting and never boring.

In other words, Good.

This is obviously not true all the time.

Test automation experiences can be good.

But also bad.

Or ugly.

Good, bad and ugly, 3 faces of test automation.

Have you seen this movie with Clint Eastwood?

The good, the bad and the ugly is one of the greatest films of all time.

It is about 3 gun fighters, the good, the bad and the ugly, all in search of a burried treasure.

Clint Eastwood as Blondie: The Good, a subdued, confident bounty hunter, capable of pity and providing comfort for dying soldiers,

Lee Van Cleef as Angel Eyes: The Bad, a ruthless, unfeeling, and sociopathic mercenary.

Eli Wallach as Tuco: The Ugly, a comical and oafish but cagey and resilient, fast-talking Mexican bandit who is wanted by the authorities for a long list of crimes.

Back to test automation.

How are automation projects good, bad or ugly?

The Good

You get hired to create test automation scripts for a web site.

The website already exists and it is stable.

There is no test automation in place.

Test data is easy to get and recreate.

The test environment is not shared with other test and development teams and can be easily refreshed.

It is your responsibility to create the test automation project from scratch including
  • the test scripts
  • the page objects
  • the test automation framework

You have the knowledge and the skills for the job.

You will not do all work by yourself but as part of a team that includes other people with similar knowledge, motivation and skills.

The Ugly

You start a new job and get handed an automation project created a few years ago.

Multiple teams worked on it during this time and created a few thousands of tests.

The tests run with a 30% fail/error rate.

The code has
  • tons of duplication
  • classes with thousands of lines of code
  • lots of static delays and implicit waits
  • it supports multiple applications (mobile site, desktop site)

The page object model is applied incorrectly with each page class having separate methods for clicking, typing, getting the value of each element.

The test environment is shared with other manual test teams.

The test data is very difficult to configure and recreate.

It is your responsibility to clean the project up, to stabilize it by reducing the fail/error rate and to bring the project in shape.

The Bad

This is when you get hired for a test automation job and you are not ready for it.

Your skills are incomplete and your experience limited.

There are high expectations from you and you cannot deliver.

Not without significant time dedicated to training.

3 faces of the same experience.

The good, the bad and the ugly of test automation.

Where can I find a full test automation project with Selenium WebDriver?

You have been learning test automation with Selenium.

You went through lots of concepts and would like to see how they all work together.

Where can you find a project that uses everything you learned and more?

Here :)

What follows is a small project that I built a while ago for a job interview.

It uses many test automation concepts such as:
  • page factory
  • base classes
  • html classes
  • test listeners
  • test ng assertions and fixtures
  • annotations
  • custom locators (javascript and jquery)
  • screenshots
  • saving errors in text files

The exercise consisted in automating the following test case with Java and Selenium WebDriver:

  • Launch bestbuy url (
  • Search a product and add it to cart
  • Go all the way through checkout process and place the order with invalid credit card
  • Capture the error message due to invalid credit card

Before downloading the project and checking the source code, a few details about the project.

Project details

Maven project
- all dependencies are managed through the pom.xml file

Test NG
- unit testing library

Java JDK 8
- used for lambda expressions and streams

Page Factory
- pattern for creating page object and page fragment classes
- the elements of page object/fragment classes have names and locators
- names and locators are implemented using annotations
- available locator types are id, xpath, css, name and javascript
   @FindBy(className = "main-navigation-container") 
   public class SearchHeader extends HtmlElement{ 
   @FindBy(id = "ctl00_MasterHeader_ctl00_uchead_GlobalSearchUC_TxtSearchKeyword") 
   private TextInput searchKeywordTxt;
   @FindBy(id = "ctl00_MasterHeader_ctl00_uchead_GlobalSearchUC_BtnSubmitSearch")
   private Button searchBtn; 
   public void search(String keyword) {;  

The project has the automation framework classes in the main folder and all test items in the test folder.

Main folder (framework classes)

annotations classes
- FindBy
- FindByJS
- Name
- Timeout

 import java.lang.annotation.ElementType;
 import java.lang.annotation.Retention;
 import java.lang.annotation.RetentionPolicy;
 import java.lang.annotation.Target;

 @Target({ElementType.TYPE, ElementType.FIELD})
 public @interface Name {
   String value();

html element classes

    import org.openqa.selenium.By;
    import org.openqa.selenium.NoSuchElementException;
    import org.openqa.selenium.WebElement;

    public class CheckBox extends TypifiedElement {
      public CheckBox(WebElement wrappedElement) {

      public WebElement getLabel() {
        try {
            return getWrappedElement().findElement(By.xpath("following-sibling::label"));
        } catch (NoSuchElementException e) {
            return null;

      public String getLabelText() {
        WebElement label = getLabel();
        return label == null ? null : label.getText();

      public String getText() {
        return getLabelText();

      public void select() {
        if (!isSelected()) 

      public void deselect() {
        if (isSelected()) 

      public void set(boolean value) {
        if (value) 

exceptions classes

decorator and proxy classes used by the page factory

page class
- used as base class for the page object classes

page factory classes

miscellaneous classes such as
- custom driver class, screenshot class
- enumerations (used to avoid hardcoding data in the page objects)
- simple logger class
- property class
- TextFile class

Test folder (test items)

  • base test class (used as base by the test classes)

  • page objects classes (all page object and page fragment classes)

  • test listeners (class for taking a screenshot and logging exceptions in case of failures)
     import java.lang.reflect.Field;
     import org.testng.ITestContext;
     import org.testng.ITestListener;
     import org.testng.ITestResult;
     import org.openqa.selenium.WebDriver;
     import static*;
     public class TestListener implements ITestListener {   
        public void onTestFailure(ITestResult result) {       
           try {
             Screenshot screenshot = 
             new Screenshot(getDriverFromBaseTest(result));
           catch (Exception ex) {
             throw new HtmlElementsException(ex.getMessage());
       private WebDriver getDriverFromBaseTest(ITestResult result) 
           throws IllegalAccessException {
          WebDriver driver = null;
          try { 
             Class< ? extends ITestResult> testClass = 
             (Class< ? extends ITestResult>) result.getInstance().getClass();
             Class< ?extends ITestResult> baseTestClass = 
             (Class< ? extends ITestResult>) testClass.getSuperclass();
             Field driverField = baseTestClass.getDeclaredField("driver");
             driver = (BrowserDriver)driverField.get(result.getInstance()); 
             return driver;
         catch (SecurityException | NoSuchFieldException | IllegalArgumentException ex) {     
             throw new HtmlElementsException("error getting the driver from base test");    
       public void onTestSuccess(ITestResult result) 
       public void onTestSkipped(ITestResult result) 
       public void onTestFailedButWithinSuccessPercentage(ITestResult result) 
       public void onStart(ITestContext context)     
       public void onFinish(ITestContext context)    
       public void onTestStart(ITestResult arg0)
  • test class

Most interactions with web elements are done through the page factory classes.

Occasionally, Javascript code is used when buttons cannot be clicked through the page factory.

Some of the pages have random popups that are closed if displayed.

The test script does the following:
  1. Open the home page
  2. Execute a keyword search
  3. Select the Online Only filter
  4. Select a product with online availability
  5. Add the product to the cart
  6. Continue checkout on the basket page
  7. Select New Member
  8. Fill in the Ship To info
  9. Select credit card as payment method
  10. Fill in the payment info
  11. Submits transaction
  12. Verify that there is at least an error message
  13. Saves the error messages and the search keyword to a text file

The test script uses a keyword parameter which can take multiple values.

Download source code

Interested in learning how to build a project like this one?

Get started here

Test automation wants your manual testing job

Automation will leave many people without a job. 

I am not talking about test automation being a danger to many manual testing jobs. 

But about automation in a more general perspective. 

In Canada, in the next 10 - 15 years, up to 7.5 million jobs (out of 18) will be lost because of automation. 

This is what Huffington Post says and I agree with them. 

The key points of the article are below: 

  • Canada faces the loss of up to 7.5 million jobs to automation in the next 10 to 15 years 
  • Even people in high-income jobs won’t be spared, as automation will reduce the demand for doctors, lawyers and engineers, among others. 
  • Autonomous vehicles are already on the road, robo-advisors are dispensing financial counsel and even lawyers and reporters are starting to see automation take over routine functions. 
  • The study’s projections found a broad range in the number of jobs that could be lost — 1.5 million at the lower end, and 7.5 million at the high end. That amounts to between 8.3 per cent and 41 per cent of the 18 million jobs in existence in Canada today. 

So the demand for doctors, lawyers, engineers, reporters, etc will be reduced significantly. 

Should we hope that this will not happen to testers?

Stop being a one-trick pony! Stop focusing only on manual testing!

Manual testing will not go away. 

But it will not be anymore what it used to be. 

Like all things, testing changes and at a rapid pace. 

Companies still need manual testers but less than before. 

Normal testing is something that not only testers can do. 
A business analyst, business user or developer can do it as well. 

With so "many testers" available, companies hire outside testers if they are exceptional. 

Or multi-talented, with diverse skills. 

So do you want to continue to have a career in testing? 

Stop being a "one-trick pony" and stop focusing only on manual testing. 

Manual testing used to be sufficient for a successful career. 

You had a good "trick" and used it over and over. 

While you focused on your trick, everything around you changed and you did not notice. 

One day, you discover that the one-trick does not keep you employed. 

You rush then to learn more tricks and hope that you can do it fast.

Sadly it is too late because learning does not happen over night. 

This is something that applies to many other domains. 

Like sports. 
Take mixed martial arts, for example. 

One of the MMA women divisions had a champion for 3 years in Ronda Rousey who beat soundly (and in many cases under 1 minute) all her opponents. 

She did this with great judo skills. 

Ronda was a true "one-trick pony" since all her skills were only about judo. 

One day came when she fought a true boxer. 

Even with a lot of boxing training, she lost in a dramatic fashion. 

After her first loss, she took a year off and trained more in boxing hoping for a revenge. 

Next time she fought, she lost again but this time under 1 minute. 

What happened then?

While she was enjoying her "one pony trick", the world changed and she did not notice. 

When she realized that serious improvement was needed, it was a bit too late.