IBM Assumptions Audience is familiar with Selenium IDE or other - - PowerPoint PPT Presentation

Srilu ilu Pi Pinjal jala a (Srid

idevi)

IBM

• Audience is familiar with Selenium IDE or
• ther 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

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.

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

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

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

First Step

Select a location on the local Drive and create the following folders in the

• rder specified. The folder names that are highlighted (In Bold) only will be

used for this tutorial.

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_SeleniumIDE\01_FilePath”

01_FilePath

File Path for Netflix File Path for Yahoo

Save the test case as “01_FilePath_Login_Netflix” at “C:\000_SeleniumIDE\01_FilePath” Save the test case as “01_FilePath_Login_Yahoo” at “C:\000_SeleniumIDE\01_FilePath”

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 “C\000_SeleniumIDE\02_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.

02_Repository

Create repository for Netflix and Yahoo in a similar fashion. 02_rep_Netflix 02_rep_Yahoo

Documentation (optional)

It is certainly a good idea to document the names for each element along with the screen shots.

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.

03_DataSheets

| Command | Target | Value | | Store | GmailUsername | data_fUsername | | Store | Abc123^^ | data_fPassword |

Save the test case as “03_data_Gmail” at “C:\000_SeleniumIDE\03_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_SeleniumIDE\03_DataSheets”. Save the test case as “03_data_Yahoo” at “C:\000_SeleniumIDE\03_DataSheets”.

All data variables start with “data_”. This is one more way to replace hard coded test data

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_SeleniumIDE\04_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_SeleniumIDE\04_GoToURL”.

• Via Windows Explorer navigate to the location “C:\000_SeleniumIDE\04_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.

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

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
• utcome (text Username) exists.

Purpose of Login PASS

| Command | Target | Value | | assertElementPresent | ${errUsername} | | | captureEntirePageScr eenshot | ${FilePath}${Username}_PA SS.png | |

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
• utcomes (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 | |

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 | |

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.

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.

Gmail Login - PASS Gmail Login - FAIL

Netflix Login - PASS Netflix Login - FAIL

Yahoo Login - PASS Yahoo Login - FAIL

• 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

Many UI’s with similar function

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

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

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} | |

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

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.

THE END

http://www.linkedin.com/in/SriluPinjala http://sriluballa.wordpress.com Srilu.PNSQC@Gmail.com Subject: PNSQC – Green Lantern