The document outlines a comprehensive guide for using Selenium to write business-relevant, reusable, and maintainable tests across various browsers. It provides a structured approach through ten steps, including defining a test strategy, selecting a programming language, utilizing Selenium fundamentals, and preparing for cross-browser execution. Additionally, it emphasizes the importance of building an automated feedback loop to identify failures early in the development process.

1. How To Use Selenium,
Successfully
by Dave Haeffner, @TourDeDave

2. http://www.wpclipart.com/geography/features/chasm.png.html

3. http://en.wikipedia.org/wiki/Optimal_solutions_for_Rubik's_Cube

4. Write business valuable tests that are
reusable, maintainable and resilient
across all relevant browsers.
Then package and scale them for
you & your team.

5. Selenium Overview
• What it is — the Reader’s Digest version
• What it is and is not good at
• IDE vs. Local vs. Remote
• Slow, brittle, and hard to maintain?

6. Support
68% 15% 11% 5% 1%

7. Usage
23,949,711
Downloads, 2015 Q3
*

8. What’s Happening?
Support
3

10. Step 1
Define a Test Strategy

11. Test Strategy
1. How does your business make money?
2. What features of your application are being used?
3. What browsers are your users using?
4. What things have broken before?
Outcome:
- What features to test
- Which browsers to care about

12. Step 2
Pick a Programming
Language

13. How To Pick a
Programming Language
• Same language as the app?
• Who will own it?
• Build a framework or use an existing one?
• http://se.tips/seleniumframeworks

14. Step 3
Use Selenium
fundamentals

15. Selenium Fundamentals
• Mimics human action
• Uses a few common actions
• Works with “locators”
Locators tell Selenium which HTML element to interact with

16. Common Actions
• get();
• findElement();
• click();
• sendKeys();
• isDisplayed();

17. Locator Strategies
• Class
• CSS selectors
• ID
• Link Text
• Partial Link Text
• Tag Name
• XPath
Good locators are:
• unique
• descriptive
• unlikely to change
That rules a few of these out

18. Locator Strategies
• Class
• CSS selectors
• ID
• Link Text
• Partial Link Text
• Tag Name
• XPath
Good locators are:
• unique
• descriptive
• unlikely to change
That rules a few of these out

19. Locator Strategies
• Class
• CSS selectors
• ID
• Link Text
• Partial Link Text
• Tag Name
• XPath
Good locators are:
• unique
• descriptive
• unlikely to change
That rules a few of these out
Start with IDs and Classes

20. Locator Strategies
• Class
• CSS selectors
• ID
• Link Text
• Partial Link Text
• Tag Name
• XPath
Good locators are:
• unique
• descriptive
• unlikely to change
That rules a few of these out
Start with IDs and Classes
Use CSS or XPath (with care)

21. Locator Strategies
• Class
• CSS selectors
• ID
• Link Text
• Partial Link Text
• Tag Name
• XPath
CSS vs XPath
http://se.tips/seleniumbenchmarks
http://se.tips/cssxpathexamples

22. Finding Quality Locators
• Inspect the page
• Verify your selection
• e.g., FirePath or FireFinder
• e.g., JavaScript console with $$(‘’); or $(‘’);
• http://se.tips/verifyinglocators
• Learn through gaming
• http://se.tips/locatorgame
• Conversation

24. CSS Selectors Cheat Sheet

27. Step 4
Write good tests

28. Good Test Anatomy
• Write for BDD or xUnit test framework
• Test one thing (atomic)
• Each test can be run independently (autonomous)
• Anyone can understand what it is doing
• Group similar tests together

29. A Login Example
1. Visit the login form
2. Find the login form’s username field and input text
3. Find the login form’s password field and input text
4. Find the submit button and click it

30. http://the-internet.herokuapp.com/login

33. Now to find an assertion
1. Login
2. Inspect the page
3. Find a locator
4. Verify it
5. Add it to the test

35. Assertion tips
• Only trust a test you’ve seen fail
• Check out Hamcrest matchers
http://se.tips/junit-hamcrest

