New article from seleniumjava.com:
https://seleniumjava.com/2017/06/05/how-to-create-page-objects-with-selenium-webdriver/
https://seleniumjava.com/2017/06/05/how-to-create-page-objects-with-selenium-webdriver/
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
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
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!
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!
SeleniumJava.com 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:
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
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 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
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.
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
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.
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.
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:
The exercise consisted in automating the following test case with Java and Selenium WebDriver:
Before downloading the project and checking the source code, a few details about the project.
The project has the automation framework classes in the main folder and all test items in the test folder.
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:
The test script uses a keyword parameter which can take multiple values.
Download source code
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 (www.bestbuy.ca)
- 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
@Name("SEARCH_HEADER")
@FindBy(className = "main-navigation-container")
public class SearchHeader extends HtmlElement{
@Name("SEARCH_FIELD")
@FindBy(id = "ctl00_MasterHeader_ctl00_uchead_GlobalSearchUC_TxtSearchKeyword")
private TextInput searchKeywordTxt;
@Name("SEARCH_BUTTON")
@FindBy(id = "ctl00_MasterHeader_ctl00_uchead_GlobalSearchUC_BtnSubmitSearch")
private Button searchBtn;
public void search(String keyword) {
searchKeywordTxt.click();
searchKeywordTxt.clear();
searchKeywordTxt.sendKeys(keyword);
searchBtn.click();
}
}
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
- - FindByJQUERY
- - FindByJS
- - Name
- - Timeout
- html element classes
- 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
package com.bestbuy.demo.annotations;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.FIELD})
public @interface Name {
String value();
}
package com.bestbuy.demo.element;
import org.openqa.selenium.By;
import org.openqa.selenium.NoSuchElementException;
import org.openqa.selenium.WebElement;
public class CheckBox extends TypifiedElement {
public CheckBox(WebElement wrappedElement) {
super(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())
getWrappedElement().click();
}
public void deselect() {
if (isSelected())
getWrappedElement().click();
}
public void set(boolean value) {
if (value)
select();
else
deselect();
}
}
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)
package com.bestbuy.demotests.testlisteners;
import java.lang.reflect.Field;
import org.testng.ITestContext;
import org.testng.ITestListener;
import org.testng.ITestResult;
import com.bestbuy.demo.exceptions.HtmlElementsException;
import com.bestbuy.demo.utils.Driver.BrowserDriver;
import com.bestbuy.demo.utils.Driver.Screenshot;
import org.openqa.selenium.WebDriver;
import static com.bestbuy.demotests.BaseTest.BaseTestClass.*;
public class TestListener implements ITestListener {
@Override
public void onTestFailure(ITestResult result) {
try {
Screenshot screenshot =
new Screenshot(getDriverFromBaseTest(result));
screenshot.capture(result.getName());
}
catch (Exception ex) {
throw new HtmlElementsException(ex.getMessage());
}
}
@SuppressWarnings("unchecked")
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");
}
}
@Override
public void onTestSuccess(ITestResult result)
{}
@Override
public void onTestSkipped(ITestResult result)
{}
@Override
public void onTestFailedButWithinSuccessPercentage(ITestResult result)
{}
@Override
public void onStart(ITestContext context)
{}
@Override
public void onFinish(ITestContext context)
{}
@Override
public void onTestStart(ITestResult arg0)
{}
}
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:
- Open the home page
- Execute a keyword search
- Select the Online Only filter
- Select a product with online availability
- Add the product to the cart
- Continue checkout on the basket page
- Select New Member
- Fill in the Ship To info
- Select credit card as payment method
- Fill in the payment info
- Submits transaction
- Verify that there is at least an error message
- 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 hereTest 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.
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.
Learn automation while you don't need it
I have been a software manual tester for 10 years.
Due to the regression tests that I do every other week, it is imperative that I get this function automated to help me with the rest of my job.
I regression test over 90 custom sites for my company and really need to get this done by February 2017.
Please help.
I received this message from a tester a few weeks ago.
He wanted to learn automation and programming and use these skills successfully in 2 months.
Which is very difficult to do.
I don't know why he did not start learning earlier.
He probably thought that will not need automation and his employer will hire a developer for the automation work.
So he did what many people do in similar occasions: postpone.
We don't like change and avoid it.
Our hope is that somehow things stay the same or we figure them out.
And a moment comes when we need change fast and results too.
This is when we realize the mistake of not starting ahead of time, when we don't need the new skills yet.
Fast change happens in stories and movies only.
Real change takes time and is done in small steps.
So, stop postponing learning programming and get started.
It does not matter if you need it in your job now or not.
You will need it sooner than you think.
Next December, you will be very happy that you started learning automation the year before.
What do you need for a Selenium test automation job?
First, the obvious.
Since test automation is programming, you need to know the basics (more if possible) of a programming language such as Java.
And you need to know the basics of the Selenium WebDriver framework.
But this is not sufficient for getting an automation job.
In an interview, you have to convince other people that you know how different things work in Selenium and Java.
For example,
You still need more for that new automation job.
You need 500 hours of practicing Selenium and Java.
The number of hours is different from person to person.
Some people may need less, others more.
But it is essential that you put the time in for the practice.
Why so many hours?
Because companies will put you to test.
There are 2 types of tests that you may have to do:
1. JAVA coding test
This test happens before the face-to-face interview and is a condition for it.
It is usually done online on a site like codility.com and it can last around 1 hour.
You are given a problem and have to write code that solves it.
EXAMPLE
2. SELENIUM automation test
After the face-to-face interview, if the interview went well, you may be asked to do the automation exercise.
This test is about automating a scenario for a site.
You may get 1 day or more to do it.
EXAMPLE
Going back to the 500 hours practice.
It is very difficult to do well at these exercises if you are not already proficient with Java and Selenium.
Because the time for doing the exercises is limited.
And your solutions have to be very good to get the job.
Since test automation is programming, you need to know the basics (more if possible) of a programming language such as Java.
And you need to know the basics of the Selenium WebDriver framework.
But this is not sufficient for getting an automation job.
In an interview, you have to convince other people that you know how different things work in Selenium and Java.
For example,
- what is boxing in Java?
- what is the difference between method overwriting and overriding?
- what is the page object model?
- what are the fastest locators?
You still need more for that new automation job.
You need 500 hours of practicing Selenium and Java.
The number of hours is different from person to person.
Some people may need less, others more.
But it is essential that you put the time in for the practice.
Why so many hours?
Because companies will put you to test.
There are 2 types of tests that you may have to do:
1. JAVA coding test
This test happens before the face-to-face interview and is a condition for it.
It is usually done online on a site like codility.com and it can last around 1 hour.
You are given a problem and have to write code that solves it.
EXAMPLE
2. SELENIUM automation test
After the face-to-face interview, if the interview went well, you may be asked to do the automation exercise.
This test is about automating a scenario for a site.
You may get 1 day or more to do it.
EXAMPLE
Going back to the 500 hours practice.
It is very difficult to do well at these exercises if you are not already proficient with Java and Selenium.
Because the time for doing the exercises is limited.
And your solutions have to be very good to get the job.
Subscribe to:
Posts (Atom)