TestComplete - PNSQC - published in 2011

 

 Introduction

Original presentations can be found on PNSQC.com 

Many companies have invested in test automation tools in hopes that the automation tool will free up manpower by taking over regression testing. The automation tools look at the skins and DOMs of the applications. They are identified by the properties assigned to the elements. (A cell could be identified by the “Row and Column”, a table can be identified by “number”, a link can be identified with ‘inner HTML or text”, and so on.)

When the skin and the Document Object Model of an application changes a lot or little, it becomes unavoidable to update and change the automation scripts a lot or a little too. And if the application User Interface was completely changed (for any reason) the automated scripts will need to be recreated from scratch.

In one of my roles as an automation engineer, I was in charge for creating test scripts for three different interfaces that used the same back end. Their functionality was same, but their user interface was completely different. I started off as everybody - creating scripts for each User Interface. But it felt like too much hard work but like “too little smart work”. So, I needed a framework where I could avoid script death by eighty percent and increase re-usability by eighty percent. I needed a disruptive framework. That is when I came up with “Green Lantern Framework”

Using the renaming feature of the automation tool that relies on the Document Object Model, the test scripts could be created once and used no matter how much the User Interface changed or the even the Document Object Model changed. For example automated test scripts created for Gmail Log-in page can be used for Yahoo Log-in page, Hotmail Log-in page or any log-in page with a user name and password.

 I will demonstrate creating automated scripts using Green Lantern framework with the tool Test Complete and scripting language VBScript.

Assumptions

1. Audience is familiar with automation tools.

2. Familiar with Record and Play 

3. Familiar with Capture and Script

4. I am positive that you can take this concept and make it your own and implement it with the automation tool of your choice.

5. This tutorial Is not about explaining the pros and cons of automation. It is about a new framework that mainly focuses on saving the automation script to handle UI & DOM changes. It simultaneously enables us to write our scripts in English (literally)

Note About Automation Tools

Automation tools like QTP, TestComplete, Selenium, Etc. have been used for regression tests. The tools cannot test a thing. All they can do is - 

1. Type in fields

2. Click buttons

3. Click Links

4. Click Radio buttons

5. Check ON or OFF check boxes

6. Compare text

7. Log messages, Warnings, Errors, etc.

They only perform user actions we told them to perform and give us data we fed them, like PASS or FAIL.

The tools are only as good as the user. If the user does not properly communicate with the tools, the tools can only do so much.

 Green Lantern Steps

Select elements for testing (Capture to repository)

Assert custom name to each element and categorize them per their type (Field, checkbox, radio button, etc.)

wRite test scripts using the pseudonym names

-       Write a routine for each element

-       Routines for text fields should have data coming from external Data sheets

-       Checkboxes are checked ON or OFF via Data Sheets

-       Log messages, Warning, Errors should be written in the script routine

Execute the test cases in test sets

Exact the element properties in the repositories from time to time.

Concept –

Main elements in a software application are

·         Text fields

·         Check boxes

·         Radio buttons

·         Links

·         Menus

·         Captions

·         Images

·         Logos

Every test uses some or all of the elements in a page. These elements are captured and categorized and named as they display. Every test uses some or all of the elements in a page. When these elements are captured and categorized and named the way they would display, it is easy to identify every element, easy to write a script, easy to detect element recognition failures, etc.

Choose elements for automating login function

Elements essential for Logging into a web page are the URL, the fields - User Name and Password, and button – Sign In.

elements necessary for the test from Gmail Login page

Capture the elements to the repository

Capture the elements the fields - User Name and Password, and button – Sign In from the Gmail Login page. (Example – Figure 2)

Gmail Login elements Original

 Notice that the logical names of the elements are not as they would display on the actual User Interface.

 Rename the logical names of the elements

Drag these elements to the aliases section and rename them in English as they display on the UI.

Rename as such - 

Firefox = MF

GmailLogin = Gmail_Login

Username (in Gmail) = UserID

Password = Password

Sign In = SignIn

Stay signed in, = StaySignedIn

Can’t access your account?  = ForgotPasword

Gmail Login elements renamed and categorized

Categorize the elements per their type

