TEST MANAGEMENT TOOLS Quality Center (QC/ALM)  Bugzilla  Perforce  Jira TESTING Functional Test  Test Automation  Test Scripting  Regression Unit Testing and Databases  TestCases  Defect Reproduction and Logging BACKEND TESTING API testing  WebServices Automation  SOAP  WSDL  RESTful HTTP  Security  Encryption MOBILE OS: Android, iOS

1. Introduction to the integral
Framework
INTRODUCTION
TO THE
INTEGRAL FRAMEWORK
BY
KARTHIK SUBRAMANIAN
https://www.linkedin.com/in/karsub1
karsubp@gmail.com

2. Introduction to the Integral Framework
One definition of the word Integral is: consisting or composed of parts
that together constitute a whole.
The focus of this framework is Simplicity. By creating and maintaining
easy-to-understanding parts, it is possible to create and maintain an
easy-to-understand whole. Simplicity here means minimizing the key
resources involved in the framework and making sure those resources
follow clear lines of communication with each other.
The Integral framework places a majority of its emphasis on Description
Objects, Component Scripts and Actions, Function Libraries (VBS files),
Driver Scripts and Actions and Master Scripts and Actions. The
Following Diagram shows a simplified hierarchy of these resources.

3. VBS
Components
Master
Driver Driver Driver
VBS

4. Description Objects
Instead of using the Object Repository feature in Quick Test Pro
(QTP), each component action will use explicitly defined
Description Objects which are property name/value collections
used to identify an object within the Application Under Test
(AUT)
Component Scripts
Component Scripts are composed of very small, reusable,
automated pieces of functionality within the AUT. Examples of
component actions include entering text in a field or clicking on a
Button

5. Function Libraries
External functions and subroutines written as VBS files can be
an extremely valuable way to reuse code in an automation
framework
Driver Scripts
Driver Scripts are composed of reusable actions that dictate the
order in which component actions are executed so that a user
experience in simulated. The focus of a driver script is on page-
specific activity.

6. Master Scripts
Master Scripts decide the order in which driver scripts are executed so that
a full, end-–to-end test scenario can be simulated. The focus of a master
script is on system-wide activity
Component Scripts
Each component script contains a collection of reusable actions that can
be used to manipulate or validate objects on a particular screen in the
AUT. Separate component scripts should be created to handle areas of the
screen that appear on more than one screen (e.g. a navigation banner at
the top of the left of the screen that appears on most of the screens).
Popup windows and dialogs should be considered different screens within
the AUT and should have corresponding component scripts as well. The
following illustration shows how each object on the AUT screen has a
corresponding reusable action in the component script

7. Component script Application Under Test
= Reusable Action
Login
Username
Password
Login
Enter Username
Enter Password
Click Login
Component script Application Under Test
= Reusable Action

8. Component Action Types
There are two main types of component actions within
the Integral Framework: manipulation actions and
validation actions. Manipulation actions are those
actions that do something to an object on the
application’s user interface. Validation actions are
those actions that check something in the system,
comparing an expected value against an actual value
or application state. The following illustration shows
how component actions can be used to validate or
manipulate specific objects in the AUT.

9. Component script Application Under Test
ValUsername
ValTodaysDate
ClickStart
Welcome
Welcome SunRaise!
Today’s Date: January 1, 10
Start
Component script Application Under Test
= Reusable Action

10. Creating Component
Scripts/Actions

11. Input Parameters
Input parameters are used to pass information to reusable component
actions. An action that handles entering text into a text field will have an
input parameter that specifies what text should be entered into the field.
Input parameters, depending on the parameter type (i.e. String, Number,
Boolean, etc.), might utilize a default value when a similar value will often
be passed into the action.
Output Parameters
Output parameters can be used to return information back to the calling
driver action. Output parameters are typically used to retrieve information
that is generated by the AUT and that is needed later during the
automated script’s execution

12. Referencing External Files
When multiple components actions use very similar code to perform their
object manipulations, the code is a good candidate for reuse by moving it
to an external file. The following illustration shows how two component
actions that contain similar code can reuse code by moving the logic to an
external file and simply calling the external file.
WebEdit_EnterText.vbs

13. Moving code to an external file not only allows the code to be
referenced more easily by component actions but it also allows
for simpler maintenance of the code since it’s only in one place.
Imagine if the logic of enter text was in 500 components actions
and then had to be updated. One would have to make the logic
update in 500 places instead of just one.
Use the ExecuteFile command in QTP to retrieve the external
file and put the file’s code into memory for execution. In the
previous example, Both EnterUsername and EnterPassword
actions would need to perform the following command before the
calling the subroutine in the external file.
ExecuteFile “WebEdit_EnterText.vbs”

14. Description Objects
The Integral Framework uses description objects instead of object
repositories to identify objects in the AUT. Using description objects
allows the engineer to be very specific when defining the property
names and values to use when identifying the object being
manipulated or validated. Storing property names and values in
object repositories requires additional space and processing during
script execution since it forces QTP to create and reference an XML
file where all the property names and values are stored and then
create description objects based on those properties. It also avoids
identifying similar fields on different pages. By manually creating
description objects, engineers can save space and skip extra
processing required by QTP.

15. The following example code shows how to create a description
object and assign a property or properties name/value pair to it.
‘Set aside memory for the description object variable
Dim descrWebEdit
‘Create the description object and assign it to the variable
Set descrWebEdit=Description.Create()
‘Add the Property to our object, supplying as the property value
descrWebEdit(“name”).value=”MyfeildName”
Note: Use the Object Spy tool in QTP to discover the properties
that uniquely identify the object being manipulated or validated.

