The information contained in these materials is
provided for informational purposes only, and is
provided AS IS without warranty of any kind,
express or implied. IBM shall not be responsible
for any damages arising out of the use of, or
otherwise related to, these materials. Nothing
contained in these materials is intended to, nor
shall have the effect of, creating any warranties or
representations from IBM or its suppliers or
licensors, or altering the terms and conditions of
the applicable license agreement governing the use
of IBM software. References in these materials to
IBM products, programs, or services do not imply
that they will be available in all countries in which
IBM operates.
Maximo Test Automation
The Maximo Test Automation Framework is a Java framework based on the
Rational Functional Tester (RFT) API. It is used to create automated
functional tests against Maximo-based products. Using RFT, we are able to
dynamically find and use objects in Maximo.
This framework is based on a common architecture created by the IBM
Quality Software Engineering group and it consists of four tiers:




“Appobject” classes that logically group GUI elements together by
application. These classes consist of discrete, granular private object
maps that contain a small number of related GUI elements, along with
routines that provide access to these elements.
“Apptask” tasks or methods that execute commonly-travelled paths
through the GUI.
Test cases that invoke the tasks, verify the state of the application, and
log the results.
Test suites that group a set of test cases together by function or test
area.
Test script and test suite execution depends on a properties file at execution
time. The properties file contains variables (such as the url, username,
password and database information) that define the test environment the
script will be executed against.
Automation Project Structure
The Maximo automation framework is comprised of two projects –
Common and TIVAUTOMATION (stands for Tivoli Automation). The
Common project contains utility files used to manipulate the environment
and/or test data. The TIVAUTOMATION project contains all of the
framework files used to navigate through the Maximo screens, as well as the
files that store the fields, common tasks and test cases. We will talk more
about each of these projects.
Project layout:
 Common
 Tivautomation
 com
 ibm
 tivoli
 industrysolutions
 …..
 maximo
 common
 database
 lib
 util
 widget
 uitest
 appobjects
 apptasks
 testcases
 testsuites
 ibm
Common project
The Common project is where the utility files that control the environment
and data it may use. Some examples are properties files, XML files for
MEA testing and various datastore files for runtime data manipulation.
One of the most important files for our automation execution, the
maximo.properties file, resides in this location. In this file, we specify the
url to be used, the user name and password, the database information, such
as the driver and db.url. This allows us to call these properties at runtime
instead of having the user specify them when the test is run, or to hard-code
them into test cases.
Another type of properties file found in this location is the properties file
used when the BVT (Build Verification Test) is run. When the BVT is run,
all new data is created to perform the test so that we do not need to rely on
maxdemo data. When the Setup portion of the script completes, the records
created are written to a properties file. Each of the subsequent tests reads
that same properties file to retrieve the records it needs to properly run the
script.
Tivautomation project
The Tivautomation project contains the framework files, as well as our
object getters, common tasks, test cases and test suites. The Tivautomation
project is organized into 4 folders: com, etc and ibm.
com.ibm.tivoli folder
The com.ibm.tivoli folder contains all of the Maximo-specific classes,
including the common Maximo framework tasks, as well as all of the object
getters, test cases and test suites. The folder is organized by project (core
Maximo vs. Maximo add on), and each of the projects contains a uitest
folder and 4 sub-folders in uitest: appobjects, apptasks, testcases and
testsuites, all found in subfolder called uitest (e.g.: maximo.uitest). The
Maximo folder contains the Maximo framework code used in the project.
common folder
The com.ibm.tivoli.maximo.common folder contains the Maximo
framework classes that contain the common actions across applications.
database folder
The database folder contains the class files that allow the scripts to access
and query the database.
lib folder
The lib folder contains the .jar files that a user needs to import upon project
creation to run the Maximo automation project.
util folder
The util folder houses the utility files that contain the actions that are
common across Maximo. There are files relating to MEA and how to
interact with it, browser interaction, string manipulation, and the most used
file in Maximo automation, the WebUtil file.
WebUtil file
The WebUtil file is one of the most important files in the framework. Most
of the common actions in Maximo reside in this class file.
Some examples of methods in the WebUtil file:
 click
 field, checkbox state verification
 field value verification
 browser readiness (ready, exists)
 open tabs within an application
 navigating the Go To and Select Action menus
 select a button
 select a checkbox
 select a detail menu
 select a link
 select a value from a Select Value dialog
 select a toolbar button
 set text in a field
widget folder
The widget folder contains classes that allow the user to interact with
different controls in the UI. Some of the class files contained in the folder
are files that interact with menus, checkboxes, dialogs, radio buttons and
toolbars. There are two important framework files contained in this folder,
Component and ComponentsTable, that allow a user to interact with fields
and tables.
Component class
The Component class is the class that contains the methods that allow the
scripts to interact with a text field. The method to get the text field, check
box or radio button is found in this class, as well as the methods to interact
with it once found. Once the object is found, any associated description
fields, buttons (long description, detail menu, select value) and rich text
editors can also be found.
Examples of some of the methods found in the class that interact with the
field and/or buttons:
 check or uncheck a checkbox
 clear text from a field
 verify a field, checkbox or radio button exists
 select a detail menu and select a menu item
 select a GL Account from the dialog
 select a radio button
 select a Select Value lookup and choose a value from the dialog
 set text in a field or description field
 verify the state of a checkbox
 verify the text in a field is the expected text