To categorize, choose element “panelLoginbox” (which is the parent element for all the field, checkbox, button, link elements). Drag this element and add it under Gmail and rename it as “Field”. Add elements UserID and Password under the Field. Drag “panelLoginbox” again to Gmail and rename it as “Checkbox”. Add element “StaySignedIn” under the Checkbox. Drag “panelLoginbox” again to Gmail and rename it as “Link”. Add element “ForgotPassword” under the Link. Drag “panelLoginbox” again to Gmail and rename it as “Button”. Add element “SignIn” under the Button. The end result with look like Figure 3 (Collapsed on the right and expanded on the left).

 Test Scripts

Write scripts using the pseudonym names

• Write a routine (function) for each element

• The first part of the routine refers to the page or Window.

• The second part of the routine refers to the type of element that needs to be used for the routine.

• The third part of the routine refers to the name of the element used for testing.

• The fourth part of the routine will refer to the actions to be executed.

• Routines for text fields use external datasheets.

• Log Messages, Warnings, errors are written in the routine.

Using the renamed Aliases elements, it will be effortless and uncomplicated for a new-comer or an experienced programmer to write scripts.  (Note - Naming the elements and categorizing them can be decided upon studying the Document Object Model, properties of elements and such.)

File per page not action

File per page

1. All the routines for dialog boxes are saved to file named - dialog.

2. All routines for elements of a particular page are saved to file named after the page.

3. The routines are named after the element name as such - pOne_fPassword

4. Maintaining a separate file per page of elements makes it easy to go back and edit the routines when need be.

5. Routines for page elements are listed in Alphabetical order, making it further more easy to get to the routine needed. 

Routine for the field User ID

Step1. Start with “Aliases.”

Step2. Call the Page or Website you wish to use for the test. In this instance it is Gmail_Login element. So add – “Aliases.Gmail.”

Step3. Call the type of element you want to use for the test. In this instance it is the Field element. So add – “Aliases.Gmail.Field.”

Step4. Call the element you want to use for the test. In this instance it is the UserID element. So add – “Aliases.Gmail.Field.UserID”

Step5. Call the function the step is supposed to perform with the element. A textbox field can either enter “text” or type in “Keys”. So add = “Aliases.Gmail.Field.UserID.Keys.”

Step6. Text or Values to be used could be static or dynamic. I like dynamic. I like to drive my data from the external datasheet. This way any member of the team can come up with the data they would like to use, without ever touching the test scripts. So add = “Aliases.Gmail.Field.UserID.Keys(DDT.CurrentDriver.Value("UserID"))”

Step7. I like to perform a few more steps before I input the indented UserID. I like to remove any pre-existing text that might be in the field. For this purpose I copy paste the above code twice and replace the (DDT.CurrentDriver.Value("UserID")) with (“^a”) from the first line to select all the existing text.  Replace  the (DDT.CurrentDriver.Value("UserID")) with (“[Del]”) from the second line to delete all the existing text. So copy and paste and modify the lines to - Aliases.Gmail.Field.UserID.Keys(“^a”); Aliases.Gmail. Field.UserID.Keys(“[Del]”)

Step 8. Insert a message in the log to know which UserID was used. So add – Log.Message(“User ID = ” + Aliases.Gmail_Login.Field.UserId. Value)

Step 9. Name the routine to match the element.  

Routine for field User ID

Routine for the field Password

Step1. Copy paste the UserID routine and replace the value “UserID” with “Password”. The routines for all fields in an application can be easily written like this, saving a lot of time and energy.

Routine for field Password

Routine for the button Sign In

Step1. Copy and paste the UserID routine. Remove the 2nd and 3rd and 4th lines.

Step2. Replace the value “Field” with “Button”.

Step3. Replace the value “UserID” with “SignIn”.

Step4. Replace the value “Keys (“^a”) with “Click ()”.

Step5. Insert a message to the log to suggest button Sign In was clicked on.. So add – Log.Message("Clicked button Sign In")

Step6. Rename the routine to match the element name and type.  

Routine for button Sign In

Routine for the checkbox Stay signed In

Step1. Copy and paste the Sign In routine. Remove the 2nd line.

Step2. Replace the value “Button” with “Checkbox”.