16. Piecing It all Together: Using Component Actions
The following diagram shows an example of everything discussed thus
far.
“SunRaise” is passed into the component action EnterUsername as an
input parameter. Because EnterUsername handles only entering text into
the Username fields, the action only needs to: (1) identify the
field being manipulated, and (2) enter text into the field. Step (1) is
handled by creating a description object that uniquely identifies the field
on the screen. Step (2) is handled by the external file
WebEdit_EnterText.vbs which contains a subroutine of the same name.
To enter text into the password field, the engineer would create a
component action called EnterPassword where a description object is
created to uniquely identify the Password field, and then make a call to
the same WebEdit_EnterText.vbs.

18. Driver Scripts
Each driver script contains reusable actions that call component actions in
a particular order to simulate a user experience on a particular screen in
the AUT. While component actions focus on a particular field or object on a
screen, driver actions focus on manipulating more than one object on the
screen
A user experience on a particular screen may involve manipulating one or
more pop-up windows or may require navigating to and from another
screen in the application in order to complete the activity. Manipulating
pop-up windows and /or navigating to another screen should take place
within the same driver action if, and only if, those extra steps are necessary
to the activity.
Driver scripts control which specific data is passed to the component
actions it calls i.e. the username “SunRaise” should be passed from the
driver action as an input parameter to the component action
EnterUsername

19. Driver Action Types
There are two main types of driver actions within the Integral framework:
Independent actions and dependent actions. Independent actions are
those actions that can be executed regardless of the application state.
Dependent actions are those actions that can execute successfully only if
the application is in a particular state (i.e., on a particular screen).
An example of an independent action might be creating a new user
account in the system. An action such as creating a new record that does
not rely on any other record being created previously can usually take
place at any time while in the application. As long as the automated test
can perform the necessary actions to return the application to a ‘start’ state
(e.g. returning to a home page or login screen), the independent action
can execute successfully.

20. An example of dependent action might be performing a task on the
fourth screen in a wizard-like sequence of screens. Without first
executing the actions that correspond to the previous screens in the
wizard, the dependent action cannot execute successfully.
Creating a Driver script
The reusable actions that make up a driver script should be named
in a way that clearly and concisely describes what the action is doing
on the particular screen. An example might be AddUserAccount for a
driver action that simulates entering in information for a new user
account, submitting that information to the system and performing
validation to ensure that the activity was successful.

21. Piecing It All Together: Using Driver Actions
The following illustration shows a driver action that enters a
username and password and then clicks the Login button –
in that order - to simulate a user logging into the system.
Note that “…”denotes QTP Syntax that has been removed
in this document

22. Component Action
Component Action
Component Action
Application Under Test
WebEdit_EnterText.vbs
WebButton_Click.vbs
RunAction “EnterUsername”, …. ,”SunRaise”
RunAction “EnterPassword”, …. ,”Password”
RunAction “ClickLogin”, …
EnterPassword
Click Login
EnterUsername
Code to
Enter text
Code to
Enter text
Login
Username
Password
Login
SunRaise
**********
Driver Action: Login
WebButton_Click.vbs

23. Data Scenarios
A data scenario is a collection of specific data that are used to
populate fields, act as expected values for validations and otherwise
drive an action to simulate the information a user might input into the
system and expect to receive from the system as output. As an
example, imagine that there are two user accounts in the system.
Each user account has an associated username and password that
must be used together in order to gain access into the system. The
following table represents two possible data scenarios that could be
used for the driver action Login shown above
Username Password
1 SunRaise SunPassword1
2 Moonlight CoolWinter

24. By referencing the first data scenario in the Login driver action, the
automation would simulate logging into the system as SunRaise. By
referencing the second data scenario, the automation would
simulate logging into the system as Moonlight. Note that the driver
action would not have to be changed at all in order to perform either
simulation. It would only be necessary to manage what input data
was supplied to the component actions called in the driver action.
This is where driver action input parameters are introduced.
Input Parameters
Input parameters are used to tell the driver action which data
scenario to use. Like component actions, a default value can be
assigned to be input parameter for the driver action.

25. Piecing it All Together: Using Data Scenarios
The following illustration shows how a call from master action can
dictate which data scenario is referenced by a driver action, thereby
determining how the driver action will simulate a user experience.

27. Referencing External Files
There are two types of external files within the Integral Framework:
AUT-focused libraries and framework – focused libraries. AUT-
focused libraries are the functions and subroutines that are used by
component actions to manipulate or validate the AUT. Framework-
focused libraries are the functions and subroutines that are used
within the framework itself to control execution flow and data.
Most AUT-focused libraries can be thought of as replacing the code
that QTP automatically generates during a recording of an action.
QTP might generate the following line after clicking a web button.
Browser(…).Page(…).WebButton(…).Click

28. The Integral Framework uses a description object to uniquely
identify the WebButton, and then passes that description object to
the WebButton_Click subroutine managed in the external file
WebButton_Click.vbs
Framework – focused libraries are designed to make the framework
more easily maintained and flexible by implementing code reuse.
Framework-focused libraries can contain functions that handle
commonly used tasks (e.g. formatting data in a particular way) or
dictate how the automation test should be executed (e.g. how many
times an action should be executed and which data scenario to use)
.

29. Master Scripts
Each master action will contain only calls to driver actions in a
particular order that simulates a user experience across more than
one screen in the system. Each call to a driver action also contains
the row number of the data scenario to use while executing. If more
than one row number is supplied, the driver action will be executed
once for each row number supplied and in the order that the
numbers are supplied. This functionality should be implemented in
the driver actions using a separate VBS file.

30. KARTHIK SUBRAMANIAN
https://www.linkedin.com/in/karsub1
karsubp@gmail.com
Meet The Expert
Selenium – Page Object Framework Overview