36. Exception Handling
• org.openqa.selenium.NoSuchElementException:
Unable to locate element: {"method":"css
selector","selector":".flash.error"}
• Most common ones you’ll run into:
NoSuchElement and
StaleElementReferenceError
• A list of all WebDriver exceptions:
http://se.tips/se-exceptions-java

37. Exception Handling cont’d

38. A much better assertion

39. Automated Visual Testing Primer
• Check that an application’s UI appears correctly
• Can also be used to verify content
• Hundreds of assertions for a few lines of code
• Open-source libraries, baseline image comparison,
and inherent challenges
http://se.tips/visual-testing-getting-started

40. In pom.xml

45. Step 5
Write reusable and
maintainable test code

46. Page Objects

47. Application Under Test
Test 1 Test 2 Test 3 Test 4 Test 5Test 1 Test 2 Test 3 Test 4 Test 5
Need to update EVERY test :-(

48. Page Object(s)
Application Under Test
Test 1 Test 2 Test 3 Test 4 Test 5
Need to update JUST the page object :-D

49. Let’s look at a page
object for login

51. And here’s what the test
looks like when using it

53. • homepage of project sites; split screen
http://se.tips/po-html-elements

54. http://se.tips/page-factory

55. Base Page Object
a.k.a.
Selenium Wrapper
Utility Class
etc.

56. Selenium
Commands
Page
Object 1
Page
Object 2
Page
Object 3
Page
Object 4
Page
Object 5

57. Base Page
Object
Page
Object 1
Page
Object 2
Page
Object 3
Page
Object 4
Page
Object 5
Selenium
Commands
• Global reuse
• More readable
• Insulates you from
Selenium API changes
http://se.tips/se-upgrade

58. Let’s take a look at a
Base Page Object

60. And here it is
implemented

62. How everything fits together
Test TestTest
Page
Object
Page
Object
Base
Page
Object
Tests use page objects
Page objects inherit the
base page (utility) class
The base page object wraps
your Selenium commands

63. Step 6
Make your tests resilient

64. Waiting

65. Thread.Sleep();
Implicit wait
Explicit waits

66. Thread.Sleep();
Implicit wait
Explicit waits

67. Waiting in Selenium
Implicit
• Specify an amount of time during test setup
• *Every* Selenium action will be retried until:
• The action can be completed, or
• The amount of time specified has been reached
(and throw an exception)

68. Waiting in Selenium
Explicit
• Specify an amount of time and an action (only
when you need it)
• Selenium will try *that* action repeatedly until:
• The action can be completed, or
• The amount of time specified has been reached
(and throw a Timeout exception)

69. http://se.tips/se-waiting-jim-evans

70. Thread.Sleep();
Implicit wait
Explicit waits

71. Thread.Sleep();
Implicit wait
Explicit waits
http://se.tips/se-waiting

73. In the Base page object

74. In the DynamicLoading page object

76. Cross-browser Timing

77. x
x
✓
✓

78. Step 7
Prep for use

79. Core Features
1. Simple organizational structure
2. Central setup and teardown
3. Configurable at run-time (with sensible defaults)
4. Reporting & Logging
5. Parallelization
6. Test Segmentation

80. Folder Structure

81. Central setup/teardown
More on JUnit Rules:
http://bit.ly/junit-rules

82. Simple config with defaults
Import config where it’s needed
(e.g., base test, etc.)

84. Reporting & Logging
• Machine readable
e.g., JUnit XML
• Human readable
e.g., screenshots, failure message, stack trace
Fantastic Test Report Tool
http://se.tips/se-reporter (Allure Framework)
Screenshot on Failure
http://se.tips/screenshot-on-failure

85. Parallelization
• In code
• Through your test runner
• Through your Continuous Integration (CI) server
#protip Enforce random order execution of tests
(turnkey in mvn-surefire)
Recommended approach:
http://se.tips/mvn-surefire

86. In your pom.xml

87. Test Grouping
• Metadata (a.k.a. Categories)
• Enables “test packs”
• Some category ideas
• defect
• shallow & deep
• release or story number
More info:
http://se.tips/junit-cat

90. Running Categories

91. Step 8
Add in cross-browser
execution

92. Locally
http://se.tips/firefox-driver
http://se.tips/chrome-driver
http://se.tips/ie-driver
http://se.tips/safari-driver (old)
http://se.tips/safari-driver-new
http://se.tips/edge-driver

93. Chrome

94. Grid
Grid Hub
Browser
Tests
All done with the Selenium Standalone Server
Just requires additional runtime flags
Grid
Node
Grid
Node
Grid
Node
Browser
Browser

95. Grid
Hub
Node(s)

96. Grid
• http://se.tips/grid-getting-started
• http://se.tips/se-grid-extras
• http://se.tips/se-grid-scaler

97. Sauce Labs
Sauce Labs Browser
Tests

98. Sauce Labs cont’d

99. Sauce Labs
Additional Considerations
- Test name
- Pass/Fail status
- Secure tunnel
More on Sauce:
http://se.tips/sauce-platform
http://se.tips/sauce-getting-started
http://se.tips/sauce-with-applitools

101. Step 9
Build an automated
feedback loop

102. Feedback loops
• The goal: Find failures early and often
• Done with continuous integration and notifications
• Notifications
- remote: Email, chat, SMS
- in-person: audio/visual indicators

103. Code
Committed
Unit/Integ.
(pass?)
Deploy to
autom. test
server
(success?)
Run
automated
tests
(pass?)
Deploy to
next env.
yes
yes
yes
Notify team if no
Code Promotion
Bonus points: stop the line

104. Simple CI configuration
1. Create a Job
2. Pull In Your Test Code
3. Set up Build Triggers
4. Configure Build steps
5. Configure Test Reports
6. Set up Notifications
7. Run Tests & View The Results
8. High-five your neighbor

106. Step 10
Find information on
your own
http://se.tips/find-selenium-info

107. #selenium
Watch the video at http://se.tips/se-info-irc

108. Steps to solve the puzzle
1. Define a Test Strategy
2. Pick a programming language
3. Use Selenium Fundamentals
4. Write good tests
5. Write re-usable & maintainable code
6. Make your tests resilient with waits
7. Package your tests into a framework
8. Add in cross-browser execution
9. Build an automated feedback loop
10. Find information on your own

109. Write business valuable tests that are
reusable, maintainable and resilient
across all relevant browsers.
Then package them and scale them
for you & your team.

110. –Dave Haeffner
“You may think your puzzle is unique. But really, everyone is
trying to solve the same puzzle. Yours is just configured
differently — and it’s solvable”