Step3. Replace the value “SignIn” with “StaySignedIn”.

Step4. Replace the value “Click() with “Click(false)”.

Step5. Insert a message to the log to suggest the check box Stay Signed In was checked ON. So add – Log.Message("Uncheck check box Stay Signed In")

Step6. Rename the routine to match the element name and type.  

Routine for checkbox Stay Signed In

Routine verifying the login

Routine for verifying login

Routine calling all the Login steps

Routine to combine all elements for login Function

 Main routine for validating the function Login

Many steps, ideas, routines, conditions, go into it. The end result would more or less look like this

Script for Login Routine

Test run results (Log files)

Run the final script

Actions performed - 

1. User name is typed in

2. Password is typed in

3. Checkbox is check ON 

4. Sign in button is clicked.

The end result of a test run log would more or less look like –

1. Gmail LogIn with Browser Mozilla Firefox

2. URL = www.gmail.com (URL text comes from data sheet)

3. UserID = Srilu.Balla (URL text comes from data sheet)

4. Password =                        (URL text comes from data sheet)

5. Gmail Invoked via Mozilla Firefox

Gmail login Test Result

A lot of work went into the Login script. (Phew)

 User Interface Change to Hotmail

Now imagine the Gmail login User Interface changes from Gmail to Hotmail or yahoo. All the time, effort and ideas put into creating the original script have to be redone in most conventional conditions. But with Green Lantern framework the script is safe as long as there is a repository that matches it.

If the aliases DOM’s for Hotmail and Yahoo are prepared similar to the aliases DOM for Gmail, the Scripts will work with little or no modification and log similar messages and check for similar functionality.

 Green lantern Steps for Hotmail Login

Step1. Select elements to repository. 

Select elements to repository

Step2. Assert the elements new names and category by type and rename the logical names to match the aliases names for the Gmail login page. 

Assert elements

Step3. Copy paste the Login Script for Gmail - Open a blank script and name it Yahoo_Login and Copy paste the Gmail Login Script

Copy paste same script

Step4. Replace “Gmail” with “Hotmail” using ‘find and replace’ (Ctrl + H)

Replace text

Step5. Verify the replaced text and run the script.

Verify change of text

Run script

The test results would look similar to that of Gmail.

 Test run results (Log files)

The end result of a test run log would more or less look like and reads-

1. Gmail LogIn with Browser Mozilla Firefox

2. URL = www.mail.yahoo.com (URL text comes from data sheet)

3. UserID = srilu_kiku (URL text comes from data sheet)

4. Password =                        (URL text comes from data sheet)

5. Hotmail Login Successful.

 Green lantern Steps for Yahoo Login

Yahoo login screen repository

Test Results

Yahoo login Test Result

 A few issues with conventional automation

Script without Green Lantern

-       Most automation is record and play. This technique will execute a few steps on an application, but wont 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 User Interface.

-       Several developers (from all over the world) are 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.

 Many UI's with similar functionality

Typically each application has its own team of testers and engineers to come up with test scenarios adn automation. 

With Green Lantern Framework the testers' time can be freed up to be better utilized 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 could be made ready to be used for manual or automated testing.

 Conclusion

If this framework is understood correctly, engineers using it can create automation scripts way before the application is developed. Most routines can be utilized over and over after changin a few names in the routines which can be accomplished via find and replace (Ctrl+H).

Several applications with similar functionality could use the same routines and scripts that were already created. Now, the engineer and the testers can come up with more scenarios.

Green Lantern Framework is compatible with the tool TestComplete. Automation tools – Quick Test Professional, Rational Functional Tester, Selenium etc also can have reusable scripts. The approach to these tools varies from the current approach but the concept is similar.

Changes in the DOM and the User Interface of any application is inevitable. During such situations automation script death is inevitable. Many automation tools have a feature to rename the elements being used for tests. When these elements are cleaverly and clearly renamed to suit the elements (also making it easy to remember during script creation), script death can be minimized or altogether avoided and simultaneously the reusability of the script can be increased.

I would like my learned and knowledgeable colleagues to test and question these ideas. I need their invaluable advice, guidance and participation to enhance this framework and to implement on other automation tools.