ComponentsTable class
The ComponenstTable class is the class that contains the methods that allow
the scripts to interact with a table. The method to get the table, as well as
methods to interact it once found, are found in this class file. Once the table
is found, the associated filter, images, New Row button, etc can also be
found.
Examples of some of the methods found in the class that interact with the
table:
 open and close row details
 delete and undelete a row
 select an image in a row
 filter the table
 get the row count
 select a button (e.g. New Row)
 select the Select All Records checkbox
 select the Select Record checkbox for a row
 select any of the table header images (e.g. Clear Filter Fields, Next
Page)
uitest folder
The uitest folder contains the object getters, application methods, test cases
and test suites. There are also a few classes located in the root that are
common actions throughout Maximo. A few examples are the BaseActions,
BaseConstants, BaseLogin, and BaseObjects classes.
BaseActions class
The BaseActions class contains actions that are common to most Maximo
applications. When a change is made to the functionality or logic of a set of
steps to complete an action, a change needs to be made in this file only.
Some examples of the common actions in the class file:
 using the various dialogs associated with Advanced Search
 change the status of a record
 manipulating the classification tree
 filtering a table on a dialog or page
 opening the Help -> System Information dialog
 using the various dialogs associated with the Profile menu
 searching for a record using the quick search field
 selecting a line type (e.g. the Line Type dropdown in the PO
application)
BaseConstants class
The BaseConstants class contains enums of some of the constants used when
creating and manipulating records in Maximo. If the name or abbreviation
of one of these is changed, an update needs to be made in this one class only.
For example:
 an enum with the names of the various statuses available when
changing a record status
 an enum with the names of the toolbar buttons
 an enum of the application names
BaseLogin class
The BaseLogin class contains code that manages logging into Maximo.
There are various methods, depending on what type of environment you are
logging into, and what type of information the user needs to provide (url,
username, password, etc).
BaseObjects class
The BaseObjects class contains most of the core object code that many of
the other class files use. When changes are made in the Maximo UI, many
of the changes are made within this class file.
appobjects folder
The appobjects folder is where all test objects and their getters are stored.
The folder is organized by application (each application has its own folder),
and the classes within the folder are organized by main application page and
then by dialog.
Examples:
- The assets folder contains a class called AssetPage, which contains
all objects found on the tabs in the Assets application.
- The assets folder contains a class called ChangeItemNumberDialog,
which contains all objects found in the Change Item Number dialog.
The appobjects file is organized by object (field, table, menu item, tab) title
and the getter. By keeping all of the labels and getters in one place, if a field
(or tab, table, or menu item) name changes (or a client customizes a label),
updates only need to be done in one place, and test cases will continue to
run.
Example:
- public final static String ASSET = “Asset”; is the definition of the
Asset field label. The object getter will use this label to find the field
and its associated description field, and any associated icons. If the
Asset field label changes, it only needs to be changed in this one place
instead of in every test case that uses the getter.
apptasks folder
The apptasks folder contains all application-specific method libraries.
Like the appobjects folder, the apptasks folder is organized by application,
and the classes within the folder are organized by main application page and
then by dialog.
Methods contained in these files are things like a new record creation,
adding table records to a record, etc. Reusable methods that are specific to
one application reside in this location. If a change is made to logic or
process, a change needs to be made in just one place instead of within test
cases, allowing the test cases to continue to run.
testcases folder
The testcases folder contains all test case files, organized into folders by
their function (e.g. Build Verification Test (BVT)), and/or their functional
area (e.g. inventory).
testsuites folder
The testsuites folder contains all test suite files, consisting of suite files
compromised of classes from the testcases folder.
ibm folder
The ibm folder contains the core common IBM framework classes such as
the Widget class and the VisualReporter logger class. The ibm folder
contains subfolders that contain libraries of core automation classes that
complement the Rational automation classes. The folders are broken down
into several categories such as loggers, tools, util, widgets, etc.
loggers folder
The loggers folder contains the class files for the custom logging available in
the Maximo automation framework.
widgets folder
The widgets folder contains the class files for the different object types used
in the automation framework. The class files in this folder contain the
getters for the various widgets available to the tester. These widgets are
used to get the objects in Maximo and are extended in the framework to
manipulate the widgets.
Some of the widgets contained in this folder are button, checkbox,
combobox, image, link, radio button, static text, table and text field.
Examples of how the classes interact with each other :
From the Assets appobjects class:
/** text field label for "Asset" */
public final static String ASSET = "Asset";
/** get text field "Asset" */
public Component getTextField_Asset()
{
return new Component(ASSET);
}
From the Assets apptasks class:
public void createNewAsset(boolean goToApp, String asset, String
assetDescription, String parent, String location, String vendor, String
manufacturer, boolean saveRecord)
{
VisualReporter.logTestCaseInfo("Create asset " + asset);
if (goToApp)
goto_Assets();
// Insert a new asset
insert();
// Give it a name and description
assetsPage.getTextField_Asset().setText(asset);
assetsPage.getTextField_Asset().setText_Description(assetDescription);
....
The createNewAsset method calls the appobject (field getter) for the Asset
field from the appobjects class. The setText and setText_Description
methods are called from the Component class.
If you wanted to change the Asset’s status to Active, the changeStatus
method is called from the BaseActions class. The constant Active from the
BaseConstants class is used as the status.
BaseActions.changeStatus(Status.Active);
The WebUtil class is used in many different ways in test cases. Examples:
To go to a tab within an application, the openPage method is called from
WebUtil, and the tab name comes from the appobjects class.
WebUtil.openPage(AssetsPage.TAB_ASSET);
To select a menu item from the Select Action menu, the selectAction method
is called from WebUtil and the action name comes from the appobjects
class.
WebUtil.selectActionMenu(AssetsPage.SA_MANAGEMETERREADINGHISTORY);