2. • Audience is familiar with Selenium IDE or
other automation tools.
• Familiar with Record and Playback and
Analyzing the results of Playback.
• I am positive that you can take this concept
and make it your own and implement it with
the automation tool of your choice.
• This tutorial is about a new framework that focuses on saving the
automation script to handle User Interface (UI) & HTML ID changes. It
simultaneously enables us to write our scripts in English (literally).
Assumptions
3. Installations / Software needed
Download and install –
1. We will utilize the Selenium IDE, Mozilla Firefox (any version as long as each is
compatible with the other)
2. Mozilla Firefox - http://www.mozilla.org/en-US/firefox/new/
3. Selenium IDE - http://seleniumhq.org/download/ (download Selenium IDE
latest version and any add-ons listed in the same page (optional))
4. FireBug for Firefox – http://getfirebug.com/downloads
Terms to be acquainted with
UI = User Interface
GUI = Graphical User Interface
DOM = Document Object Model
HTML ID = Identification attribute that provides Document-wide
unique identifier for an element.
4. 1. What happens to the automated regression scripts if the User
Interface changes?
2. Can we use the same scripts for testing various user interfaces
with a similar purpose?
3. What is the simplest method to update the scripts?
4. What is the simplest method to trouble shoot issues with scripts?
Introduction
5. This presentation will give step-by-step instructions for creating a Test suite utilizing the Green
Lantern concept. A tester can take this concept and utilize it for creating test suites for one’s
applications.
• First step is to specify a location where the test result pictures will be stored. I log
messages with pictures rather than go through the log file and find the errors, warning or
information messages.
• Second step is to identify the elements (text field, link, button, page, text, check box, etc.).
The developers usually assign a “logical name” to these elements. I rename the “logical
names” with a naming convention.
• Third step is to create a data sheet where the data is saved in HTML format. This data will
be used by the test scripts as an alternative to hard coded test data.
• Fourth step will invoke the URL intended for testing. I like to use one selenium test case
solely to invoke the URL that can be replaced and used with other functionality.
• Last but not least, the ingredient that adds value to this concept is being able to post a
screen shot at every passed or failed step with a meaningful message as its name.
Introduction
6. Main elements in a software application are
Text fields
Check boxes
Radio buttons
Links
Menus
Captions
Images
Logos
Text
Captions
Table
Column
Every test uses some or all the elements in a page
Concept
7. First Step
Select a location on the local Drive and create the following folders in the
order specified. The folder names that are highlighted (In Bold) only will be
used for this tutorial.
8. 01_FilePath
File Path for Gmail
File path specifies the location for the Captured Screen Shots to be saved. Each
set of screen shots will be saved to a specific location with a specific naming
convention.
Type in the following paths and store as variables for Gmail, Netflix and Yahoo.
(Copy paste all the steps and modify the few names as necessary)
Save the test case as “01_FilePath_Login_Gmail” at “C:000_SeleniumIDE01_FilePath”
9. 01_FilePath
File Path for Netflix
File Path for Yahoo
Save the test case as “01_FilePath_Login_Netflix” at “C:000_SeleniumIDE01_FilePath”
Save the test case as “01_FilePath_Login_Yahoo” at “C:000_SeleniumIDE01_FilePath”
10. 02_Repository
Main elements for this User Interface are fields Username and Password, check
box Stay Signed in, button Sign in, link Cant access your account?” on page
Login; and button Username and Sign Out and any error messages.
Right click on the element and select to add with option “assertText”
Save the test case as “02_rep_Gmail” at “C000_SeleniumIDE02_Repository”
Open the test case file via Notepad. Find and replace all “assertText” with
“store”. Save, close and reload the file.
Assign suitable variables for each element and sort them alphabetically.
12. Documentation (optional)
It is certainly a good idea to
document the names for each
element along with the screen
shots.
13. 02_Repository (more about)
02_rep_(page)
Create a repository file (page) to store all the elements per page. Some pages have just 2 elements specific to the
page. Some pages have 200 elements specific to the page. This way when the User Interface or Document Object
Model or HTML IDs of the page change, it would be easy to locate the particular page and update the values
quickly.
02_rep_HomeElements
Create a repository file home to store all the home elements (links, logos, version, header, footer, menus etc.) that
are common on all the pages of a web application as the Home elements. This practice eliminates the need to
maintain the standard elements in all the individual page repository files and also eliminates the need to update
numerous files.
02_rep_Pages
Create a repository file Pages to store all the page titles. Most pages may not need individual repository files, but
it would be necessary to test their existence. Though the elements of each page are maintained in individual files,
it is a good practice to store all the page titles in a singular file.
Create 02_repPages
Go to home pages for Gmail, Netflix login and Yahoo mail. Right click anywhere on the page.
Select option “assertTitle”. Add the variable name in the column Value as such - for
Gmail add pGmail_Login, for Netflix login add pNetflix_Login, for Yahoo Mail add
pYahoo_Login.
14. 03_DataSheets
| Command | Target | Value |
| Store | GmailUsername | data_fUsername |
| Store | Abc123^^ | data_fPassword |
Save the test case as “03_data_Gmail” at “C:000_SeleniumIDE03_DataSheets”.
| Command | Target | Value |
| Store | NetflixUsername | data_fUsername |
| Store | Abc123^^ | data_fPassword |
| Command | Target | Value |
| Store | YahooUsername | data_fUsername |
| Store | Abc123^^ | data_fPassword |
Save the test case as “03_data_Netflix” at “C:000_SeleniumIDE03_DataSheets”.
Save the test case as “03_data_Yahoo” at “C:000_SeleniumIDE03_DataSheets”.
All data variables start with “data_”.
This is one more way to replace hard coded test data
15. 04_GoToURL (test case)
• In Mozilla Firefox, navigate to Gmail login page. Stop recording.
• Add (write) steps to verify title and to capture a screen shot of the page for reference.
| Command | Target | Value |
| Open | | |
| assertTitle | ${pGmail_Login} | |
| captureEntirePageScreenshot | ${FilePath}.png | |
Save the test case as “04_GoTo_Gmail” at “C:000_SeleniumIDE04_GoToURL”.
Go To URL Gmail
Go To URL Netflix and Yahoo
•Copy all the steps from test case “04_GoTo_Gmail” and paste them in the new Test Cases.
•Update “${pGmail_Login}” to “${pNetflix_Login}” and ${pYahoo_Login}
•Save the test cases as “04_GoTo_Netflix” and “04_GoTo_Netflix “ at
“C:000_SeleniumIDE04_GoToURL”.
•Via Windows Explorer navigate to the location “C:000_SeleniumIDE04_GoToURL”.
•Open the file “04_GoTo_Netflix” and “04_GoTo_Yahoo “
•Replace the URL Gmail login page with Netflix Login page and Yahoo Login page
•Save the files and close.
16. 07_LoginSteps (test case)
| Command | Target | Value |
| Type | ${fUsername} | ${data_Username} |
| type | ${fPassword} | ${data_Password} |
| clickAndWait | ${bSignIn} | |
Type in field Username the data specified for the Username;
Type in field Password the data specified for the Password;
Click button Sign In and wait for the page to load.
Note: This test case only carries out the steps for a test. It does not verify if
the test had passed or failed.
Purpose of Login Steps
17. 07_LoginPass (test case)
• Only if text Username is present execute the rest of the steps;
• Capture and save a screen shot at the specified location as PASS.
• Note: This test case executes and logs a picture as PASS, if the desired
outcome (text Username) exists.
Purpose of Login PASS
| Command | Target | Value |
| assertElementPresent | ${errUsername} | |
| captureEntirePageScr
eenshot
| ${FilePath}${Username}_PA
SS.png
| |
18. 07_LogOut (test case)
• Only if text Username is NOT present execute the rest of the steps;
• Only if field Username is present execute the rest of the steps;
• Capture and save a screen shot at the specified location as FAIL.
• Note: This test case executes and logs a picture as FAIL, if the desired
outcomes (text Username does not and field Username) exist.
Purpose of Login FAIL
| Command | Target | Value |
| assertElementPresent | ${tUsername} | |
| Click | ${tUsername} | |
| clickAndWait | ${bSignOut} | |
| captureEntirePageScre
enshot
| ${FilePath}${Username}_Log
Out.png
| |
19. Test Case Template (base test case)
For effortless and quick test case creation, I would recommend creating and
maintaining a base script. The base script will consist of all the elements needed for
writing a test case for most actions, verifications and assertions.
| Command | Target | Value |
| assertTitle | ${p} | |
| assertElementPresent | ${} | |
| assertElementNOTPresent | ${} | |
| click | ${rb} | |
| click | ${cb} | |
| click | ${l} | |
| click | ${b} | |
| type | ${f} | ${data_} |
| select | ${ddl} | ${data_} |
| captureEntirePageScreenshot | ${FilePath}${}_.png | |
20. Test Set Arrangement Order
01_FilePath
(files – 01_FilePath_First, 01_FilePath_Second, 01_FilePath_Third),
02_Repository
(files – 02_repPages, 02_repHomeElements files; If specific page or pages are
involved in the test, 02_rep (page(s)) will also be necessary in the test suit),
03_DataSheet
(optional, datasheets may be added as necessary or may be skipped for some test
sets),
04_GoToURL
(one file suffices)
The test cases should be added in ascending order till 04_GoToURL.
This is one way to create, store and guesstimate when a test case is ready and if it
is set up in order. Now, the actual test cases may be added in the order they would
execute manually.
21. Test Execution Results
Typically, all test cases are supposed to turn Green in order to assume that
the test set passed. Here, that is not the case. Certain test cases are
supposed to pass and certain test cases are supposed to fail. Each test
case will only execute if the required conditions are met.
Provide valid credentials to pass a test. Passed tests would have two
picture logs, one for navigating to the website and one for successful login.
Provide invalid credentials to fail a test. Failed tests would have three
picture logs, one for navigating to the website, one for failed login and one
for the failed login with error message.
UNKNOWN errors. We must remember that there are unknown errors. We
should leave room to capture those unknown errors. In the log in scenario,
if the Login Page or the Logged in page do not show up, an Unknown error
is logged.
25. • Most automation is record and play. This technique will execute a few steps on
an application, but won’t log full length messages, warnings and won’t do
comparisons.
• A lot of time goes into automating regression suits. A lot of effort goes into
automation. A lot of ideas go into automation. All of this effort goes waste with
a few tweaks to the UI.
• When several developers (from all over the world) developing scripts for
automation, unless there was a coding standard defined, each developer would
pursue their own style of repository naming and script writing. The automation
suits will not be consistent.
• Automated suits with various coding standards are hard to merge and maintain.
• Automated scripts created for one application cannot be used if changes are
made to the application. They will need to be updated as well.
• A test had failed due to recognition issues, by looking at the logical names in the
repository or the script alone it is not enough to identify which element needs
updating. Because sometimes several elements could be named same and
several times the names given on the page are not used for the logical name.
Conventional Automation Limitations
27. SAREE (mnemonic)
Select elements for testing
The most suitable mnemonic summon up the steps for Green Lantern
Automation concept would be SAREE. Just like a Saree, the Scripts can
be wrapped to any User Interface for testing as long as their functions
are similar.
Page
Field (text field)
Button
Check box
Radio button
Link
Menu
Sub Menu
Drop Down List
Caption
Image
Logo
Text
Section
Dialog box
28. SAREE (mnemonic)
Assert custom name to each element in the repositories.
Page pGoogle
Field (text field) pGoogle_fUsername
Button pGoogle_bSearch
Check box pGoogle_cbChose
Radio button pGoogle_rbTrue
Link pGoogle_lHome
Menus pGoogle_mMore
Sub Menu pGoogle_smTranslate
Drop Down List pGoogle_ddlSettings
Caption pGoogle_capGoogle
Image pGoogle_imgGmail
Logo pGoogle_logoGoogle
Text pGoogle_tVersion
Section pGoogle_secSearch
Dialog box pGoogle_dSuccessful
Based on the naming convention one can (with a little bit of training) can identify
that the elements belong to the page Google
29. SAREE (mnemonic)
wRite test cases with custom names
Execute the test cases in test sets
Exact the element properties in the repositories from time to time.
| Command | Target | Value |
| type | ${pGmail_fUsername} | ${data_fUsername} |
| click | ${pGoogle_bSearch} | |
| select | ${pGmail_ddlEnv} | ${data_ddlEnv} |
| assertTitle | ${pGoogle} | |
30. Typically each application has its own team of testers
and engineers to come up with scenarios for testing
and automating.
With the help of Green Lantern Framework the
testers time can be freed up to explore and
implement more scenarios across applications and UI.
Companies that focus on testing can come up with
test scripts for similar applications or domains –
Suitable Test cases, Automated scenarios and the
data files with all possible Data are ready to be used
for manual or automated testing.
Conclusion
31. Note about Automation Tools
Regression automation tools like RFT, QTP, Test Complete, Silk
Test, Selenium, etc.
have been used for regression tests.
The tools cannot test a thing. All they do is –
Click buttons
Type in text in text box fields
Click links
Click radio buttons
Check ON or OFF check boxes
Compare text
Compare Images
Compare Values
Verify an element exists.
log messages, log warning, log errors etc.
They do what we tell them to do.
The tool is only as good as the user.
