User Guide

FOR VERSION 2.6.5

 User Guide

Table of content
1. Introduction _________________________________________________________________________ 6
1.1 TERMS AND ABBREVIATIONS __________________________________________________________ 6
1.2 REQUIREMENTS ___________________________________________________________________ 6
1.2.1 Optimal hardware configuration __________________________________________________ 6
1.2.2 Supported platforms __________________________________________________________ 6
1.2.3 Supported Java™ versions _____________________________________________________ 7
1.2.4 Additional softwares __________________________________________________________ 8
1.2.5 Privileges ___________________________________________________________________ 8
1.3 TESTMANAGER INSTALL _____________________________________________________________ 8
1.3.1 The TestManager™ download / update site ________________________________________ 8
1.3.2 Download of the TestManager™ installer __________________________________________ 9
1.3.3 Installation _________________________________________________________________ 10
1.4 LICENSING ______________________________________________________________________ 10
1.4.1 Online Licensing ____________________________________________________________ 10
1.4.2 Offline Licensing ____________________________________________________________ 11
1.5 W ORKSPACE ____________________________________________________________________ 12
2. TestManager setup __________________________________________________________________ 13
2.1 TESTMANAGER SETTINGS __________________________________________________________ 13
2.1.1 TestManager/Configuration/log4j.ini _____________________________________________ 13
2.1.2 TestManager/Configuration/config.ini ____________________________________________ 13
2.1.3 Content of TestManager/TestManager.ini file ______________________________________ 13
2.2 GENERAL PREFERENCES ___________________________________________________________ 14
2.2.1 Build information ____________________________________________________________ 15
2.2.2 Label Decorations ___________________________________________________________ 16
2.2.3 Datapool configuration ________________________________________________________ 17
2.2.4 Report transformer configuration ________________________________________________ 18
2.2.5 Resource Browser configuration ________________________________________________ 18
2.3 PERSPECTIVE OVERVIEW ___________________________________________________________ 18
2.3.1 TestManager Design perspective _______________________________________________ 19
2.3.2 TestManager Debug perspective _______________________________________________ 21
2.3.3 TestManager Datapool perspective______________________________________________ 22
2.4 EDIT_RUN_PARAMETERS DATAPOOL SETTINGS _______________________________________ 22
2.5 SVN SETUP _____________________________________________________________________ 25
3. Test projects _______________________________________________________________________ 27
3.1 PROJECT OVERVIEW ______________________________________________________________ 27
3.1.1 Create Project ______________________________________________________________ 27
3.1.2 Import project _______________________________________________________________ 30

Page 2 of 116
 User Guide

3.1.3 Convert project _____________________________________________________________ 31

3.2 RELATIONS BETWEEN PROJECTS______________________________________________________ 32
3.3 T24 CONNECTION SETUP ___________________________________________________________ 34
3.3.1 Browser connection __________________________________________________________ 34
3.3.2 Desktop connection __________________________________________________________ 35
3.3.3 Common connection setup ____________________________________________________ 35
4. Basic design _______________________________________________________________________ 37
4.1 STRUCTURAL OVERVIEW – HOW TO PLAN A TEST SCENARIO __________________________________ 37
4.1.1 Organizing test scenarios _____________________________________________________ 37
4.1.2 Creation of TSC structure _____________________________________________________ 37
4.1.3 Test Scenario Overview ______________________________________________________ 39
4.2 VERSION, ENQUIRY, REPORT ________________________________________________________ 39
4.3 VALUES, EXPECTED VALUE CHECKS ___________________________________________________ 41
4.4 HELPERS, DYNAMIC VALUES _________________________________________________________ 45
4.5 OTHER DESIGN OBJECTS ___________________________________________________________ 47
4.5.1 T24 COS __________________________________________________________________ 47
4.5.2 T24 TAB ___________________________________________________________________ 48
4.5.3 T24 Arrangement Architecture _________________________________________________ 48
4.5.4 Change company____________________________________________________________ 48
4.5.5 Java Script and jAgent ________________________________________________________ 48
4.6 IMPORT/EXPORT TEST SCENARIOS ____________________________________________________ 49
5. Basic execution _____________________________________________________________________ 50
5.1 EXECUTION WITH XMLINEXECUTOR____________________________________________________ 50
5.2 EXECUTION MONITORING ___________________________________________________________ 51
6. Log analysis ________________________________________________________________________ 52
6.1 XMLOUT, IOXML ________________________________________________________________ 52
6.2 INFORMATION IN RESOURCE BROWSER _________________________________________________ 54
6.3 GRAPHS _______________________________________________________________________ 55
6.4 TESTMANAGER LOGS ______________________________________________________________ 55
7. Advanced design ____________________________________________________________________ 57
7.1 PACKAGES, PARAMETERS (INPUT, OUTPUT, LOCAL)________________________________________ 57
7.1.1 Design a pack ______________________________________________________________ 57
7.1.2 Create package _____________________________________________________________ 57
7.1.3 Call a pack _________________________________________________________________ 60
7.1.4 Local parameters ____________________________________________________________ 62
7.2 DATAPOOLS_____________________________________________________________________ 63
7.3 MULTI-LEGGED TRANSACTIONS _______________________________________________________ 64
7.4 POPUP WINDOWS _________________________________________________________________ 64
7.5 T24 AA AUTOMATION _____________________________________________________________ 64

Page 3 of 116
 User Guide

7.5.1 AA datapools _______________________________________________________________ 65

7.5.2 AA tab on Resource Browser __________________________________________________ 69
7.5.3 Automate AA New Arrangement ________________________________________________ 69
7.5.4 Expected value checking in AA _________________________________________________ 72
7.5.5 Using AA in See mode _______________________________________________________ 72
7.5.6 Automate AA Activities _______________________________________________________ 73
7.5.7 Executing AA Test Scenarios __________________________________________________ 76
7.5.8 Non-english language support__________________________________________________ 76
7.5.9 AA Troubleshooting __________________________________________________________ 76
8. Complex methods ___________________________________________________________________ 77
8.1 DATAPOOL ITERATION _____________________________________________________________ 77
8.2 XPATH ________________________________________________________________________ 79
8.3 MULTI PHASE, MULTI DAY SCENARIOS __________________________________________________ 79
8.3.1 Phases ____________________________________________________________________ 79
8.3.2 Days ______________________________________________________________________ 80
8.4 CONDITIONAL EXECUTION CONTROL ___________________________________________________ 81
9. Non-English language support _________________________________________________________ 82
10. Advanced execution _______________________________________________________________ 82
10.1 SUITES ________________________________________________________________________ 82
10.1.1 Create Suite ________________________________________________________________ 83
10.1.2 Suite structure ______________________________________________________________ 83
10.2 MAIN SUITE, STANDALONE SUITE _____________________________________________________ 85
10.3 SEQUENCE TYPES ________________________________________________________________ 86
10.4 ERROR HANDLING SUPPORTS ________________________________________________________ 86
11. Reporting ________________________________________________________________________ 87
11.1 REPORTS FROM EXECUTION LOG _____________________________________________________ 87
11.2 REPORTS FROM DATABASE (BIRT) ____________________________________________________ 88
12. Interfaces ________________________________________________________________________ 90
12.1 INTERFACE DESIGN _______________________________________________________________ 90
12.2 INTERFACE CONNECTIONS IN INTERFACE ENGINE _________________________________________ 90
13. Recording _______________________________________________________________________ 92
13.1 THE RECORDER VIEW _____________________________________________________________ 92
13.2 PREPARATION FOR RECORDING – BROWSER, HTTP/HTTPS _________________________________ 93
13.3 RECORDING_____________________________________________________________________ 95
13.4 THE SESSION FILE ________________________________________________________________ 96
14. Regression testing _________________________________________________________________ 98
14.1 BASELINE RUN, CONTROL RUN – GENERAL METHODOLOGY __________________________________ 98
14.2 DIFFERENCES, MAINTENACE _________________________________________________________ 99
14.3 COMPARE VIEW _________________________________________________________________ 100
14.4 DEFECT HANDLING _______________________________________________________________ 101

Page 4 of 116
 User Guide

14.5 DEFECT REPORT ________________________________________________________________ 101

14.6 DEFECT SYNCRONIZATION _________________________________________________________ 101
14.7 ERROR REPORTING ______________________________________________________________ 102
15. TestManager Methodology _________________________________________________________ 103
15.1 REGRESSION TEST’S PHASES _______________________________________________________ 103
15.1.1 Test planning ______________________________________________________________ 103
15.1.2 Test design/implementation ___________________________________________________ 103
15.1.3 Test execution _____________________________________________________________ 106
15.1.4 Test analysis ______________________________________________________________ 106
15.1.5 Defect handling and tracking __________________________________________________ 108
16. Terminology _____________________________________________________________________ 110
17. Table of Figures __________________________________________________________________ 115

Page 5 of 116
 User Guide

1. Introduction
1.1 Terms and abbreviations
This chapter contains information about how to start using TestManager™. Most of the
connected tasks should be done by system administrators, so to have all information in
these topics please refer TestManager™ System Administrator Guide. Here only the key
events will be explained, which can be done by all users – however this may be changed
according to local policies.
In the following document the following terms and abbreviations will be used with the
following meanings:
 TM: this is the abbreviation of TestManager™, the main tool
 TSC: Test Scenario, the largest unit of the test. A designed testing workflow of a
bank Business Process to reflect the system’s functionality. It defines the users’ tasks
named Test Cases, the input and output data of the function and the required,
expected functioning during the testing.
 TC: Test Case, a TSC is divided into test cases, usually means one version input,
authorize, amendment or enquiry checking in T24
 BP: Business Process, a unit which is a base/skeleton for similar TSCs in TM. A list
of TCs which to be perform during test process (without input and output data).
 ENQ: T24 enquiry
 RB: TestManager™ Resource Browser
 IE: Interface Engine

1.2 Requirements
TM is an Eclipse and JAVATM based standalone application, which works on different
platforms and software environments. The following recommendations are for a regular use
of the tool, which means a test set of about 4000 TSCs.

1.2.1 Optimal hardware configuration

The Core Banking Group recommends the following configuration for a TM workstation for a
project with around 4000 test scenarios. For smaller projects weaker workstations will do as
well.
 64 bit processor with 2.5GHz clock frequency and 4 processor cores
 6 GB RAM memory
 100 GB free disk space
 100 Mbit/s network card
 Monitor with 1280*1024 pixel resolution

1.2.2 Supported platforms

TM is supported on the following operating system versions:
 Microsoft Windows XP Professional 32 and 64 bit edition, Service Pack 3 or above,
 Microsoft Windows 7 Professional / Enterprise / Ultimate, 32 and 64 bit edition,
Service Pack 1 or above.

Page 6 of 116
 User Guide

 Windows 2003 Server

 Windows 2008 Server 32 and 64 bit edition
 Linux
 Macintosh OS X

TM may operate on other operating systems where the Sun/Oracle Java™ is available –
The Core Banking Group has to be contacted if TM is required to be used on a platform not
listed above.

1.2.3 Supported Java™ versions

TM is an Eclipse based application; therefore a JAVA SDK or JRE must be present on the
workstation.
TM is supported on Sun / Oracle Java™ 6 Java™ Runtime version from update 20 to
update 31.
If the operating system is 64 bit edition than 64 bit edition of Java™ is recommended.
The Core Banking Group recommends Java™ 6 update 31 as this version is tested most
comprehensively.
If Java™ 6 update 32 or above would be used for TMplease consult with The Core Banking
Group before.
It is important to have similar release of TM than the version of Java present on the
workstation. Cross usage is not supported, and TM won’t even start, but gives the following
error message:

1. Figure: Error message for missing or unsupported JAVA

Similar error message appears if Java is not presented on the computer, or Java is not
added to the PATH. In case Java is present, but can’t be included in the PATH, a location
can be given to TM in its .ini file under –vm argument. Please check the Ini section for
further information.

Page 7 of 116
 User Guide

1.2.4 Additional softwares

The following softwares are optional, but make work with TM much easier. For full list
please refer the official Hardware and Software Requirements document, or consult with
The Core Banking Group.
 Microsoft Office (Excel, Word)
 Putty
 WinSCP
 Notepad++
 Subversion 1.6 or higher (preferred) or CVS server
 Total Commander or equivalent

1.2.5 Privileges
TM requires the following user rights to work with full potential (can be different users):
 Localhost admin
 Full right for the T24 Application server
Additional project specific rights might be required.

1.3 TestManager install

1.3.1 The TestManager™ download / update site
The official download / update page of TM (and other products of The Core Banking Group):
http://updatesite.corebanking.com/

2. Figure: Login page of The Core Banking Group download/update site

Page 8 of 116
 User Guide

Download requires authorized access, user name and password can be obtained from The
Core Banking Group via an e-mail to tm.support@corebanking.com .

1.3.2 Download of the TestManager™ installer

The Core Banking Group can provide information about the latest stable version of TM to be
downloaded for installation.

Steps of the download process:

1. Open TCBG updatesite, by using http://updatesite.corebanking.com/

2. Log in, by using the appropriate username and password

3. Figure: Fill user name and password to login TestManager updatesite

Page 9 of 116
 User Guide

4. Figure: Click on “TESTMANAGER” tab at the top of the screen

1.3.3 Installation
The installation of TM does not require administrator or power user privileges.
The installation needs at least 400 MB free disk space - later on TM can generate a lot of
big-sized execution log files - 100 GB free disk space is recommended.
The Core Banking Group recommends selecting other disk partition than the operating
system partition for the TM installation if possible.
The TM installer is a ZIP compressed file - it must be uncompressed to a new folder (even if
an earlier version of TMhas been already installed on the workstation).
On Windows 7, if the installation and later the use is made with different operating system
user than give full access to the root folder of the TM installation to the operating system
user which will use TM.

1.4 Licensing
TMrequires a valid license to operate. It can be an “online” license or an offline license. Both
can be setup during first start of any TM product.

1.4.1 Online Licensing

This type of license requires a license server operating in the visible network. TM licenses
are stored on this server, and if there is any available one, TM product occupies one for the
time it is running. In this model the total number of TM products are limited which can be
operate at the same time. On the “Floating license” form fill the URL of the license server,
then click “Recheck”. If there is a valid TM license on the server, a green OK appears and
the “OK” button becomes enabled, TM can start. License server settings are stored in TM

Page 10 of 116
 User Guide

workspace, it will be checked automatically every new start, and if there is a free TM
license, the dialog window won’t appear.

5. Figure: Floating license dialog

1.4.2 Offline Licensing

This type of license is valid for a specific hardware with a specific user. To get this kind of
license, fill the request form on the Floating license dialog window, then click on the “Send
request” button. This will create an email with the data filled in the fields from “Organization”.
TCBG operators will create a license key file which will be sent back to the requester. The
content of this file has to be copied in the License Key box on “Node-locked license
management” form as text. Then click on “Recheck” button. If there is a valid TM license on
the server, a green OK appears and the “OK” button becomes enabled, TM can start.
License server settings are stored in TM workspace, it will be checked automatically every
new start, and if there is a free TM license, the dialog window won’t appear. It is important to
remember that this kind of license uses some hardware specific information as well as the
OS user name, which all has to be matched to be valid. In case any of them is changed a
new license has to be requested.

Page 11 of 116
 User Guide

6. Figure: Node-lock license dialog

1.5 Workspace
First a (default) workspace must be selected or created. It is recommended to create a new
workspace, under the TM folder. Then projects should be imported separately.

7. Figure: Creating a new workspace

In case a non-existing location is selected, TM automatically creates new workspace in the

given location. It is important that there can’t be “space” in the path of the workspace.

Page 12 of 116
 User Guide

2. TestManager setup
2.1 TestManager settings
2.1.1 TestManager/Configuration/log4j.ini
The log4j.ini file contains location of the TM log file, which will contain logged items during
usage of TM tool.
The tm2.log file will be created automatically after launching TM.

2.1.2 TestManager/Configuration/config.ini
The default workspace can be set here:
osgi.instance.area.default= D:/TestManager/workspace
It is critical that workspace path must not contain any space characters.

2.1.3 Content of TestManager/TestManager.ini file

Specific memory usage and Java information can be changed in TestManager.ini file. In
case default settings are not working, the following parameters should be checked:
-vm
full path of the javaw.exe for the java which TM should use.
With this setting a specific Java can be attached to TM. Useful if more than one Java
instances are installed on the workstation. This setting has to be used if the PATH doesn’t
contains a proper JAVA version. (See 1.2.3)
-data
full path of a default workspace
A location can be set here for a default workspace.
Memory setting is very important part for proper work. If more memory allocation is set for
TM than what is even possible, then TM won’t start. Memory is used dynamically, which
means that TM will ask for new allocations during work if necessary. Memory can be set
with the following parameters:
-Xms…M: Size of allocated memory for start.
-Xmx…M: Size of the maximum possible allocated physical memory (RAM)
-XX:MaxPermSize=…M and --launcher.XXMaxPermSize: Size of the index of the memory
heap. The bigger heap (Xmx) is used the bigger PermSize is required. In case of TM the
half of Xmx should be set at least.
In case of 32 bit Java version the Xmx and the MaxPermSize together can’t be larger than
1.5GB because of Java limitations. To find the proper settings other running applications
and total available memory should be considered, therefore this setting can be different in
each workstation. Default settings are fit for 32 bit version Java with 4 GB total RAM.

Page 13 of 116
 User Guide

8. Figure: Example for TestManager.ini

‘config’ isn’t a directory name, this is a constant value in Eclipse, always means the
configuration folder’s path.
If the line starts with – it means this is a command. The next row, without – mark, is the
parameter of the command.
Last row defined the absolute path of the log configuration file. TM warns the amendments
after launching in case if the path is not set up properly.
Default workspace can be set up in this file as well, using the following syntax:
-data
./workspace

2.2 General preferences

Preferences page - central place for general and TM specific configuration. It can be
accessed through the “Window”->”Preferences” menu item.

Page 14 of 116
 User Guide

9. Figure: Preferences/General

2.2.1 Build information

 Changes in Business Processes are automatically merged into the Test Scenarios
generated from the Business Processes on saving.
 The Java files generated from a TM Suite are automatically regenerated on saving
the TM Suite
 A project list can be added setting up build order or the default one can be used
(original state in alphabetical order of projects from Package Explorer)

Page 15 of 116
 User Guide

2.2.2 Label Decorations

10. Figure: Preferences/Label Decorations

 Common and TestManager specific setting

 Used during the test analysis
 Modify the rendered item label
 They can be switched on/off in Label Decorations menu item
 Decoration images into one of the four corners of the icon of the test scenario log
file or log files’ folder
o Shows checks having pass, fail, warnings, design error, baseline mismatch
 File name decorations next to the log files and folders name
o Statistics on number of baseline errors, design errors, errors, warnings,
passes and on number of covered errors

Page 16 of 116
 User Guide

2.2.3 Datapool configuration

11. Figure: Datapool configuration

 TestManager specific setting

 Datapool Server settings
o The name or IP address of the host running the RMI t server providing access
to the datapools. An RMI server is started locally, if it’s empty
o The port on which the datapool RMI server is listening. It’s disabled if server
host is empty
 Datapool project natures is a list of Eclipse project natures for which the
TestManager should scan the project directory for datapool files

Page 17 of 116
 User Guide

2.2.4 Report transformer configuration

 Customize usage of local XSL stylesheets or global in all TestManager projects to
generate report files
 All available TestManager projects are listed

2.2.5 Resource Browser configuration

12. Figure: Resource Browser Preferences page

13. Figure: Resource Browser with active tabs

 Switch on/off each tabs from Resource Browser, which is the main console of TM.

2.3 Perspective overview

Perspectives are Eclipse objects, which are collections of pre-defined views. These views
are collected to support a function, or TM feature. One view can be attached to many
perspectives. There are several Eclipse Perspectives and there are three TM specific
perspectives.

Page 18 of 116
 User Guide

Additional perspectives are available by menu: Window  Open Perspective or using the
Open Perspective icon in top right/top left/left place of the TestManager window
 Functions: Open Perspective, Reset Perspective, Close Perspective, Close All
Perspectives
 TestManager views are automatically assigned to different perspectives

14. Figure: List of default perspectives

The default TM specific perspectives are the following:

2.3.1 TestManager Design perspective

This perspective offers views to be used during test design. It includes by default:
 Resource Browser: the main container of test design, where the TM projects can be
organized. It contains several lists about cross references inside the project, as well
as execution information for each TSC.Content of each tab can be filtered with a free
text filter field which can be opened by typing any character when RB is active. This
is just a temporary filter which helps locate a specific item fast. RB tabs are the
following:
o Projects: Shows all imported or created TM design and environment projects
and their relations. It shows the active (selected) design project too.

Page 19 of 116
 User Guide

o Test suite: Shows all created TM Suites. It is the content of the design
project’s suites folder with a filter of .ptxml files.
o Test scenarios: Shows all BPs and TSCs. It is the content of the design
project’s scenarios folder.
o Versions: Shows all T24 versions used in the selected design project grouped
by application. For each version it is listed which TSCs are using that.
o AA: Similar to the Versions but AA versions are shown here.
o Enquiries: Similar to the versions but Enquiries are shown here.
o COS: Similar to the Versions but T24 COS are used here.
o Packages: TM package objects are shown here, which are test templates
used in advanced test methods.
o Interfaces: Shows all TM implementations for interfaces. These are version
like layers which help creating interface message contents or check interface
message results.
o Menu: Shows downloaded T24 menus.
o Scripts: Shows all available java scripts, including internal TM scripts.
 File Explorer: a system based view of the TM projects
 Graphs: a visual view to show execution and regression status of TSCs.
 Problems: a list of warnings and java build problems.
 Defects: a view to organize and report regression test defects.

Page 20 of 116
 User Guide

15. Figure: Open additional views

Additional useful views, which opens automatically or can be opened manually:

 Test Case Editor: the main editor to create BP structure. This editor connects BPs
with corresponding TSCs and execution results.
 Test Case View: the main editor for TCs (versions and enquiries)
 Error log: contains error history of the project, including exception traces, which are
very useful information for developers in case of bug fixing. The logs can be grouped
by different categories such as TestManager.general, TestManager.execution,
TestManager.design using the Group by Plugin option in the right top of the window.
 Stylesheet Admin View: a view with all xslt based reports, where basic information
can be set (input format, output format)
 XML Attribute View: an editor where XML attributes can be edited from the items
used in the Test Case Editor.
 XPath-View: a helper tool for creating XPath expressions with live evaluation option.

2.3.2 TestManager Debug perspective

 Execute TestManager Suites
 Monitor the execution process – progress information

Page 21 of 116
 User Guide

 Debug exceptions, errors occurred during run

2.3.3 TestManager Datapool perspective

 Datapool maintenance (Create, Modify, delete etc.)

2.4 EDIT_RUN_PARAMETERS Datapool settings

Edit Run Parameters is a technical datapool, which contains environment specific settings,
and setup possibilities for execution. For each environment different settings can be set,
that is why it is in the environment projects datapool folder. Several variables – like
Globus/T24 login information –are just stored here; there are other forms to edit them. It is
highly recommended to use those forms for getting proper value format.
EDIT_RUN_PARAMETERS datapool can be edited inTestManager Datapool perspective
with a valid TM environment project.

16. Figure: EDIT_RUN_PARAMETERS

Page 22 of 116
 User Guide

Important parameters:
 #CLASSIC_LOGIN_PROMPTS: use for classic Globus/T24 login (e.g. COB)
 #DATE_PATTERN: for the Globus/T24 date pattern
 #DEFAULT_OS_LOGIN_NAME: the login name of the server
 #DEFAULT_OS_LOGIN_PASSWD: the login password of the server
 #GLOBUS_SERVER: the name or IP address of Globus/T24 server
 #GLOBUS_SERVER_PORT: the port of the Globus/T24 server
 #GLOBUS_TODAY: the actually date of Globus/T24
 #HTTP_HOST: the name or IP address of the webserver
 #HTTP_PORT: the port number of the webserver
 #HTTP_ROOTPATH: rootpath of the T24 web application on the webserver
 #LOGIN_PROMPTS: used for Globus login (desktop)
 #OVERRIDE_GLOBUS_SERVER: override the global server Globus/T24 settings
 #OVERRIDE_GLOBUS_USERS: override the global users settings
 #PRIMARY_INTERFACE: Browser or Desktop
 #REPLACE_ONLY: Yes or No. When the processing of interface messages went
wrong a new feature can be used to replace the wrong messages with a new set of
messages without erasing the correct part of the xmlout.
 #UNIX_LOGIN_PROMPTS: used for UNIX login
 #VERSION_PATTERN: used only for desktop
 #T24RXX_XSLT: the T24 version is beeing to be used. The value is defaulted from
Login and user definition window
 #DEFAULT_CODE_PAGE: the code page used on the connected environment.
 #TXN_COMPLETE: specify custom txn complete text. Multiplescripts can be added
by separating the values by “,”This improvement also supports multi language drill
down actions in enquiries. This is needed to support multi language.
 #TXN_VERIFIED: specify custom txn verified text. Multiplescripts can be added by
separating the values by “,”This improvement also supports multi language drill down
actions in enquiries. This is needed to support multi language.
Further parameters can be:
 #PHASES: the phases should be listed in the parameter.
 #HOLIDAY_YEARS_IDS: needed for automatic fill of DAYS datapool required for
increasing/decreasing working days in date fields, containing list of country codes
and years.

Page 23 of 116
 User Guide

 #SO_TIMEOUT: the browser timeout can be set here in milliseconds. This is used for
HTTP communication only.
 #CHECK_STRUCTURE: If this is set to "true" then the health of the Globus/T24
response is checked, otherwise not.
 #RECEIVE_ECHO_LOG: If this is set to "true" then the response echo (i.e. the part
of socket response that contains only the echoing of the request) is always logged.
Otherwise it is logged only in case of error.
 #SOCKET_LOG: If this is set to "true" then the low-level socket logger is activated. It
generates the log files under the "log/SocketLog/" subdirectory of the design project
directory (it should be generated to the environment project, so this is a mistake).
 #IS_PERFTEST_ON: "OFF" value is used in all cases when not performance test is
beeing to be executed
 #ECHO_LOG_LEVEL: has effect on the xmlout logging. There are some
INFO_IGNORE elements which usually contains the following information:
o Status,
o Text (usually the transaction ID)
o User (number)
o UserGroup (name)
o Time
o LogLevel of the current INFO_IGNORE element.
If the value of this parameter is less than or equals to 4 then no INFO_IGNORE
element is written to the xmlouts.
If the value is greater than or equals to 5 than all INFO_IGNORE elements are
logged in the xmlout files.
The default value for this parameter is 4.
 #FILE_LOG_LEVEL: has effect on the timing log (short info’s about the start and end
time of a T24 transaction). The timing log is collected in file named in run parameter
#LOG_FILE_NAME (default: .TestManagerFileLog.csv) under the design project
folder.
The #FILE_LOG_LEVEL parameter's value must be numeric.
If this value is less than or equals to 3 then no timing log information is collected into
file.
If this value is greater than or equals to 4 then timing log is generated for the
transactions.
The default value for this parameter is 4.
 #ENQ_RESULT_FULL_COMMUNICATION: default process is that in the log files
TM saves only the first page’s screenshot of the ENQ result, because of size
problems. In case the user needs all screenshots it can be set with this key.

Page 24 of 116
 User Guide

 #FILTER_BY_TRID: a logical selection for interface messages caught by TM.

Decides if TransactionId datapool should be used or not to check the message Id. If
the message Id can be found in the datapool, then TM keeps the message as it was
created based on one of TM’s TSC, if not, then the message is discarded.
 #JAGENT_PORT: in case jAgent uses different port for server connection as default,
it can be set in this key.
 #SSL_KEYSTORE_FILE: in case of an encrypted socket communication is used as
channel the user key file path can be set in this key.
 #SSL_KEYSTORE_PASSWORD: in case of an encrypted socket communication is
used as channel the user password can be set in this key.
 #SSL_KEYSTORE_TYPE: in case of an encrypted socket communication is used as
channel the encryption type can be set in this key.

2.5 SVN setup

A version controller, like SVN or CVS is highly recommended to store TM projects, making
team work much easier and efficient. It is clear and visible which is the latest version of a
TSC, and who modified it last time. Also TSC created in different TM instance can be
shared this way between project members.
An existing Version controller can be attached to the TM from the corresponding
perspective (SVN in the SVN Repositories perspective, CVS in the CVS Repositories
screen). The previously installed repository’s location should be copied in the “Add SVN
Repository” screen’s Url field. In case of a valid Url, a user name and password can be
added to get access to the repository.

17. Figure: Create new SVN repository connection

From a live connection, the actually used TM projects can be checked out, and after
creating new TSCs, or modifying old ones, can be committed back. Once a project has
been checked out from a repository, it is followed constantly in the TM, showing its state

Page 25 of 116
 User Guide

compared to the shared one in the repository. Icons are indicating the changes, so the user
can decide if an update or a commit is necessary.
In case of conflict, the user can decide that differences to be updated or committed one by
one. To support this, a repository view will be opened, where the local and the shared
version is shown next to each other.

Page 26 of 116
 User Guide

3. Test projects
3.1 Project overview
TestManager organizes work in projects. TM uses two type of projects, one is called
“design” project, which stores all information about design (BPs, TSCs, version/ENQ
schemas, etc.), the other is called “environment” project, where T24 connection information
is stored next to execution results.
Projects can be reached in TestManager Design perspective, RBs Projects tab, where
project can be created, imported or edited. Project name must be unique; TM checks it
during project creation and gives error message in case of conflict.

3.1.1 Create Project

18. Figure: New Design Project – Resource browser

Page 27 of 116
 User Guide

19. Figure: New TestManager Project

Creation of a new TestManager Design Project can be done by the following ways:
 Context menu in the Resource Browser’s Projects tab
o New  Design Project
 At this step also the Environment Project can be created by clicking the checkbox.
 Context menu on Design Project creates a new Environment Project
o New  Environment Project
 Context menu in the File Explorer
o New  TestManager Design Project
o New  TestManager Environment Project

Page 28 of 116
 User Guide

20. Figure: New Environment Project

Icons
 TestManager Design Project
 TestManager Environment Project

TestManager Design Project – place to create XML Call packages, Business Processes,
Test Scenarios, TestManager Suites, to store local source codes, style sheets needed to
generate reports
TestManager Environment Project – all execution result files are generated here and also
all necessary datapools needed during Test Scenarios execution, which are implemented in
Design Project
In the Resource Browser, the TM Environment Projects are shown under the related Design
Project. The actually used is marked by bold; the activation is done by double clicking on
the needed Project.
All log files from the selected environment project can be deleted by one click from the
Resource Browser. It is also possible backup the logs with the Create Snapshot menu item
from the same RB context menu. The result is a zip file containing all log results from the
log and scenarios folder.

21. Figure: TestManager Projects – Resource Browser

Page 29 of 116
 User Guide

22. Figure: TestManager Design Project

3.1.2 Import project

Already existing TM projects can be imported into the workspace with the Import project
context menu option. In this form a path should be filled, from where TM automatically
recognizes valid projects, highlighting those ones, which are not part of the workspace yet.
At this level there is no difference between design or environment projects, there are just
projects. During import procedure TM recognizes them, and organizes them correctly.
All imported projects should be copied under the workspace as well, to avoid cross-changes
with other project members, who might work with the same projects.

Page 30 of 116
 User Guide

23. Figure: Import project form with selected projects

3.1.3 Convert project

In case of a TM upgrade to newer version like upgrade from 2.5 to 2.6 it is necessary to use
the “Convert project to current version” functionality from the context menu of the Design
project.

24. Figure: Convert project to current version

Page 31 of 116
 User Guide

3.2 Relations between projects

Design projects store information about test design, while environment projects tell how to
connect to a T24 environment. That is why a design project should connect to an
environment project, one at the time. RB offers an easy way to establish this connection.
First a design project should be selected with double click on it. The design projects name
become bold for this action.
Then double click on any existing environment project, which will do the same, and will be
“moved” under the selected design project. This represents the connection between the two
projects.
In the same time on the top of the Resource Browser this selection should appear in text
format too.

25. Figure: Connected design and env projects

This connection can be manually set in each projects Preferences page, where the project
to be connected can be selected from a drop down list.

26. Figure: Design project Preferences page, connect environment project

Page 32 of 116
 User Guide

In case of the environment project, a second connection can be established: a baseline

project can be selected to the given environment project. This means that during regression
test execution results will be compared to the selected baseline projects results. A baseline
project is a different environment project, where the results of the base execution are
stored.
Similar to the connection settings, there are additional preference pages such as:
– AA parameters
– Browser specific settings
– Builders
– Desktop specific settings
– Generic logging
–Globus/T24 login and user definition
– Interface handling
– Other Property Page
– Report settings
– T24 Environment specific settings
–T24 Environment project preference
– Test execution specific settings

27. Figure: Preferences page for Environment project

The selected baseline project will appear under the environment project, one level below,
and with normal text. All possible baseline projects will appear in RB, but only the selected
one is normally visible. Baseline project can be selected with double click too on this list.

Page 33 of 116
 User Guide

28. Figure: Connections in RB

3.3 T24 connection setup

T24 environment connection can be setup in the environment projects Preferences page,
under “Globus/T24 login and user definition” screen. This form contains all information
required for login. There are two type of supported communication: Browser and Desktop
protocol. They have different fields to be filled.

3.3.1 Browser connection

Browser connection can be setup in the T24 tab. It requires host name, port and proper
folder information of the environment. TM supports different type of browser protocols from
R8 to R13, the proper one has to be selected from a dropdown list under T24 version. In
case a proxy must be used for connection, which can be setup here.
The browser URL can be copied directly to the field “Environment URL”, this case TM
automatically separates IP, host and folder. It works the other way around, after filling the
separated fields, the result copied from this field to a browser should open environment
login page.
TM must recognize date in environment, for that a proper date pattern should be set. This is
a regular expression; the default value ((\d*)-(\D*)-(\d*)) matches the common T24 default
date, like 11 JAN 2013.

Page 34 of 116
 User Guide

29. Figure: Browser specific T24 connection

3.3.2 Desktop connection

Desktop connection can be setup in Globus tab. On this form next to the host and port an
OS user must be setup with password, because T24 login contains two levelled login
procedure. This OS user is used not only for the desktop connection, but for classic or script
execution connections as well. Each of these three types of connection a login procedure
must be defined. It goes under the Desktop, Classic and Unix tabs. Here the “questions”
must be enlisted which are asked by the system in correct order, and give the correct
answer. For proper setup please contact TCBG experts.

30. Figure: Desktop specific T24 connection

3.3.3 Common connection setup

T24 user setup is common for both types of connections. Columns to be filled are:
 “Globus/T24 name”: is the SIGN.ON.NAME of the user
 “Globus/T24 password”: which is defaulted with 123456

Page 35 of 116
 User Guide

 “Globus/T24 ID”: is the user ID.

 “Teller ID”: is an optional field, if the user has a dedicated teller, its ID should be
stored here. In some cases T24 asks this number during teller transactions, but TM
can answer these questions automatically. Can left blank in case there is no teller
open for the user.

TM has three different types of users, separated by their role:

 Info user: is used during design period, to get version and ENQ schema information
from the selected environment. It is also used to download T24 menu structure.
 SOR user: is used in Desktop execution for the SOR operation, in case of any other
user is stuck. The user allocated for this role must not be used anywhere else.
 Globus test users: are users which used during execution. There are two default user
roles:
o DEFAULT_INPUT_USER: is used for all tasks except Authorize steps
(including all ENQs, report openings, See checks, etc.)
o DEFAULT_AUTH_USER: is used for Authorize tasks only.
With the “Add First/Add Next” buttons custom roles can be added to this list with different
users. In TSC design users can be reached with their Nick name. It is important, that the
same T24 User can’t have more than one role, meaning it should appear only once in this
list. Otherwise there might be conflicts and errors during execution.

31. Figure: User definition screen

Defined users login can be tested individually for Info user and SOR user by pressing Test
button. Pressing “Test all” button tests all defined users login including Globus test users.

Page 36 of 116
 User Guide

4. Basic design
4.1 Structural overview – how to plan a test scenario
Basic element of a test scenario is called Business Process (BP). This is the skeleton of the
test, contains all sequences in the correct order, how they appear during the workflow. A BP
covers a complete workflow of a bank product. TSCs created based on this BP can use
sequences which are added to the BP, but not necessary all of them. It depends on the
nature of the TSC – for example a negative TSC which expected to be failed during the first
transaction won’t contain sequences after the first one.
Actual field values will be set in TSC level, where the proper field order and expected
checks can be set too.

4.1.1 Organizing test scenarios

First level of organizing tests is folder level. Folders should represent T24 modules, or
business products. Then a second folder should come named after the specification
package.
A test specification package is covered with a few BPs, depends on the structural variety of
TSCs. Normally the structure of TSCs connected to the same business product are not very
different, therefore usually one BP is enough to build up the whole structure.
BP is the match of specification, contains the very same sequences. The structure follows
the specification in also day separation, but also some phases should plan in the BP ahead.
Further details come later.
Normally one TSC is covered with one XMLIN, a TSC equivalent in TM. XMLINs are
connected to a BP, and have the same structure. It can be decided at this level if a
sequence from the BP is used in that particular TSC and with what values. It is just an
option to use all sequences; normally there always will be some sequences which are
skipped here and there.

4.1.2 Creation of TSC structure

All “creation” tasks are part of the design process, so they should be done on TestManager
Design perspective. Best option is the Resource Browser, which offers all required tools and
information which are needed during design.
After selecting a design project and connect to an environment project, folder and BP
creation is done on RBs “Test scenarios” tab. Create and rename commands are available
from the context menu after right click inside the tab. New elements will be created at that
location where the click was performed.
Same rules must be followed here in naming convention than for the workspace: there can’t
be any space in the file/folders name.
Double click on a BP item in RB will automatically open it in the TestCaseEditor, on the right
side of the screen. This is a multi-tabbed editor, where the BP and all connected TSCs can
be edited and followed including execution result checks.

Page 37 of 116
 User Guide

New sequences can be added to “Phase” named items in many different ways.
 By right clicking on it and select “Add new…”
 If a T24 menu was downloaded earlier, one or many menu item which represents a
valid sequence (version, ENQ, report) can be added with drag & drop.
 Already used versions and ENQs can be drag & drop from RBs Versions or Enquiries
tabs.
 TM packages can also be added with drag & drop.
For each sequence in the BP a specific user has to be assigned. This can be a default user.
In this case no extra action has to be done. Default rule is that Default Auth user do
authorization mode sequences, Default Input user does everything else. Allocated user can
be changed in two places. First is on BP level. In this case user allocation will be changed in
all related TSCs. Second is on TSC level, where the user allocation is changed for one TSC
only. Allocated users can be selected from a drop down list which contains all defined users
from Globus Test Users user definition page of the environment. User allocation uses the
nick name of the user, this way the actual T24 user can be different in each environment,
but the design doesn’t have to be changed, only the users table.
TM supports many different connection channels to T24. Default channel is set in the
environment setup where the Desktop or Browser is selected as default. Desktop is a
socket based communication while Browser is a html based communication protocol. During
BP design for each sequence the environment default protocol is selected automatically.
OFS protocol is also supported, but this protocol has to be selected manually for each
sequence where this would be used. For OFS protocol the OS login section has to be filled
with a user who is in T24 group (login promt is in jShell). In this protocol TM creates an OFS
message instead of a socket or a html post and send this OFS directly to T24 through a
dedicated service (e.g. TAP).

Page 38 of 116
 User Guide

4.1.3 Test Scenario Overview

When multiple Test Scenarios are created the “Test scenario overview” tab displaysall the
variations of the different Test Case and parameter usage by scenarios in one screen. It
also displays all input and expected value.
Double clicking on a value will select the related scenario (xmlin), select the related node
and the editor (version/enquiry/…) should appear with the field in focus.
Pressing “d” or toggling the “Show only fields with differences” should show/hide fields
which are identical.

32. Figure: Test scenarios overview

4.2 Version, Enquiry, Report

Basic elements of a TSC are called Test Cases, which can be one of the following
elements:
 T24 Version
 T24 Enquiry
 T24 Report
 T24 AA product
 T24 Composite Screen (COS)
 Interface
 Java Script
 TM Package
 Change Company
 jAgent

Page 39 of 116
 User Guide

33. Figure: Insert new items into a BP

Each screens touched during manual execution should appear in the BP, each with its
technical name. Sequence name and other attributes can be set on the XML Attribute View.
The second mandatory attribute is the mode. It can be:
 I(nput)
 A(uthorize)
 S(ee)
 V(erify)
 D(elete)
 R(everse)
Saving the BP triggers an automatic schema download process, when TM tries to get
structural information for each version, enquiry, COS and AA. With the help of this
information TM can show a T24 look and feel editor to fill input data. TM uses the INFO user
for this task. The schema download communications are stored in a separate folder under
environment project’s log folder. The process of schema download requires the possibility of
opening a new or an already existed record from the given version. In case there is no new
record option for a version but an already existed one can be opened, this record ID can be
used as an “Example ID”, which can be set on RB’s versions tab. This case TM tries to
open the given record, and builds version schema based on that record.

Page 40 of 116
 User Guide

34. Figure: TC modes

TM support the generation of test data from xsl or java. This feature helps to cover multiple
variations of T24 Version fill out with one test case where the different rules of variations
aredescribed by an additional self-implemented xsl or java class file.For instance it is very
useful for AA and LD payment schedules.
Technical help for implementing the element:
 A new >>PLACE_HOLDER<< element can be added to version and enquiry design
in the xmlin. One case decide to provide an xsl file or a java class file.
 For the xsl, the file should be in the .stylesheet folder and set the input extension to
xml.
 For the java the file should implement the IGenerateXmlElement interface.
 Parameters can be added to the PLACE_HOLDER element which will be passed to
the java or to xsl.
 When the test case is executed the PLACE_HOLDER element is replaced with the
result of the xsl transformation or the result of the generate method of the java class.

4.3 Values, expected value checks

After creating BP structure, XMLINs should be created. It can be done from Test Case
Editors “Test scenario list” tab. Right click on it will open the context menu: New test
scenario. XMLINs name will be created based on the BPs name as default, but it can be
changed to anything else as long as there is no space or other special character in it.

Page 41 of 116
 User Guide

35. Figure: Create new TSC from BP

The created XMLIN file opens automatically in the editors “Test scenario” tab. It has the
same structure as the BP, but it is “empty”. To add values to fields or ENQ search criteria,
first an Input data should be created to the proper sequence. Adding a new Input data and
double clicking on it will open automatically the Test Case View, where the selected
sequence can be edited. In case of a version a T24 look and feel form appears where the
tabs and fields of the selected version can be seen. To add a value simply fills the first
column with any fixed data. TM will fill this field with this value.
For easy navigation TM offers a search panel where a field name or a part of it can be
entered. Then TM focuses automatically to the first match. If this is not the required field, the
field name has to be given more specifically or by clicking the “next” button TM jumps the
next match.
All kind of fields can be filled, from a single value field to a multivalue field, or multivalue
group, dropdown list fields, radio buttons or multiline fields. Multivalue fields are shown with
a red box in TM editor. By clicking on it a new multivalue field appears, if the previous field
has any value in it. In case only a later field has to be filled, a #IGNORE() helper value can
be used. See more in helpers chapter. Dropdown fields and radio buttons appear as a
single value field. If the schema contains the possible values, TM also offers them during
design time. Multiline field can be designed with a help of #ML() helper.
In some cases T24 automatically generates a deal slip during a transaction commit. TM can
show this deal slip as a T24 Report object, but this check has to be designed as an attribute
of the version instead of a T24 Report sequence in the BP. TM automatically opens the deal
slip if the Deal Slip attribute is true, based on the information T24 shows during the version
commit. The result appears as a separated test sequence in the log, but as explained
before it doesn’t have to be designed upfront.
Similar to the deal slip TM can show a delivery preview connected to a transaction. This
step doesn’t have to be designed as a single sequence in the BP either, just as for the deal
slip, but a specific attribute has to be set instead. The result appears as a T24 Report
sequence in the log.
TM supports capturing and checking status bar messages for each window. This can be set
through an attribute similar to deal slip.

Page 42 of 116
 User Guide

36. Figure: Fill input data to a version

For functional test expected values should be added to each field to check if the system
works well. These values can be filled in the second column. TM will check field contents
against this given value, and indicates error in case of any difference. Field value can be
checked before or after the commit. If a reopen transaction mode is set on (the verify
attribute of the test case is true), TestManager™ will check the field expected values on the
reopen version, which means after the commit. If there is no reopen mode then expected
values will be checked before the commit. Reopen mode shouldn’t be used for AA and
multi-legged versions. Expected values in these cases should be checked on a separate
test case (extra See mode).
Expected values can be texts, numbers, fixed data or calculated values.
For each version field TM can check it’s enrichment, the “comment” text appears next to the
field value. This check works similar as the field value checks, except this expected value
has to be set as a field attribute.
TestManager recognizes dynamic schema changes such as hot field changes during
version execution. In case a hot validation changes another field as hot validation field, TM
will handle it properly when reaches that during execution.As the version design may
change at run time (new fields may appear after filling special fields), hot field recognition
must also be dynamic. Hot field attribute is detected from the last T24 server response after
each Post+Response communication.Enquiry results can also be checked in many ways.
There can be expected values set for the number of rows in the result. Default result is one
or more rows, but can be set to no result, or a specific number of rows.
For each row TM can check field values in the second level filter. In this case TM checks the
expected value for all fields in the selected column, so in this case best practice is to have a

Page 43 of 116
 User Guide

single row as result. To get this one specific row to be checked a second level filter option
helps to find the requested row. TM can create many second level filters from a single
executed enquiry, all based on the original result. This way any number of rows can be
checked. It is important to remember that if more than one second level filters are designed,
no popup menu actions should be used!
For better understanding TM can filter empty rows from enquiry result in the log. This option
has to be set in the enquiry editor.
TM supports check of all fields in the enquiry result header. There fields appear among the
second level filter column names, but with all capital letters. Expected value has to be set
similar as any other field in rows.
T24 Report content can be checked with enhanced regular expression commands. Search
patterns can be created with regular expressions combined with TM helpers or string
functions. In these patterns groups can be defined with the help of ‘(‘ and ‘)’. For each of
these groups expected values can be added which can also be a regular expression but
also a fixed value. With the help of this method even a specific SWIFT tag can be checked.
TM supports multiple Reports as result of save as action used while iterating on a datapool
with a package.The resolution is to use the postfix value defined as a parameter in the
package itself in the meaning that postfix the report file name with that value.
There would be the following two options:
 if there is any postfix parameter used in the package, then the same value will be
used also in the report file names
 if there is no postfix the same file name will be given as currently

37. Figure: Input and expected values in Test Case View

Page 44 of 116
 User Guide

38. Figure: Enquiry editor

In case of non-english T24 users the Enquiry Test Case view filters are displayed in English
and non-english language as well. Use the correct filter to test and evaluate the expected
result.
TestManager supports unicode character encoding. Default code page is ISO-8859-1 and it
can be configured dynamically in its .ini file.

4.4 Helpers, dynamic values

To make connections between each TC in an Xmlin or between different TSCs, TM offers a
large variety of special field values, which are the so called “Helpers”. They are TM built in
functions which help in design time to connect one field to another, or to make the TSC
“environment free”.
IDs which are generated during the execution (Customer ID, account ID, transaction IDs,
etc.) are different in every execution that is why they can’t be used as fixed value. During
TSC design, every time such value is used, a Helper will be used instead, which makes a
reference to the “origin” of the value (points to the field it appeared), and uses that value as
an input or base of calculation. Typical example is a transaction ID which needs to be
authorized. This process has two TCs, one for Input and one for Authorize. In the second
case there will be a helper reference to the transaction ID of the first case’s (Input) ID. This
way for each execution exactly that transaction will be authorized, which was created in the
same execution. Such references can also be made for version fields, ENQ results or even
Interface message fields.
Handling date is critical in designing a TSC, because this has the greatest impact on the
reusability of the scenario. During automated test one of the most important goal is to create
TSCs which are not dependent to any environment, so they easily can be executed in many
different environment giving the possibility to check the difference between each

Page 45 of 116
 User Guide

environments. In case of using fix dates it requires sometimes hard efforts from local IT who
creates test environment, because the environment must be on a specific date, or has to
have some specific settings, etc. Instead of using fix dates which have to be maintained for
every execution TM offers the usage of relative dates with the helper: TODAY. This helper
refers to the date of the current environment, and this “base” date can be shifted in design
(e.g.: Today+1Y, Today-5).
A different date handling calculates based on the connected environment’s holiday table.
These are the #DAYS helpers, where in design references are for the logical test date. The
DAYS datapool links the logical dates with actual calendar dates. A built in java script fills
this datapool from the selected T24 environment. A specific helper can calculate differences
between these logical dates, and tells how many real days are between two logical dates.
Helpers offer solution for special set fields, like “multi-line” input, or specific account-, and
transaction ID formats. There are also functions which help in value calculations when an
expected value can be calculated or combined from more than one different other fields or
just create a random number.

39. Figure: Initializing helper – first selection

Page 46 of 116
 User Guide

40. Figure: Using helper – second selection

41. Figure: Helper – full expression

4.5 Other design objects

4.5.1 T24 COS
TM can open any kind of composite screens (COS), but only one part of it at a time.
Therefore the “result” of this object is a version or an enquiry, or even an enquiry result.
Design goes similar as for normal version or enquiry. However if the COS is an enquiry

Page 47 of 116
 User Guide

result, then the first level selection doesn’t have to be filled, since that have been already
executed by T24. Only second level selection should be filled this case (include popup
menu action).
To get the proper part of the COS selection process guides the user from up to down. This
means that first the frame container has to be selected, then if there are several possibilities
in a frame (like other frames), then select a level deeper as long as the required version or
enquiry is reached. TM offers these containers automatically. They are downloaded as COS
schema, similar then a version or enquiry schema.
Every area touched during execution has to be a separated COS sequence in the BP.

4.5.2 T24 TAB

Similar to T24 COS, TM can open any kind of Tab separated objects (TAB), but only one
part of it at a time. Therefore the “result” of this object is a version or an enquiry, or even an
enquiry result. Design goes same as for COS.Every area touched during execution has to
be a separated TAB sequence in the BP.

4.5.3 T24 Arrangement Architecture

Using TM it is possible to design test for any kind of complex Arrangement Architecture
(AA). To understand the full procedure of downloading and designing AA T24 objects,
please go to chapter7.5T24 AA Automation.

4.5.4 Change company

This sequence can “move” the selected T24 user to a different company. Result does the
manual process for change user’s company. It has two parameters, first is the user nick
used in TM, the other is the target company’s name. TM doesn’t check if the user is allowed
to login that company upfront, but shows as an execution error if the change company is
failed.
This is a global command, which means that after this point the user remains in the selected
company as long as its session is active. After a new login user is put to its default
company. One step in a BP is valid for one user only.

4.5.5 Java Script and jAgent

These objects make possible to use “external” commands and scripts. Java Script object
can execute a user created java file. It has to be part of the TM project, which means that if
it was not created in TM, it has to be imported (perform a refresh in File explorer) into TM
(Eclipse). Java scripts can contain any commands, handle with care. An example of a java
script is a ReadHolidayTable.java, which fills the DAYS datapool based on the
environment’s holiday table.
With jAgent object T24 jShell commands can be designed to be performed automatically.
For this a specific login process has to be setup next to the browser (desktop) login. The
Unix (OS) login page has to be filled with a valid OS user from the T24 group, which can
perform jShell commands as LIST, SELECT, JED, etc. It can perform a single command,
but it can also be a routine. With the help of this object many manual actions can be
automated, like backup, or start service or agent.

Page 48 of 116
 User Guide

4.6 Import/Export test scenarios

TM offers a possibility to export and import test scenarios to a specific format. With this
option the scenarios can be transferred or synchronized with other programs like HP QC.
The supported format is an excel table which contains the test skeleton, which is similar to
the BP. The export TSC command generates this excel file which can be processed with
QC, while the import TSC command reads this excel file and generates the test skeleton
based on the file.

Page 49 of 116
 User Guide

5. Basic execution
5.1 Execution with XmlinExecutor
During design time it is important to check from time to time the “quality” of the design, and
check if the TSC really does what it should be. For this purpose TM offers a special
execution control system where a TC can be quickly executed and then analysed. This is
the XmlinExecutor suite, which is a “template”, it will execute always the current command,
and so the content of the suite is automatically changes every time. It can be controlled with
four icons from the last section of the icon bar, or from RB context menu. This method is not
capable for complex executions, parameterization is limited, which means that execution
won’t change phase or day. It will stop in the end of the phase it was started.
There are two prerequisites for using this method:
 valid environment connection setting in the ENV project
 all opened items in the Test Case Editor must be saved. TM will offer a save
automatically before the execution, but this time there won’t be a chance to see the
content of the modifications, just the files to be saved.
The four control icons can be used inside the editor area, when the Test scenario tab is
opened. Standing here on any of the sequences will make these buttons available. The
buttons will do the following:
 Continue: this button is enabled only if a part of the result has been created, and
there is anything which can be continued. It is not important where the cursor stands
in the time of the command, because this time TM finishes the last opened phase of
the TSC.
 Step over: this button will execute the selected TC only. It is important to consider
that in case of a multi-legged transaction or a popup menu ENQ this execution
method is not working well.
 Continue and stop: this button is enabled only if a part of the result has been created,
and there is anything which can be continued. It continues the execution until that TC
which is selected in the time of the start of the execution.
 Start from: this button starts the execution from that TC which is selected and
executes everything until the end of the current phase.

42. Figure: Execution control buttons

XmlinExecutor can be used from RBs Test scenarios tab too, but from here only the whole
day1 phase “Empty” can be executed, and step by step execution is not possible. However
from here all TSCs connected to a BP can be executed with one click (start execution on a
BP).

Page 50 of 116
 User Guide

5.2 Execution Monitoring

When an execution starts a Console view opens in the bottom right panel which contains
messages during execution. System messages like user logins, and execution errors
appear in this view. It gives also information about the status of the execution if it is still
running or terminated.
During execution status icons in RB change too. A “Running man” icon appears in the
Execution status column in the row of the current TSC. After the execution the icon
automatically changes to statistic information which shows how many TCs were executed
from that TSC in percentage or with numbers.
A more detailed execution information is shown in the xmlin editor too, where the actual
status can be seen after each TC. This way it can be followed how far the execution
reached in the specific TSC, which TC have been finished, which is just running and which
are remained, and for those which have been finished, the result can be also seen. This
means a green tick in case of good result, and a red cross with the error message in case of
bad result.
Execution can be followed best in TestManager Debug perspective, which offers the most
important views connected to execution. In the Debug view appear different threads started
during the current execution, and shows the status of them (running/terminated). The Users
view also offers several useful information about the selected thread, including status,
response time, last command, BP and TSC name and many more.

43. Figure: Users view

Page 51 of 116
 User Guide

6. Log analysis
6.1 XMLOUT, IOXML
Execution result appears in two main log file, the Xmlout and the IOXml.
The Xmlout contains the result of the TSC (Xmlin). It has similar structure than the Xmlin
which helps to locate a specific part of the TSC. It gives information for each TC, number,
name, mode, Input values, system responses, override messages (system warnings) and
commit statuses. It also contains the results of checks, indicating with colouring places with
difference or error. All version fields appear in this log as well as ENQ results or T24 reports
and Interface messages.
This log can be used as base for regression test; in case a baseline is available with the
compare to baseline button a compare can be started. After that only the differences
between the two execution will be coloured, not the functional errors. This means that while
a failed commit is coloured with red in functional mode, if it was wrong also in the baseline,
it will be green in compare mode.
Meanings of each colour are the following:
 green: functionally ok, worked as expected.
 yellow: TM warning, format change (e.g. T24 changes the format of the number
input, or date)
 brown: handled system error or anomaly, like opening already existed record instead
of new
 light red: expected value check failed for a field.
 dark red: execution error, a system exception or other not expected anomaly; error
happened most probably on T24 side
 black: design error occurred during execution, the error happens on TM side (e.g. a
datapool is missing, used version schema doesn’t match on the one in the
environment and a not existing field wants to be filled)

Page 52 of 116
 User Guide

44. Figure: Version expected value check in Xmlout

45. Figure: Enquiry expected value check

The IOXml contains information about the surrounding of the execution. It shows login
information for each user used during the execution, and a top level result of each TSC
executed recently. This log is linked with the Xmlins created for TSCs, and with a double
click they can be opened.

Page 53 of 116
 User Guide

Xmlouts can be opened in TestManager Design perspective, when a TSC is opened in the
Test Case Editor. The last tab opens the corresponding log result.
IOXml can be opened from the Log folder browser view, when a suite is opened in the Test
Case Editor.

46. Figure: IOXML

6.2 Information in Resource Browser

After execution a lot of statistical information appears in RB. There are four columns:
 Execution status: This contains information about how many of the TCs in the TSC
were executed
 Design status: This shows the number of design errors
 Error status: This shows the number of execution errors
 Regression status: This shows the number of differences in case a baseline is
available and the compare was executed.
On Xmlin level these numbers show the statistic of the TSC, while on BP and folder level
they are cumulative values.
On different tabs the “meanings” of these values are slightly different. Statistics for versions
or ENQs show cumulative statuses for the actual version/ENQ only from TSCs they are
used, and not the status of the TSCs. E.g. if a TSC contains a Customer version and an
Account version, where Account failed, then on Versions tab Customer will be “green”, while
on Test scenarios tab the TSC is “red”.
Double clicking on a column opens either the xmlin (design), the xmlout (log) or the
compared log in the editor.

Page 54 of 116
 User Guide

47. Figure: Execution result in Resource Browser

6.3 Graphs
Graphs view shows a visual statistic of the whole project, or of a subset of it. Selecting (click
on it) an item in RBs Test scenarios tab gives the “root” for the Graphs statistics, and will be
updated automatically.
There are two pie charts, one show functional status, the other is regression status. This
last one contains “relevant” information only if a baseline is available.

48. Figure: Graphs view

6.4 TestManager logs

While working TM creates some log files which contains information about the whole
process. These log files are only important if an error occurred in TM.
Main log file is “tm2.log”, which is located in the root directory of TM. It contains all
information which was printed to the screen, and a lot more Infos, Warnings, Exceptions,
Suite start/stop info. All of them are time stamped, so it is easy to find (for developers) a
concrete event in it.

Page 55 of 116
 User Guide

Another log file called “.log”, located under “workspace\.metadata”, contains TM exceptions
and some other critical errors.
In case of reporting any discrepancies, please attach these log files too, or at least the
corresponding part from them.

Page 56 of 116
 User Guide

7. Advanced design
7.1 Packages, parameters (Input, Output, Local)
Packages are collections of versions, enquiries or Interfaces which are connected from a
certain point of view, and should be executed together. It works as a template, because it
can’t be executed on its own, an “external” BP must “call” it. A pack can be used many
times with different input data, what is common is the TCs to be used. A good example for a
pack is a version which needs to be authorized, so put together the Input version and the
Authorize version.

7.1.1 Design a pack

A pack should contain steps which are logically connected and should be used together all
the time. This can be a multi-legged transaction which has always the same versions;
therefore 4 or more steps can be grouped together. Or if a certain transaction can be
reached through an ENQ with a popup selection then group the ENQ and the version
together. If an account opening requires many steps/versions to be filled then these should
be grouped together. After creating the pack it should be named after the logical content, so
it will be easy to recognize what it does – e.g. account opening, card issue, etc.
Packages will have a separate log file after their name, which means that if the same pack
is used multiple times on the same sequence, only the last result will remain because all
execution will overwrite the previous one. To avoid this anomaly a group of parameters
should be set as “postfix” parameters, where the content of them will form a unique text.
Adding this text to the name of the pack will keep all log results because the name of the
pack will be different. This set can be done in BP level, while standing on an Input
parameter, then in the XML Attribute view change the postfix attribute to true for each
members of the set.

7.1.2 Create package

Packages are stored in the design projects “design/packages” folder. In RB there is a tab
called Packages which provides an interface to handle packages. On this tab the structure
of the previously mentioned folder can be seen.
New folder and pack can be opened in RBs Packages tab from context menu. This will be a
BP first, and same steps have to be done during design as for a regular BP. The main
difference is that a pack – as mentioned before – is a template, and can be called later with
different data. That is why it should not contain fix values. Data is given to the pack through
parameters. These parameters can have default values, but in the same time give the
possibility to change it to any different value.

Page 57 of 116
 User Guide

49. Figure: Designing package BP

Parameters can be Input or Output parameters. To create them open the packs BP in the
Test Case Editor, and right click on the Parameters item. There must be a separate
parameter for each field which should be used in the pack.
Input parameters are used for transferring values into the pack, while output parameters are
moving out data. There is no other way to get values from the pack, just through
parameters.

50. Figure: Create Input parameters in pack Xmlin

Page 58 of 116
 User Guide

51. Figure: Create Output parameter in pack Xmlin

After creating all required parameters in the BP, they will appear in the Xmlin as well. In the
next step of design these parameters must be connected to the fields where they should
give their value with the #PARAM helper as field value, or assigned them to fields where
values should be taken with the #ASSIGN_PARAM helper in the expected value field. All
helpers can be used inside the pack, but they will “see” only inside the packs content.

52. Figure: Assigned Output parameter in pack Xmlin

Page 59 of 116
 User Guide

7.1.3 Call a pack

Packages must be called by a “normal” BP to be able to use them. It appears in design as a
normal sequence, and can be added to the BP similar way as a version or an enquiry. After
selecting the pack there is the first opportunity to change parameter values. These settings
will be default for all Xmlins created from this BP. Overwriting parameter values can be
done ultimately in TSC level.

53. Figure: Selecting a pack to be called

When it is called in BP its main characteristic is the multiplicity. It can be set here how many
times this pack should be called at that given point.

Page 60 of 116
 User Guide

54. Figure: Fill parameter values for a called pack

55. Figure: Helper reference to a pack’s Output parameter – selection mode

Page 61 of 116
 User Guide

56. Figure: Helper reference to a pack’s Output parameter – finished expression

7.1.4 Local parameters

Parameters can be added to a normal BP, they are called Local params. They are Input and
Output parameters, and works very similar than in a pack. They can be used to transfer
data inside a TSC, or give the possibility to do variations on the same TSC structure.
Creating them works similar than in packs: from the context menu of the BPs Parameters
item.
Input parameters are used for variations of the TSC. In case most of the input data are
similar for many TSCs, collecting the different ones into parameters they can be “grouped”
together into one TSC. The different field values can be set in a parameter table, which
becomes active when at least one Input parameter is created. Clicking on the parameter
table item in the Xmlin opens an embedded Excel where values can be defined in columns
for each parameter. One row will be one variation. The input parameters should be
connected to their corresponding fields with the #LOCAL_PARAM helper. It is possible to
add ‘Test Scenario ID’ in the parameter table and use it in the naming of the test scenarios
in the resource browser and reports.
Any field can be “refactored” as local Input parameter by right click on it in the Test Case
View editor.
Output parameters can get value during execution, and be used later in the TSC. To add
value it must be assigned to a field with the #ASSIGN_PARAM helper into a field’s expected
value column. It can be read with the #LOCAL_PARAM helper as an input value. It works
for TCs which has only one input message.

Page 62 of 116
 User Guide

7.2 Datapools
Best way to transfer data between TSCs is datapools. Datapools are mostly file based
storage places connected to the Environment projects. They can store data created during
an execution or can keep design data used for TSC input.
They can be managed on the TestManager Datapool perspective. On the left panel there is
the Datapool navigator, which shows all Environment projects and the datapools inside.
Selecting a datapool will open Datapool view where all information connected to the
selected datapool can be seen and in some cases modify. The content of a datapool can be
edited in the Test Case Editor on the top right panel.
There are six types of datapool:
 Hash datapool: it is a key-value type of datapool, data can be read and write to it
during an execution. It is file based, which means that after a normal execution
datapool content will be written in file and can be used later.
 Table datapool: it is an indexed table, where one row stores data for one iteration. It
is used for design purposes, where data is put in datapool during design time. In
execution it is just read and used as input data. It is a file based datapool.
 Excel datapool: this is a variation of table datapool, it is a link to an excel sheet for
better design purposes. It is easier to manage data on it, and used for input data, just
as a table datapool. The excel file location can be a fixed path or a relative path
calculated from the environment project location as root. The file path can be
changed anytime.
 JDBC datapool: this is a variation of a table datapool, it is a link to a database table.
 FIFO datapool: this is a virtual datapool, exists only while TM is running, so any data
stored in it will be lost when TM stops working. It is used for Interface message
handling.
 Remote datapool: this is a link to another datapool, which can be in a different project
on the same workspace, but can be located on a different PC as well.
Datapools can be read and write with helpers:
 #DP: this helper reads a value from a datapool. Syntax is: #DP(‘datapool
name’,’key’,’column name’). For key there are two other words to be used:
o #USED can be used in a table datapool, and refers to the row where the index
points at that moment.
o #NEXT can be used in a table datapool, and refers to the next row where the
index points at, then moves the cursor.
 #DPP: this helper puts data to a datapool. Syntax is: #DPP(‘datapool
name’,’key’,’column name’). This helper can be used in a fields expected value. In
case the key doesn’t exist, TM will automatically create it. There is one special word
for key:
o #MULTI can be used for table datapool where a column of an ENQ result can
be stored, not just one value.

Page 63 of 116
 User Guide

There are some technical datapools which are created automatically with the environment
project:
 EDIT_RUN_PARAMETERS contains technical parameters connected to the
environment
 TransactionID stores all values which appeared as Transaction ID during any
execution on the environment. It can be used to filter “our” transactions from any
other content of the environment.
 EDIT_GLOBUS_TEST_USERS stores user settings for the environment.
Datapools contain execution data therefore they are important to be backed up together
with the log results so in case of a restore all data will be available. This backup can be
initiated with a manual snapshot command, which creates a zip file from the datapool folder,
postfixed with the date and time of creation.

7.3 Multi-legged transactions

The normal way of working of TM is that it opens a screen, gives some input, do a commit
then returns to the T24 opening screen. In T24 there are several transactions where input
goes through many versions, or enquiries. Classical example is a Loan transaction where a
manual schedule opens a different version during commit, and transaction is committed
finally from this second version. Same happens when the proper version opens after
clicking a link on an ENQs result.
In this case TM has to be notified that after “committing” a TC the next step will
automatically open and therefore a different opening procedure has to be taken (practically
the next screen will be opened without doing anything). This can be done in the BP level by
adding a popup parameter to the proper sequences. Every TC involved this procedure must
have this popup attribute, and the value must give the proper order how they will be
opened. This can be done on the XML Attribute view after selecting the TC in the BP,
where click on “Add new attribute” icon on the top right corner of the view will open a drop
down list with all possible new attributes. From this list popup can be selected, then set the
proper value.

7.4 Popup windows

Some T24 Versions are designed in the way like when successfully committing them, a new
popup screen opens up automatically with another T24 Version. This situation is also
handled by TM and needs to be automated as a separate Test Case with the proper
technical name of the popup Version what can be retrieved either checking manually in T24
browser or executing the Version Test Case triggering the popup and checking its detailed
execution log..

7.5 T24 AA Automation

TestManager supports AA test case design the same way as for all versions, through the
Version editor. In order to do it there is need for the schema of each used AA versions too.
The same Version editor is used for AA multi versions also, but only one subversion or the
main version can be edited using the Version editor (TestCase view) at once.

Page 64 of 116
 User Guide

The way in which TestManager learns the AA schemas is not the same as how it
learnsVersions, for this ones, a series of multiple steps are performed which results in a
properly created schema of the desired AA.
TestManager recognizes AA versions (both arrangements and activities) when they are
opened directly from a Composite Screen resulting an enquiry popup menu action or
opened as a 2nd leg of a normal version.
TestManager uses the AA Product Catalog for both AA schema download and AA TSC
execution. By default the core Product Catalog is taken. We also support the Bank specific
Product Catalog(s).
TestManager uses the following enquiries in order to download the AA Product Lines,
Groups and Products possible values referred in the T24 standard Product Catalog:
 product line: %AA.PRODUCT.LINE
 product group: %AA.PRODUCT.GROUP
 product:%AA.PRODUCT
These Enquires can be overridden in the datapool AA_PARAMETERS using the following
keys in case the scope is to test AA product in a Bank specific and customized T24
environment:
 product line: #ENQ_NAME_OF_PRODUCT_LINE
 product group: #ENQ_NAME_OF_PRODUCT_GROUP
 product: #ENQ_NAME_OF_PRODUCT_CATALOG
If there is no value defined for these datapool entries or they are removed from the datapool
AA_PARAMETERS then the T24 standard Product Catalog enquiry names are used as
default.
After having the schema of the product, to get schema of the corresponding activities, a new
key has to be put in the datapool. It looks like the following: “[product name]-
ARRANGEMENT-ID”, where [product name] has to be replaced with the current product.
There can be a separated key for every product. The value must be a valid arrangement id,
where the selected activity can be performed on. Again, TestManager will just initiate the
activity, but never commits.

7.5.1 AA datapools
TestManager uses two helper datapools for storing the required data, “AA_PARAMETERS”
and “EXAMPLE_IDS”. These datapools are automatically created for each new
TestManager environment project.
 AA_PARAMETERS - After a successful connection to AA product line, product
group and products this datapool is filled out automatically with all relevant
information.

Page 65 of 116
 User Guide

57. Figure: AA_PARAMETERS datapool

In case not the standard Product Catalog needs to be used and/or TestManager doesn’t
succeed with automatic download of Product Lines, Groups, Products etc. the following
parameters can be defined by the users in AA parameters item using Preferences window
in order to help TestManager. All changes done on AA Parameters item of Preferences
window are automatically written into AA_PARAMETERS datapool. There are hints for each
variables as well giving additional information about their usage.

Page 66 of 116
 User Guide

58. Figure: AA Parameters item on Preferences window

#AA_CURRENCY_EXAMPLE, #AA_CUSTOMER_EXAMPLE – optional variable

representing currency and customer used for downloading AA schema files. It has to be a
valid currency for AA transaction capture and any customer number, not compulsory to
have any AA transaction for this customer. TestManager tries to find the values
automatically, however if it fails than gives an error message in the schema .err file to
provide the values manually.
#ENQ_NAME_OF_PRODUCT_LINE, #ENQ_NAME_OF_PRODUCT_GROUP,
#ENQ_NAME_OF_PRODUCT_CATALOGUE – optional variables used to define the
Enquiries names for Bank customized Product Catalog (see above). The exact technical
names of Enquiries have to be defined
#AA_PRODUCT_LINE_COLUMN_INDEX – optional variable containing the index value of
column with the list of Product Lines in the standard %AA.PRODUCT.LINE enquiry. Its
default value is 3. It has to be defined for Bank specific Product Line enquiry in case the
column containing Product Line doesn’t match with the defaulted value.
#AA_PRODUCT_PRODUCT_GROUP_COLUMN_INDEX – optional variable containing the
index value of column with the list of Product Groups in the standard
%AA.PRODUCT.GROUP enquiry. Its default value is 2. It has to be defined for Bank
specific Product Group enquiry in case the column containing Product Group doesn’t match
with the defaulted value.
#AA_PRODUCT_CATALOG_PRODUCTS_DESCRIPTION_COLUMN_INDEX – optional
variable containing the index value of column with the list of Products in the standard

Page 67 of 116
 User Guide

AA.PRODUCT.CATALOG-PRODUCTSenquiry. Its default value is 2". It has to be defined

for Bank specific Product enquiry in case the column containing Product doesn’t match with
the defaulted value.
#AA_ARRANGEMENT_CUSTOMER_COLUMN_INDEX - optional variable containing the
index value of column containing the customer of an Arrangement in the
%AA.ARRANGEMENT enquiry. Default value is 2.Is used for AA schema automatic
download. In case TestManager finds column with name “Customer” than no column index
is used. Value might need to be defined especially for non-english T24 users and/ or
customized Bank environment.
#AA_ARRANGEMENT_CURRENCY_COLUMN_INDEX - optional variable containing the
index value of column containing the currency of an Arrangement in the
%AA.ARRANGEMENT enquiry. Default value is 3. It is used for AA schema automatic
download. In case TestManager finds column with name “Currency” than no column index is
used. Value might need to be defined especially for non-english T24 users and/ or
customized Bank environment.
#AA_ARRANGEMENT_ID_COLUMN_INDEX - optional variable containing the index value
of column containing the id of an Arrangement in the %AA.ARRANGEMENT enquiry.
Default value is 1. It is used for AA schema automatic download. In case TestManager finds
column with name “Id” than no column index is used. Value might need to be defined
especially for non-english T24 users and/ or customized Bank environment.
#AA_ACTIVITY_DESCRIPTION_COLUMN_INDEX - optional variable containing the index
value of column containing the description of an Activity in the %AA.ACTIVITY enquiry.
Default value is 2. It is used for AA Activity schema automatic download. Value might need
to be defined especially for non-english T24 users and/ or customized Bank environment.
#AA_ACTIVITY_ID_COLUMN_INDEX - optional variable containing the index value of
column containing the Id of an Activity in the %AA.ACTIVITY enquiry. Default value is 1. It is
used for AA Activity schema automatic download. Value might need to be defined especially
for non-english T24 users and/ or customized Bank environment.

 EXAMPLE_IDS – this datapool contains the reference of a given example of the AA

arrangement or AA activity that is being implemented. This datapool is common for
Versions and AA Versions. Warning: these example transaction IDs are specific to
the T24 environment instance used during the schema download. A data restore
action on the T24 server side or a new T24 environment usage can invalidate these
example transaction IDs.

Page 68 of 116
 User Guide

59. Figure: EXAMPLE_IDS datapool

7.5.2 AA tab on Resource Browser

AA tab shows all AA products used in the current selected TestManager Design project.
Also all modes and activities are listed on the tab with their descriptions in Name column
and technical name in the Description column. In case there is an example id used for
schema download than it is shown with ID text in the schema icon or in case there is html
used for schema download, it appears with Ht text in the icon.

7.5.3 Automate AA New Arrangement

The process for implementing a new AA Arrangement or Activity is similar to how the
versions are created, nevertheless it consists extra steps. The process of creating a new
T24 AA test case in TestManager is the following:
1. Start the process by adding a new T24 AA item in the Business Process (if the AA
was already used, the product can be added to the Business Process by dragging &
dropping the New Arrangement item from the AA tab Resource Browser into the
Business Process).

Page 69 of 116
 User Guide

60. Figure: Insert AA Test Case

2. Select first product line, then product group then the product. For all case
TestManager fills the dropdown list with the proper values. It may take some time to
update the list as the values are retrieved directly from T24 first (cached after
successful retrieval for better performance in the datapool AA_PARAMETERS).
If no group and line values are provided then all AA Products will be available in the
choice list. Some products do not have group and line parameters and using only
product value is recommended for these cases.

61. Figure: Select AA product Line, Group, Product and Mode

3. Change the mode to “New Arrangement”, “Simulate” or any other available value
from drop down list. (This step can be skipped if the AA was dragged & dropped from
the AA tab of the Resource Browser).

Page 70 of 116
 User Guide

4. Saving the Business Process triggers download the AA multi version schema from
T24.
5. In some cases when TestManager cannot automatically download the AA schema
and design error is displayed in the Resource Browser, example Id usage or the
“Paste example HTML source” context menu action is recommended. Go to the AA
tab at the Resource Browser, select the New Arrangement under the mode, right
click on it to show the context menu and select the “Add Example ID” (or “Paste
example HTML source”) option.This will show a popup window where you should
paste a valid ID of an AA product that you wish to design. Both existing AA
identification and html source can be retrieved manually from T24 browser. For
HTML source there is need to open the AA transaction than choose View Page
Source item from right click menu on the AA screen, than select its content and paste
into TestManager. As result of paste, the html file is saved into Design project
.descriptors/browser folder. In all cases when T24 has been changed by adding new
functionalities impacting the current AA transaction, manual refresh of HTML file is
needed in TestManager. Using HTML source is not affected by database restore
case in the meaning that schema download still succeeds after T24 database.

62. Figure: Insert Example ID for AA schema download

6. Finally click on the “Re–download design” from the context menu and wait for the
schema download action result.
Remark for upgrade to TM2.6 In case of updating TestManager from older release (TM2.5
and below), please add each example ID again for all AA schema using the old
AA_parameters datapool example ID list (storage datapool was unified with normal
Versions). After that the example ID list can be deleted from the datapool
AA_PARAMETERS as it is generated in a new format into the EXAMPLE_ID datapool.
In TestScenario level AA version looks different than standard Versions. Version editor is
opened separately for each sub-version, but only when the sub-version or main version is
selected, not any level higher as for versions. For all sub-version the corresponding schema

Page 71 of 116
 User Guide

appears in the editor. Fill the field values and expected values the same way you do for the
T24 versions.
On the main version the customer, currency and the effective date fields have to be filled.

63. Figure: Complexity of AA Test Case Design

Most of the AA products do not require any authorization. In case of authorization is

necessary, then drag & drop the product again in the BP, and change the mode to A. This is
one of the exceptions when “standard” modes are working. For the authorization, the
#TX_ID helper can be used, as the new arrangement transaction has to be authorized.
TestManager also supports AA version popup from a normal T24 Version as result of its
successful commit. Test Scenario design needs to be done in two different Test Case as in
case of any other popup.
Important remark is that it might also happen that html source needs to be used for AA New
Arrangement schema download because the AA main version name to be used is different
than the default one what TestManager would take in case there is no html source given.

7.5.4 Expected value checking in AA

Expected value checking is done in the same way as in case of T24 version. TestManager
checks the fields’ expected values based on the verify attribute value in the meaning that if
it has the default value as true, than automatic reopen S mode is used otherwise the field is
checked at commit level. With this function the user can define where the expected value
needs to be checked. It is especially recommended to be applied for checking the fields with
dynamic values. (eg. Product and Activity fields values in AA Main version)

In case there is an error message received like „Field doesn’t exist on the form” and the
reason is that to be checked fields do not have name attribute in the html code either than
we recommend to check them in different mode. (eg. A, New Arrangement etc.)
If all modes result the same error than there is no option to check them with TestManager.

7.5.5 Using AA in See mode

In TestManager schemas for AA products in S mode are downloaded via the View Activity
foe Arrangement activity, therefore the transaction id has to contain the value structure such
as Arrangement identification concatenated by -VIEW-ARRANGEMENT string. This is

Page 72 of 116
 User Guide

defined in TestManager for example in the following way:

@#RFIELD('PERSONAL.LOAN','12','ARRANGEMENT')+-VIEW-ARRANGEMENT
This ensures that the same AA subversions are downloaded in the schema as appear
during execution.

7.5.6 Automate AA Activities

All actions performed with an AA arrangement have to be done through activities.
Downloading a product to TestManager will get a list of all possible activities which can be
performed on that product. Adding new activity to the BP can be done by drag & drop the
selected activity.
Activity mode can be “Do activity”, “Do activity today” or “Simulate”. Warning – the default
mode is “I” for all dragged element.
In case the activity has been already used before, then it can be dragged from the mode
list. In this case the Do activity today mode has to be dragged.
In Test Scenario the transaction id of the activity’s main version must be the Arrangement Id
of the New Arrangement. This value can be found on the main version of the New
Arrangement in the field Arrangement. It can be referred by a #RFIELD helper function.
Authorization goes the same way as for the New Arrangement, if required.

64. Figure: Do Activity Today AA TC example

While working with AA activities it might be faced on the challenge of reaching to an activity
that is not listed under the AA Activities list shown in Resource Browser AA tab.
TestManager is able to reach for such kind of activities via Drilldown, to do so the first thing
needed is the name of the Activity to reach for and to get this name the process has to be
started manually till the screen of the activity that need to fill out and its name can be read
from here.The name of the activity follows the pattern of PRODUCTGROUP-ACTIVITY-
NAME, for most of the activities it will be shown at the top of the activity, however for those
who does not (like some payoff simulations), it is contained within one of the subversions of
the activity.

Page 73 of 116
 User Guide

65. Figure: AA Activity example 1

66. Figure: AA Activity example 2

After getting the name of the activity,one of the activities from the activity list of the AA has
to be drag and drop than replace the product name and the mode of the activity. The name
should be the onepicked before manually.
NOTE: it is recommended to leave the product name follow by the # sign so the new activity
is grouped under the product properly.

67. Figure: Manipulate AA Product

After performing the actions mentioned before and saving the Business Process,
TestManager will attempt to download the schema, however since the activity is not listed,
we need to provide the schema which we do by copying the HTML source from the AA
transaction screen from T24 browser.

Page 74 of 116
 User Guide

68. Figure: Get AA Example form HTML

And pasting it to TestManager by right clicking the added activity and selecting the “Paste
example HTML source” from the context menu.

69. Figure: Insert AA example from HTML source

After we save TestManager will generate the schema based on this example HTML source.
TestManager supports automatic company change during AA creation in the same way as
T24 does. For the time of one transaction action (like an AA Activity, or an AA version
Authorization) T24 automatically transfers the user to the company where the record is
booked.

Page 75 of 116
 User Guide

On user side changing the company is "invisible", only in record header is written that it is
another company, but no action has to be done. After closing the transaction window user is
back to its original company.

7.5.7 Executing AA Test Scenarios

TestManager executes AA Test Scenarios via Product Catalog by launching the
AA.PRODUCT.CATALOG-PRODUCTS enquiry for the given Product (with or without
Product Line, Product Group results the same) than opening popup menu New
Arrangement or Simulate.
AA Activity execution is started by the AA.DETAILS.NEW.ACTIVITIES enquiry filtering for
AA Arrangement id and Activity than opening popup menu action based on the selected
mode – Do Activity Today, Do Activity or Simulate.
TestManager marks additional subversions during AA execution which are not present in
design level. This happens especially in case of AA activities because during the design are
less subversions in Do activity today/Do activity/Simulation mode than in reopen mode S
when usually all subversions are shown.
In case of any execution error, the detailed execution log with communications has to be
checked in order to find the root cause of the error.

7.5.8 Non-english language support

TestManager supports AA schema download and execution with non-english T24 user as
well in such a way that TestManager looks for the column index in an AA related enquiry.
These indexes are defaulted based on the T24 Model Bank but can be customized with AA
related parameters.

7.5.9 AA Troubleshooting
In case the Product Line and/or Product Group and/or Product schema download fails in the
meaning that these variables do not get any value in the XML Attribute View for a T24 AA
type of TC, than is recommended to check manually whether the default AA Enquiries result
proper answer. If not than it means that different Enquiries need to be used for schema
download and these have to be given in the AA_PARAMETERS datapool’s variable. There
is also option to configure the schema download detailed login by adding the -
Dcreate.schema.download.log=true in the TestManager 2.6.ini file stored in the
TestManager root folder.
In case the product has to be relearnt, this action can be selected on the modes part of the
product on the AA tab. For each mode the re-download has to be performed one by one.
Downloading AA schema takes some time, significantly longer than standard versions or
enquiries. Please check the progress view to follow ongoing operations. Please keep in
mind that until the schema is not downloaded new test scenarios will not perform properly.
Schema errors are displayed in the editor and also in resource browser’s design error
column. Wrong schemas often cause execution errors and may have effect on other
scenarios executed in the same session.

Page 76 of 116
 User Guide

8. Complex methods
8.1 Datapool Iteration
This method should be used when a TC needs to be executed many times in a TSC. It
works very similar than iteration with local parameters, but this time the iteration will be
executed only on one sequence of the BP. For example if many different accounts have to
be created for the same customer, then iteration on the account creation is a good choice.
Iteration can be done on any elements of the BP such as versions, enquiries, interfaces,
reports and packages. In case of iterating on a package TM will execute the whole content
of the pack. The numbers of iterations are depending on the connected datapool: each row
of the datapool represent one iteration and contains the “changing” data.
For iterating on datapool first the datapool itself should be created. It contains those fields
where data changes in iterations. Datapool must be a table-like datapool (table or excel),
where each column represents a field, and each row a different iteration.
Set up iteration in BP, first the multiplicity value should be changed for the TC to be iterated
to “…iterate on datapool”. Next selecting the TC in the Xmlin; in the XML Attribute view fill
the datapool attribute from the drop down list with the datapool to be iterated on. Field
values in the TC which are changing should be connected to the datapool with the
#DP(‘datapool name’,#USED,’column name’) syntax. TM automatically goes through the
datapool and executes the TC with each row.
In case the iteration goes on a package it is important to set the postfix parameters to keep
all logs of the iteration and avoid log overwrite problem.

70. Figure: Datapool iteration – multiplicity setup in BP

Page 77 of 116
 User Guide

71. Figure: Datapool iteration – connect datapool to the TC in Xmlin

72. Figure: Datapool iteration - using datapool columns in helper references

Page 78 of 116
 User Guide

73. Figure: Datapool iteration – result in the Xmlout

8.2 XPath
In case there are more than one Input Data for a TC, common helpers may have trouble to
locate a proper value. This case XPath expressions should be used to find a value. TM
allows to use XPath 1.0 expressions and functions. Syntax is that field value should start
with “=” then comes the expression.
All helper references are XPath expressions after all, and are evaluate on the Xmlout log.
To help creating manual XPath expressions TM has a view called XPath-View, which has
the possibility to evaluate immediately the expressions, so the result is immediately seen.
XPath functions are also commonly used mostly the string manipulation functions, like
substring or concat. They have the standard XPath syntax, and all combinations are
supported which is allowed in XPath 1.0 standard.

8.3 Multi phase, multi day scenarios

8.3.1 Phases
TestManager’s basic execution unit is a phase. Phase is a logical unit in a day. There are
several possibilities for this logical separation. Most commonly used phases are
“transaction”, “ENQ”, “beforeCOB”, “afterCOB”, “COB”, etc.
Phases have to be designed in BP. By default an “empty” phase is created in the BP. To
“name” a phase simply change its value in the XML Attribute view. Right click on a phase
opens a context menu which allows creating new phases before or after the selected phase
on the same day. There shouldn’t be two phases under the same day with same name!

Page 79 of 116
 User Guide

74. Figure: Create new phase in BP

Phases used in BPs has to be listed in EDIT_RUN_PARAMETERS datapool under the key
#PHASES. Phase names have to be listed here in the exact order they are coming during a
day. TM will locate log results by this order, and will be able to put results in a correct order.
A normal execution executes phases, all TCs in the selected phase for each TSC in the
execution list, then phase has to be changed manually to execute all phases in the TSC.
That is the job of the main suite (see Advanced execution).
Phases can be repeated, and TM will replace the log section of the phase. It is important to
fill #PHASES, because TM will find the location of the phase based on this list. In case of
the phase which is repeated is not in the list, TM will put the phase in the end of the day
removing any possible results from later days.

8.3.2 Days
TSCs are planned in day structure. Most of the complex and end-to-end scenarios are
covering several days. To separate test design from the real calendar in TM there are
logical days. Beginning of the test cycle represented with day1, and then all other days are
relative days from this day, like day2, day3, etc. In every execution TM reads the current
T24 date and replaces all date expressions based on that value. To avoid conflicts with
bank working and non-working days, there is a test convention that in automated test
Holiday table should be empty in T24 environment, meaning that only weekend days are
holidays. In addition, day1 should be a Monday, and test plan is done according these
conditions. This means that – considered T24 COB automatism – actions are designed on
day1-5, then day6 and 7 are always empty. In T24 COB of day5 automatically jumps to
day8 because day6 and 7 (Saturday and Sunday) are holidays. Keeping these conventions
will make sure that test execution will always work without serious maintenance work.

Page 80 of 116
 User Guide

New day can be added similar way that phase, from context menu on a day item in BP.
Value is mandatory for day item. An empty phase is automatically created for each new day.

8.4 Conditional execution control

TestManager supports a specific way to control the execution with certain conditions. These
conditions can be given through enquiries. This means that the sequential execution can be
suspended with an enquiry selection as long as a specific expected result happens.
TestManager executes the enquiry as long as the required result happens, e.g. a specific
record appears in the result, or a balance reaches a required amount. This method can be
setup in the enquiry TC through attributes. First the enquiry selection must have an
expected result designed. Then the retry count has to be set, which is 0 by default, which
means that TestManager doesn’t check the enquiry again in case of failed expected result
check. Then a delay attribute has to be set which shows how much TestManager has to
wait between each retry.
This method can be used best in parallel execution, when the second thread monitors the
first with this enquiry check, and as soon as a specific result happens, like a record has
been created in the first thread, or COB reached a specific stage or job, the second thread
is “released”, continue running because of the positive enquiry check.

Page 81 of 116
 User Guide

9. Non-English language support

Expected Transaction complete and transaction verified messages can be defined in any
language in order to ensure that Test Scenario execution will be a successful result. These
variables are setup in the Preferences window opened from environment project’s context
menu.

75. Figure: Properties of Environment project

Additional information on supporting AA transaction design and execution using T24 user
with non-english language can be found in chapter 7.5 T24 AA Automation.

10. Advanced execution

10.1 Suites
Complex executions can be controlled with Suites. A suite item executes complete phases
in the selected TSCs, and not TCs one by one.

Page 82 of 116
 User Guide

10.1.1 Create Suite

Suites can be created on the RBs Test suite tab from context menu. Suites can be ordered
in folders similar way than TSCs and BPs. Test suite tab represents the suites folder from
the design project and suites are stored in files with .ptxml extension.

10.1.2 Suite structure

After creating a suite it is automatically setup for a single thread local execution structure.
Single thread means that TSCs are executed sequentially, one after another. Local
execution means that TM can access T24 environment directly, no server side “agent” is
required for connection. Agent is a process running on the environment server which opens
a port for TM to access the environment. This application is part of TM and has to be copied
to server if needed. For detailed information contact TCBG.
The Scenario item contains items to be executed including commands and scripts. A default
script always appears in a new suite: “Close Globus Session”. This script logs out all users
involved during the execution.
BPs and even single TSCs can be dragged & dropped under the Scenario item, but a
context menu based insert is an option. From this context menu all possible items can be
added to the execution. The most important ones are the following:
 BP
 TSC
 Set day
 Set phase
 Transactor
 Increment day
 Delay
 Script
 Suite

Page 83 of 116
 User Guide

76. Figure: Items which can be inserted into a suite

It is possible to drop a specific variation (row in the parameter table) of a test scenario into a
suite.
“Set day” and “Set phase” controls during execution that which day and which phase will be
executed after that point where they are used. They are “global variables” during one
execution, which means that if they are changed once, their value is stored until they are
changed again, but until the first started suite finishes. Default value is Day1 and “Empty”
phase if no other value is set.
Transactor is an item which is a container used for iterations. It repeats its full content as
many times as it is set in its Iteration No. attribute.
Delay can be used at this level between TSCs only. Its value is in millisecond.
Script can be any java code and can have any type of effect. It can execute OS commands
on the application server, but can reset datapools or change their values. It requires high
programming skills to create proper scripts.
Suite can execute another suite. It is good for organizing purposes, moving together TSCs
which are connected to the same product or specification document usually a good idea.
This way they can easily switch on/off before an execution and suite structure doesn’t need
to be changed. It is important that inside (called) suites should not contain “Set day” or “Set
phase” items because their change will have effect in the caller suite too, and then it will be
impossible to control the execution. The called suite’s day and phase value comes always
from the caller suite.
All items in Scenario have an Enable/Disable context menu attribute where the actual
execution’s scope can be put together. It is easier to disable items for some executions than
Page 84 of 116
 User Guide

remove them, because they are usually not put back to the suite later and will be skipped
“forever”. In disabled status they will be seen in the suite but also visible that at the moment
they are skipped.

77. Figure: Selecting TSCs to be executed in Suite property editor

10.2 Main suite, Standalone suite

To organize and put together all created test scenarios there should be a main suite, which
has one purpose: to execute a whole day with all phases designed in any TSC. ALL TSC
should be added into this main suite in those phases where they have anything to do. Best
practice is to organize first TSCs into suites mentioned previously, then put these suites into
the main suite. This way is the less chance to miss any TSC from a full execution. Then in
case of a reduced execution scope any suite can be disabled.
Suites inserted to the main suite should not contain any “Set day/phase” command,
because the main suite will control it.
During design time it can be important to execute separately TSCs from a particular module
or product. Standalone suites are used for this purpose. A standalone suite contains all
days and phases which are designed in the related scenarios. This is the major difference
between main suite and standalone suite that main suite contains the structure of one day –
and it is separately controlled which day it will be, while a standalone suite contains all
effected days.
Best practice is that for each suite put in the main suite a standalone suite should be
created too with “Set days/phases” for separate execution purposes.

Page 85 of 116
 User Guide

78. Figure: A Main suite with execution result in the Log Folder Browser for each phase

10.3 Sequence types

Each sequence has to be categorized into one of the following group: Preparatory, Test or
Check. Default setup is Test for all new TC. This category has effect mostly during
reporting, like preparatory steps are not reported as thoroughly as test or check steps. It has
one effect for execution too, that execution of Test type sequences won’t start as long as
there is any error in the TSC’s preparatory steps. This way TM makes sure that the test
won’t run in vain.

10.4 Error handling supports

Next to the previous feature which doesn’t let to start TSCs where prepare is wrong another
feature helps repeat only those TSCs where any execution errors happened. This feature
can be reached from the RB context menu.

Page 86 of 116
 User Guide

11. Reporting
11.1 Reports from execution log
Final stage of any testing process is the reporting when the results are presented in a user
friendly format. TestManager offers two different types of reports divided by the source. One
group are the “stylesheet-based” reports which generate reports from execution log results
(xmlouts). The output format can be HTML or PDF.
Report generation can be started from RBs Test scenarios tab from the context menu
Reports/Create report… This opens the wizard where the required report should be
selected from a combo box. Reports will be generated for all TSCs which have execution
results and are under the selected region. Multiple selectionsare possible, as selecting
folders.

79. Figure: Creating report from RB context menu

There are several pre-defined reports with both types of output formats:
 Report PDF/HTML report focuses to sequences with TEST and CHECK type.
Sequences with Preparatory type are shown only the basics. For Test type
sequences report contains all information. Result is coloured to highlight errors and
defects. In case of browser execution this report contains T24 screenshots for
versions and enquiry results.
 Report HTML screenshot contains the TEST and CHECK type sequences with all
screenshots of the browser communications next to the table data like in the previous
report. This means that this report is valid only in browser mode. Screenshots are
supported in HTML output only.

Page 87 of 116
 User Guide

 Report with menu HTML is a report with a menu to navigate between sequences. It
also contains filtering option to show/hide steps. Report contains all information from
the execution. It has only HTML as output format.

80. Figure: Report wizard for stylesheet-based reports

The following Project and Test Cycle relatedgeneric information is generated in each Birt
report:
 Project
 Test cycle
 Cycle schedule
 Test environment
 System version
They need to be given in the RUN_PARAMETERS datapool (#projName, #testCycle,
#testStartDate, #sutEnvironment, #sutVersion)

11.2 Reports from database (BIRT)

The other source of reports is the design model of TM. For this kind of reporting TM has a
built-in BIRT reporting tool which has several pre-defined reports to help following the
design status of the project. BIRT reports require special TM licence.

Page 88 of 116
 User Guide

Report generation can be started from RBs Test scenarios tab from the context menu
Reports. From this menu a valid BIRT report can be selected. Multiple source selection is
also possible in the same way than stylesheet based reports.
 Execution status report contains information about how many TCs of the scenario
has been executed and with an execution statistic of error/warning numbers.
 Overallreport contains summary information about the executed tests with the
possibility to select the required details like Show coverage (Yes/No), Show
execution results (Yes, No), Show error summary (Yes, No).Regression status report
contains information about the scenario execution compared to a selected baseline.
Shows the covered/not covered differences with statistics.
 Test Scenario summary report shows the structure summary of each TSC in the
selected area, including packages, versions, enquiries, helpers used, etc.
 Defect report contains information about which defects are linked to the given test
scenario. Mainly it is a list of defects, where it shows for each defect’s description
and what exactly they are covering. In this case an extract is shown in compare
report style: sequence number, name, baseline value, value, baseline expected,
expected (if it has any).
 Execution report contains details about the Test Case level execution of the selected
Test Scenario in PDF format including T24 screenshots.
For all reports there is a possibility to save them in file automatically, in this case they will
appear in design project’s generated reports folder, or open them with system editor.

TM supports using Bank specific logos in the generated reports.

The default empty icon need to be replaced by the Bank specific logo under the icons folder
of birt plugin accessed from TM root folder
(eg. d:\TM_2.6.2_Sprint_150909\plugins\com.fotgroup.birt.connector_2.2.8553\icons\

Page 89 of 116
 User Guide

12. Interfaces
12.1 Interface design
TM supports system integration test with replacing external systems with test stubs. These
stubs are called interfaces. Interfaces are built up from two parts. One is the design part
which creates a version like layer where fields can be defined; values can be specified for
the messages or expected values for checks.
These design items can be used as any other TC in a BP. There are two different type of
interface by direction: it can be Input or Output. In input interface TM will create a message
to T24, while Output interface analyse a message from T24.
Interface definition files can be created in RBs Interfaces tab from context menu
“New/Interface”. In functional and regression testing Data type of interfaces are used.
After creating a new interface fields (single or multivalue) can be added in the TSC Editor
area. At this point only the existence of a field is important, because TM automatically
orders them. Main rule is that first single value fields are coming, then the multivalue fields.
Mixing them is not possible.
In case of an Input interface the “connection” attribute has to be set, while in case of Output
interface the “datapool” attribute.

12.2 Interface connections in Interface Engine

Second part of interface building is the connection definition. TM has a built-in tool called
Interface Engine, which gives an easy way to define different type of connections. Interface
Engine supports file-based connections (FTP, SFTP) like Swift In and Out, MQ or Temenos
Connector. For full documentation please refer to TCBG advanced training materials.
Interface connections are responsible for converting interface design data to a proper format
and transfer it to T24, or catch T24 answers, analyse and transform them back to design-
acceptable format.
Interface Engine has many datapools, from which at this point the IN_CONFIG_DP and the
OUT_CONFIG_DP have to be mentioned. All connections have to be defined in these
datapools, where a connection is a row in one of the datapools. These datapools contain
four columns:
 Connection name
 Message Description: contains how the message has to be transported to T24 or
where to check it.
 Converter Description: contains which fields and in which order has to be in the
message. This is the point where connection meets with design. Field values are get
from design if field name matches, otherwise a default value will be used.
 On/Off makes it possible to decide if the connection should be running or not.

Page 90 of 116
 User Guide

The Message and Converter columns contain an XML script, which is an easy to learn
language, therefore easy to create new/custom connections. TCBG advanced training
material contains several examples which can be used as base for new connections.
Interface Engine has a main control suite which has to be started before any other
execution starts, then in the end it has to be manually stopped with executing a “Terminator”
suite.
Interface Engine can be replaced with java programs, where connection and converter rules
have to be programmed. This is an advanced way to operate interfaces and requires expert
programming skills.

Page 91 of 116
 User Guide

13. Recording
There is an option in TestManager to use the recorder function to record the manual
creation of any transaction or record any specific action what results problems when
implementing or executing with TestManager. The recorded session gives enough detailed
information for further debugging done by developers.

13.1 The Recorder view

81. Figure: General options

 Select the target project and folder!

 If there is a folder in the target folder it could be the package
 Type the script name. This will identify the generated session file, and this will be the
name of the generated test script class.

82. Figure: HTTP options

Page 92 of 116
 User Guide

In case of HTTP/HTTPS communication recording (this is the case for T24 Browser
interface), the “Http port” must be set. The default is 2008. This is the Proxy port to be set in
the Proxy settings of your browser.
Include ’Disconnect’ in the generated session file checkbox:
The Session file (.ptsession) generated by the Recorder contains a lot of "Disconnect" lines
in case of HTTP recording. These are not needed in most cases, but make the file less
readable, and add a lot of unnecessary checkboxes, sometimes exhausting the handle limit
of Windows. The generations of “Disconnect” entries are optional with using this checkbox.

83. Figure: Socket options

84. Figure: The Log tab

The Log tab of the Recorder view shows progress, errors, and other useful information
during the recording process.

13.2 Preparation for recording – Browser, HTTP/HTTPS

In the following description we assume that you use Microsoft Windows and Internet
Explorer. In other cases the procedure is similar.
Make a note of what you modify, so that you can restore after recording.
 In the Internet Explorer, from the menu bar select “ToolsInternet Options”.
 On the Internet Options panel, select the “Connections” tab, and press the “LAN
settings” button.

Page 93 of 116
 User Guide

 On the appearing LAN Settings panel ensure that the “Use a proxy server…”
checkbox is checked, while the “Bypass proxy server for local addresses” checkbox
is unchecked.
 The “Address” should be “localhost”. (Unless the Browser and the Recorder are on
different computers, in which case “Address” should be the name (IP address) of the
recorder’s computer).
 The Port and the Recorder’s “Http port” must be the same.
 Press the “Advanced” button”.
 On the appearing “Proxy Settings” panel ensure that the “Do not use proxy server…”
area is empty.

85. Figure: Preparation for Browser recording

Page 94 of 116
 User Guide

13.3 Recording

 Open / activate the Recorder view.

 Press the “Start proxy” button.
 Log in on the client that is on the Browser to Globus/T24.Make every step what you
have to do, but you don’t want to record.
NOTE: if you use HTTPS (i.e. the URL of the T24 main page starts with “https”), then
use protocol “http” instead of the “https” prefix and insert :443 as port into the URL if
no port is defined. (The Recorder will properly convert it to HTTPS, if the port of the
T24 server is 443, or it ends with '443' (e.g. 9443)).
 Press the “Start recording” button on the recorder view before the steps that you
would like to record.
 Do the manual actions in the browser (e.g. Internet Explorer).
 Press the “Stop recording” button when you finished recording.
At this point the result of the recording is already available, but it is nice of you to
 Logoff from T24/Globus.
 Press the “Stop proxy” button.
 Check the content of the recorded file to ensure that the recording was successful
(see next chapter 14.4).
 Send the recorded session file to TCBG or attach it to the appropriate ITS issue for
detailed investigation - in case it was requested by TCBG.
 Restore the proxy settings of the browser you used for recording.

The Recorder view has additional buttons:

 You can pause and later continue the recording.
 You can split the script.
 At any time you can add a note (comment). This comment will appear in the recorder
result (session) file, as well as in the generated script. In this way you can easily
identify the start and end of a relevant recorded step.

Page 95 of 116
 User Guide

13.4 The Session file

The session file (which is the result of the recording) can be found in the “session”
subdirectory of the specified package. The name of the session file is composed of the
specified Script name and the timestamp; it has “.ptsession” extension.

86. Figure: The result of recording – Session file

Double-clicking the name of the session file, the file is opened in the Session editor.
 The recorded communication steps are in separate lines.
 The “Note” item refers to a note you explicitly made during recording.
 A response can be found under the corresponding request.

In case of Browser (HTTP/HTTPS) recording, you can find more and less relevant lines in
the Session file:
 The “Disconnect” items can almost always be disregarded.
 The “POST” communications are always important.
 The “GET” communications for images (“.gif”, “.jpg, “.png” files etc.) are less relevant.
These serve for displaying constant pictures, icons on the screen, which is not an
essential part of the communication.
 Usually the “GET” communications for “.js” and “.vbs” are less relevant too.
 Communications with response code “304” (Not modified) can usually also be
disregarded, as they are retrieved from the cache, rather than from the T24 server.

Page 96 of 116
 User Guide

87. Figure: The session file, opened

Double-clicking on a line of the Session Editor, the details appear in the Log Attribute
Viewer.
 In case of Browser (HTTP/HTTPS) recording the upper part of the Log attribute
viewer also contains the HTTP header parameters.
 Selecting (clicking on) a property name in the upper part, the property value appears
in the scrollable lower part.
 Usually the most relevant properties are the following:

Page 97 of 116
 User Guide

14. Regression testing

14.1 Baseline run, Control run – general methodology
Last major test type supported by TM is regression testing. Point of this test is that the same
set of TSCs is executed on different environments and the results are compared. First
execution is called “baseline”, second execution is “control run”.
The purpose is to verify
 Defects discovered during the earlier execution of the test are corrected
 The modifications/new functions of the system do not result defects or reappearance
of the earlier found and corrected defects
Automated regression testing
 Test execution cycles while all defects are corrected inside one phase of project
 Old functions still work correctly in a new version
Advantages of automated regression testing
 Shorter time duration
 Safer test (no human factor)
 Quality assurance (Assure continuous quality)
 More complex verification (script programming)
 Keep experts to concentrate on the design/testing of new functionalities
 Make order during the last stage of the project when the development is normally
losing control
Post-implementation
 Automate c.a. 80% of manual tests
 Fixed duration and effort
 Low cost
 High quality – high trust in results
 Skip manual tests completely when implementing small changes (small
improvements, patches)
 Do not depend on external resources
 Keep all testing knowledge as a bank’s asset
The changes on the system can be caused by
 New Globus/T24 release upgrade
 Database upgrade
 Local development upgrade
 Service pack install
 operating system patch release
To use this kind of test two different environment projects are needed. One will contain
baseline results, other will contain control results. In RBs Projects tab a Baseline relation
can be set if both environment projects are opened in the workspace. This relation is
mandatory; because TM will know from here which results has to be compared.
Results of compare are the differences. These differences have to be analysed and
organized into defects.

Page 98 of 116
 User Guide

Defects are collection of differences which are connected from a certain point of view. There
are no rules which differences should be put in the same defect, it depends always the goal
of the test; what kind of differences are in focus, this is a decision the test manager has to
make.
Differences are not necessary mean problem. Many differences happen because
executions were performed different time, or T24 generated different IDs for transactions.
But it can show serious problems, wrong calculations, etc.
Regression status can be seen in RBs last column, where in case compare difference file
has been created, numbers show covered/total differences. In case a “?/?” appears, that
means baseline is available but no compare has been executed. An update statistic solves
this problem, but can take some time if result files are large.
Regression test cycle is finished if all involved TSCs are fully covered with defects.

14.2 Differences, maintenace

During the regression test process control execution many differences can occur. Many of
them can be detected before even executing a single test case. These are differences in the
design, the version or enquiry schema. After getting a new environment, TM can perform a
Relearn environment command, which checks if there is any change in the schemas, and
downloads new version or enquiry structure if needed. Then if they cause conflict in the
already implemented test scenarios, TM shows these locations. In the Errors view every
error is listed in the project, but these errors are indicated on the RB on their exact location.
These differences can be a change in a field (added/ removed or renamed), or a change in
the enquiry result structure, in the selection criteria options or in the popup menu action
commands. Many of them can be changed with the help of mass replace option of Eclipse,
but still manual maintenance is required. TM offers a Transform test scenario(s) option
among the reports, which uses an xslt on the TSC design files. In this xslt a change rule can
be defined in xsl language which helps modify blocks in the TSCs (like remove a field, or a
block of fields). This option requires some programming skills.
If the changed items are not used in any test scenarios, then no error will occur, but TM will
download the new schema.
If the current result is better than the baseline, it is possible that the selected Test Scenario
is incrementally added to the baseline Environment project for comparison by selectingthe
’Make current execution result a baseline (will be copied to the baseline project)’ item from
Test Scenario context menu in ResourceBrowser’s Test Scenario tab.

Page 99 of 116
 User Guide

88. Replace baseline with current execution result

14.3 Compare view

Compare has to be done one by one over all TSCs. Opening the result of a TSC in the
editor will enable the “Compare with baseline” button in the middle of the icon row. Compare
result will appear in the same window, but colouring will change. In regression test green
colour means identical result (can be both wrong from functional point of view). Red means
different result (both can be good from functional point of view). Brown means covered
difference, or “duplicate”. Duplicate means that the very same difference appears only once
as red (to be covered), all following appearances will be shown as warnings only. For
example if new fields appear on a version, then they will have to be covered only once, not
in every occasion of the version (where naturally this difference will be present).
Right clicking on a difference opens a context menu with two options: create new defect or
add the difference to an existed defect. Both selections open the Defect wizard, where an
XPath pattern has to be created to cover the difference. These patterns are stored in a
defect, so if a pattern created wisely it may match in other files where same type of
differences will be automatically covered. This check can be done in the wizard, where TM
shows real time results of pattern evaluation and possible matches in TSCs from the same
folder where the analysed file is. Other possibility is from the defect overview.
Covered differences will turn to brown from red, and the background of the red “X” will
change to brown too in the beginning of the row.

Page 100 of 116

 User Guide

There are two navigation buttons in the icon row which can be used to jump between
differences. It can be selected if uncovered differences can be a target, covered difference
or difference which connects to the selected defect (if there is one selected).

14.4 Defect handling

Defects can be seen in the “Defects” view, where some statistics can be seen from them
next to some important connected data like name, description, creator or status.
From the context menu all information about the selected defect can be reached.
 All TSCs can be seen where the selected defect is attached.
 Edit the defect
 Detach the defect from the actually opened TSC
 Delete defect
 Check if the defect has a match in other TSCs selected from a list. In case of finding
any matches defect can be attach to those TScs with checking the checkbox in front
of the name of the TSC. This way when those TSCs will be opened to analyse
matched differences will be shown as covered.
Defects are stored in a database, which is independent from the environments. This means
that defects created during a previous regression test can be used again later. It is also a
good check to see if same differences come up from time to time.

14.5 Defect report

Result of regression test is a report created from the defects. Next to the compare report
(discussed in the stylesheet based reports) this gives a full picture of the results.
In defect report all information can be found about the defects: full description, attached
patterns and all TSCs where it has match. This way it is easy to find where a problem came
up and gives a good start to focus on.

14.6 Defect syncronization

Defects can be stored locally in a defect database, this is the default setup. Defect import
and export is possible when a database record file is created which contains the selected
defects. The exported file can be imported to any other TM instance and be used there
locally.
Other method is to use a single defect database which is shared to all users who are doing
the compare. In this case one TM is dedicated as master, and for all other TM instances this
dedicated TM’s location has to be set in TestManager.ini. The key to be used is: “-
DTM.defect.host” where the master TM’s IP has to be put. In case of changing this value, a
TM restart has to be performed.
Defect database can also be exported to an external program like HP QC. With this option
the defect database can be synchronized with HP QC directly.

Page 101 of 116

 User Guide

14.7 Error reporting

TM supports bugreport creation what can be used for any bug tracking systems like Mantis
or JIRA giving detailed information on Test Scenario and its execution result. In case a
reportable issue comes up, with the bug report functionality from the Support menu TM
helps collecting all relevant data for the issue, then compressing the files and attaches it to
the issue it creates.
In case of TM related issues use the black bug button to export all the relevant information
into a zip file.

89. Bug report Zip creation

This button is only available if a business process, a test scenario or the execution result is
opened in the Resource Browser. This action packs the necessary files such as descriptor
and schema files, packages, Business Processes and Test Scenarios, all these files as part
of a Design and Environment project. It makes a copy also from tm2.log very useful for
issue investigation.

Page 102 of 116

 User Guide

15. TestManager Methodology

15.1 Regression test’s phases
TestManager methodology is demonstrated on the phases of regression test, showing how
they appear in TM. Discussed phases are the following:
 Determination of testing needs (Quality Expectations)
 Test planning (Test Scenariost, Test Casest, execution schedule etc.)
 Test design/implementation (Test Environment, Test Scenarios, Test Data,
configuration)
 Test execution (Baselinet and Control Runt)
 Test result validation (functional checking)
 Comparing test execution’s results
 Defect handling and tracking
 Defect report generation

15.1.1 Test planning

Test planning is a very important phase, the foot-stone of testing.
The optimal choice is when the test experts and banking specialists work together on Test
Specifications. There are less acceptance cycles in this case. Test specifications can be
written in Excel/Word or in any other word processor. The Core Banking Group has Test
Specification template made in Excel.
Separating Test Specifications in different modules – one specification for every module –
takes them more usable and readable.

 Collecting the Test Scenarios covering the criteria given by the Requirement
Specification, Functional Specification and the system design
 Planning Test Scenarios (TSC) in details
o Field input, expected value
o Version commit, authorization, amend, delete, reverse etc.
o Enquiry, selection criteria, expected record(s) as result, expected value
o Report, expected value
o Interface message checking (existence, content)
o Execution day number scheduling
o Notes to explain each step
 Writing Test Specification(s) - output of this phase
o written by business people from Client side or The Core Banking Group test
specialists or together
 Accepting Test Specification(s) by Client – prerequisite of design/implementation
phase

15.1.2 Test design/implementation

Test Scenarios are going to be implemented in this phase.

Page 103 of 116

 User Guide

These are specified by the Test Specification.

T24 Test Environment is set up for automated testing (making backup from original state of
the Globus/T24 environment, creating Globus/T24 users, checking content of HOLIDAY
table etc). T24 Test Environment is a specific copy (created by clear files method) from to
be tested system. It is created so that the test can be run in a measured and monitored
environment.

Creation of TestManager Design and Environment(s) projects

Test Scenario design consists of three steps
 Build - Creation of Execution Plan
 Link - Link data to Test Cases
 Organize - Reuse and organize Test Scenarios in Suites

90. Figure: Test design - Build

Creation of theBusiness Process(BP) by right of Test Specification

 Skeleton of the Test Scenarios
 Days, Phases
o Types of Test Cases
o Version (I, A, S, V, D, R)
o Enquiry, Report
o Interface message (IN, OUT/ONLINE, OFFLINE)
o XML Call Package (XML procedure call entity, callable, reusable,
parameterizable)
Generation ofTest Scenariofile(s) (XMLIN)
 Same structure as BP has (Test Case-> Sequence (Test Case))
 Schema and descriptor files

Page 104 of 116

 User Guide

91. Figure: Test design - Link

 Fill in the Test Cases elements of the Test Scenario file with Test Data needed
during the execution
 Version’s field (valid/invalid input value, expected value)
 Transaction commit (pass, fail, drop, hold)
 XML Call package (input, output parameters)
 Enquiry (selection criteria, 2nd filter on fields/content/page number/row number,
popup menu action, expected result, expected values)
 Interface message (message identification key, expected value)
 Direct, dynamic data
 Data assist mechanism - Ctrl+Space helper
o # References
• Datapool variable
• Relative days
• Transaction id
• etc.
o Concatenation
o XPath functions

Page 105 of 116

 User Guide

92. Figure: Test design - Organize

 Specify the Test Scenarios, Scripts for the execution

 Elements of TestManager Suite (PTXML)
o Default script (CloseGlobus/T24Session)
o Scripts (COB, backup/restore T24 Test Environment, interface handling etc.)
o Business Processes, Test Scenarios
o Sub-suites
o Transactor (day iteration)
o Set day
o Increment day
o Set phase
o Delay

15.1.3 Test execution

 Setting up TestManager Suite before execution
o Set proper day number, day iteration
o Disable unnecessary sub-Suites, Business Processes, Test Scenarios
o etc.
 Run TestManager Suite
 Monitor during running
o Status (receiving, overhead, stopped etc.)
o Number of successful/unsuccessful steps
o Name of the running Script, BP, Test Scenario
o Globus/T24 message
o Number/name of the very moment executed iteration (day)/phase
o Number of succeeded/not succeeded iterations
 Outputs: test report, execution log

15.1.4 Test analysis

 Analysis of the test execution result
 Approach to be followed
o identifying the main risks
o finding as many bugs as possible

Page 106 of 116

 User Guide

o identifying and escalating important problems

o verifying the correction
 Functional checking
o During run
o After run has finished
 Find reason of the unexpected results
o if real error, then bug report
o if error in the test case, then back to test implementation phase, modification
of the test Scenario
o if error in the test plan, then back to test planning phase, modification of the
test plan
 Handle failure during run
o Restart from the last successful step (day, phase, script, TC etc.)
o Continue with next step after fixing problem
 Close earlier bug reports
Test planning
TEST SPECIFICATION

Test design Modify/correct

Modify/correct
XML CALL, EP, XMLIN, PTXML

Specification
Test execution Test Case
error error
XMLOUT, IOXML

Create Test analysis

Real
Bug Report error

93. Figure: Error handling - reason

 Generated log files under Environment project

o XMLOUT (Test Scenario execution result, XML Call package files have their
own xmlout log files, though they are linked to the caller test case’s log file)
o IOXML (TestManager Suite execution result)
o Log files of all suite’s elements having separate execution result, are linked to
the caller suite
o Log files are generated in the same directory structure as the Test Scenarios
are located in Design project
 Label decorations
 Log coloring
 Test Scenario Log Editor Toolbar
 Test Report

Page 107 of 116

 User Guide

94. Figure: Comparing test results

 Filter communication log

 Statistics in log files
o Errors covered
o Errors
o Warnings
 Coloring supporting the compare process
o Red – unassigned error
o Yellow – unassigned warning
o Brown – systematic difference, first occurrence is marked with red
o White – assigned error or warning
o Blue – selected defect
 Jump to previous/next
o Unassigned error
o Selected defect
o Error
o Defect
 .ignoreFromBaseline file
o Used to ignore unimportant differences
o IgnTag: the addition or removal of this element is ignored. E.g. Received,
Sent
o IgnAttribute: a difference in the value of this attribute does not count a
difference. E.g. *.Time
o LogicalAttribute: the changes of the specified attribute are considered
systematic. E.g. TransactionId
 .tagtext file
o Specify which attributes “identify” an element type
o XML elements corresponding method

15.1.5 Defect handling and tracking

 The most important result/product of the testing process
 Defect analysis features
o Search for hits capability on defects
o Assign many files to a defect in one step
o Possibility to import/export defects

Page 108 of 116

 User Guide

o Update statistics on folders includes compare with baseline

o Enhanced statistics including the number covered defects or finished test
cases
o Automatic update of statistics
 Create defect – the occurrence is associated to the defect
o Common, specific defect
o XPath expressions
 Attributes of Defect
o Id, Severity, Priority, Name, Status, Created By, Description etc.
 Defect tracking mechanism (Locally, distributed way)
 Categorization of found difference
o Database difference
o Local development
o Change request
o Fixed error
o Serious error
 Generate Defect Report (style sheets)
o Id, Title, Description, Common XPath, Manual/Automatic Comments,
Occurrences
 Add relevant defects to Defect Tracking System – life cycle from the detection to the
close
 Defect is a common word used for any discrepancy, anomaly, failure, error, issue or
change request that appears during the testing processes
 DTS system provide a lifecycle for defects:
o Reporter report the defect
o Responsible person or reporter assign the defect to developer
o Developer check and fix the error and set the status of defect to resolved
o Tester test the fixed defect and close it or reopen it

Page 109 of 116

 User Guide

16. Terminology
automated Test execution cycles while all defects are corrected inside one phase of
regression project. Old functions still work correctly in a new version.
testing Advantages of automated regression testing
 Shorter time duration
 Safer test (no human factor)
 Quality assurance
 More complex verification (script programming)
 Easier to compare the results of the run
 The software can be taught to ignore trivial differences
automated Test automation is the use of software to control the execution of tests.
testing Advantages of automated testing:
 Test cases will be saved that means we can run again and again.
When test suite run again the duration is shorter than run manually
 Safer test (no human factor)
 Quality assurance
 The software logs every steps what makes easier to find the error
reason
baseline run Execution of a set of Test Scenarios on a well functioning Globus/T24
Environment (e.g. copy of the live environment)
compare The most important phase of regression testing. The earlier executed tests
are executed again against on the new version of the system and the
results are compared.
control data Result of a set of Test Scenarios which were executed on the new, modified
Globus/T24 environment. Usually the Test Scenarios are the same as used
in baseline run, however there are cases when changes need to be made.
control run Execution of a set of Test Scenarios on the modified Globus/T24
environment. The changes on the System can be
 New Globus/T24 release upgrade
 Database upgrade
 Local development upgrade
 Service pack install
 operating system patch release
CVS Concurrent Versions System (CVS) is a free software revision control
system. Version control system software keeps track of all work and all
changes in a set of files, and allows several users (potentially widely
separated in space and/or time) to collaborate.

Page 110 of 116

 User Guide

datapool Enable the storage and handling of data grouped together by some
common properties. Often used in exchanged data between testScenarios
or input data for testCase.
day This is a logical day used in the Test Scenario. The first day contains the
prerequisites of the Test Scenario (e.g. customer, account creation) Usually
there is no need for End of day between the first and the second day.
Second day contains the main transaction(s). The other days contain the
checking and the modification part.
defect Used in regression test. The differences between the reference data and
the control data are called defect because it isn’t sure that the found
difference is an error, it could be an expected change.
design project Place to create Test Cases (which are used many times), Test Scenarios,
TestManager Suites, to store local source codes, style sheets needed to
generate reports. This project stands for planning and creating the Test
Scenarios.
Eclipse The Eclipse Platform is designed for building integrated development
environments (IDEs). It can be used to create diverse end-to-end computing
solutions for multiple execution environments.
environment All execution result files are generated here and also stores all necessary
project datapools needed during Test Scenarios execution, which are implemented
in Design Project. This project contains the login settings and user
definitions.
ERT Extended Regression Testing. ERT means the continuation Quick
Regression testing. The extension can be reached by several ways, like:
 enhancing the Test Scenarios created during QRT for a longer time
span by modifying Test Scenarios implemented successfully
 creating new Test Scenarios with increased complexity (interfaces,
reports etc.) involving more Globus/T24 modules
functional A testing strategy which focuses on whether or not the system has the
testing functions, services, methods and user claims defined by the software
specification.
Globus GLOBUS is an integrated international banking system, which supports the
processes and the operations of banks and other financial institutions.
GLOBUS is a modular package. It is composed of a Core System that
offers all the common operations between the various banking jobs and a
line of modules that covers the different functional requirements of users.
html HyperText Markup Language (HTML). The publishing language of the
World Wide Web. It provides a means to create structured documents by
denoting structural semantics for text such as headings, paragraphs, lists
etc as well as for links, quotes, and other items.

Page 111 of 116

 User Guide

interface A boundary across which two independent systems meet and act on or
communicate with each other.
Interface
Engine Globus/T24 Server
TestManager

T24
DeskTop/
InterfaceEngine 3rd partysystem Browser

3rd partysystem
3rd partysystem

Interface Engine simulates the Legacy systems to achieve the testing of the
communication between Globus/T24 and other systems.
Mantis Mantis is a bug tracking system, a software application that is designed to
help quality assurance and programmers keep track of reported software
bugs in their work.
OFS Open Financial Service is a channel used to mass upload transactions into
T24 directly without user interface.
perspectives A perspective defines the initial set and layout of views in the Workbench
window.
phantom Phantoms are programs what jobs are process messages and forward
messages in a defined way.
phase The logical separation of different phases during a banking day. It makes
the rerun of a part of the day easier and more effective
putty PuTTY is a terminal emulator application which can act as a client for the
SSH, Telnet, login, and raw TCP computing protocols.
QRT Quick Regression Testing. Regression testing executed with low complexity
Test Scenarios on basic modules like Customer, Account and FT. It
provides a numerous coverage for the selected modules. Low complexity
means simple business processes of a short time span (i.e. 1-2 COBs)
without interface simulation.
recorder Recording is a really used function to find the error reason. When you can
do something manually in Globus/T24 but TestManger gives an error you
can record the process and see the communication to find out what's
happening in the background.
reference data Result of a set of Test Scenarios which were executed on a well
functioning Globus/T24 Environment (e.g. copy of the live environment)

Page 112 of 116

 User Guide

regression Regression testing helps to find out whether or not certain changes in the
testing system will or won’t cause problems in those parts of the system which
were not directly affected by those changes. The same Test Scenarios will
be executed again in the modified system, results will be compared and
relevant differences defined as defects.
regular Regular expressions provide a concise and flexible means for identifying
expressions strings of text of interest, such as particular characters, words, or patterns of
characters.
RMI remote method invocation
Standard way for Java applications to communicate with each other
suite A set of the tested code, interfaces, Test Scenarios, execution plans and
other elements of TestManager, necessary for testing.
SVN Subversion (SVN) is a free software revision control system. Version control
system software keeps track of all work and all changes in a set of files, and
allows several users (potentially widely separated in space and/or time) to
collaborate.
T24 TEMENOS T24 is the most technically advanced banking system available
today. T24 is built on open architecture, offers low cost of ownership and
uses established standards such as HTTP, XML and J2EE.
test case Test Case is a basic unit, a simple test step e.g. T24 Version input,
authorize, amendment, enquiry checking, an incoming interface message
creation etc.
test plan A test plan is a systematic approach to testing a system. The plan typically
contains a detailed understanding of what the eventual workflow will be.
test scenario A designed testing workflow of a Business Process to reflect the system’s
(abbreviation functionality. It defines the users’ tasks named Test Cases, the input and
is TSC) output data of the function and the required, expected functioning during the
testing.
test The test specification describes Test Scenarios in details, containing the
specification prerequisites, transaction inputs, amends, checkings, enquiries, reports and
interface messages, each of them defined in proper banking day.
view Views support editors and provide alternative presentations or navigations
of the information in the Workbench.
WinSCP (Windows Secure CoPy) is an open source SFTP and FTP client for
Microsoft Windows. Its main function is secure file transfer between a local
and a remote computer. Beyond this, WinSCP offers basic file manager
functionality

Page 113 of 116

 User Guide

XML Extensible Markup Language. It is classified as an extensible language,

because it allows the user to define the mark-up elements.
XPath XML Path Language is a language for selecting nodes from an XML
document. In addition, XPath may be used to compute values (strings,
numbers, or boolean values) from the content of an XML document.
XSLT Extensible Stylesheet Language Transformations (XSLT) is an XML-based
language used for the transformation of XML documents into other XML or
"human-readable" documents. The original document is not changed;
rather, a new document is created based on the content of an existing one.

Page 114 of 116

 User Guide

17. Table of Figures

1. Figure: Error message for missing or unsupported JAVA _______________________________________________ 7
2. Figure: Login page of The Core Banking Group download/update site ____________________________________ 8
3. Figure: Fill user name and password to login TestManager updatesite ____________________________________ 9
4. Figure: Click on “TESTMANAGER” tab at the top of the screen _________________________________________ 10
5. Figure: Floating license dialog ___________________________________________________________________ 11
6. Figure: Node-lock license dialog __________________________________________________________________ 12
7. Figure: Creating a new workspace ________________________________________________________________ 12
8. Figure: Example for TestManager.ini ______________________________________________________________ 14
9. Figure: Preferences/General _____________________________________________________________________ 15
10. Figure: Preferences/Label Decorations __________________________________________________________ 16
11. Figure: Datapool configuration ________________________________________________________________ 17
12. Figure: Resource Browser Preferences page ______________________________________________________ 18
13. Figure: Resource Browser with active tabs _______________________________________________________ 18
14. Figure: List of default perspectives _____________________________________________________________ 19
15. Figure: Open additional views _________________________________________________________________ 21
16. Figure: EDIT_RUN_PARAMETERS ______________________________________________________________ 22
17. Figure: Create new SVN repository connection ____________________________________________________ 25
18. Figure: New Design Project – Resource browser ___________________________________________________ 27
19. Figure: New TestManager Project ______________________________________________________________ 28
20. Figure: New Environment Project ______________________________________________________________ 29
21. Figure: TestManager Projects – Resource Browser _________________________________________________ 29
22. Figure: TestManager Design Project ____________________________________________________________ 30
23. Figure: Import project form with selected projects _________________________________________________ 31
24. Figure: Convert project to current version ________________________________________________________ 31
25. Figure: Connected design and env projects _______________________________________________________ 32
26. Figure: Design project Preferences page, connect environment project ________________________________ 32
27. Figure: Preferences page for Environment project _________________________________________________ 33
28. Figure: Connections in RB _____________________________________________________________________ 34
29. Figure: Browser specific T24 connection _________________________________________________________ 35
30. Figure: Desktop specific T24 connection _________________________________________________________ 35
31. Figure: User definition screen _________________________________________________________________ 36
32. Figure: Test scenarios overview ________________________________________________________________ 39
33. Figure: Insert new items into a BP ______________________________________________________________ 40
34. Figure: TC modes ___________________________________________________________________________ 41
35. Figure: Create new TSC from BP _______________________________________________________________ 42
36. Figure: Fill input data to a version ______________________________________________________________ 43
37. Figure: Input and expected values in Test Case View _______________________________________________ 44
38. Figure: Enquiry editor ________________________________________________________________________ 45
39. Figure: Initializing helper – first selection ________________________________________________________ 46
40. Figure: Using helper – second selection__________________________________________________________ 47
41. Figure: Helper – full expression ________________________________________________________________ 47
42. Figure: Execution control buttons ______________________________________________________________ 50
43. Figure: Users view __________________________________________________________________________ 51
44. Figure: Version expected value check in Xmlout ___________________________________________________ 53
45. Figure: Enquiry expected value check ___________________________________________________________ 53
46. Figure: IOXML ______________________________________________________________________________ 54
47. Figure: Execution result in Resource Browser _____________________________________________________ 55
48. Figure: Graphs view _________________________________________________________________________ 55
49. Figure: Designing package BP _________________________________________________________________ 58
50. Figure: Create Input parameters in pack Xmlin ____________________________________________________ 58

Page 115 of 116

 User Guide

51. Figure: Create Output parameter in pack Xmlin ___________________________________________________ 59

52. Figure: Assigned Output parameter in pack Xmlin _________________________________________________ 59
53. Figure: Selecting a pack to be called ____________________________________________________________ 60
54. Figure: Fill parameter values for a called pack ____________________________________________________ 61
55. Figure: Helper reference to a pack’s Output parameter – selection mode ______________________________ 61
56. Figure: Helper reference to a pack’s Output parameter – finished expression ___________________________ 62
57. Figure: AA_PARAMETERS datapool _____________________________________________________________ 66
58. Figure: EXAMPLE_IDS datapool ________________________________________________________________ 69
59. Figure: Insert AA Test Case ___________________________________________________________________ 70
60. Figure: Select AA product Line, Group, Product and Mode ___________________________________________ 70
61. Figure: Insert Example ID for AA schema download ________________________________________________ 71
62. Figure: Complexity of AA Test Case Design _______________________________________________________ 72
63. Figure: Do Activity Today AA TC example ________________________________________________________ 73
64. Figure: AA Activity example 1 _________________________________________________________________ 74
65. Figure: AA Activity example 2 _________________________________________________________________ 74
66. Figure: Manipulate AA Product ________________________________________________________________ 74
67. Figure: Get AA Example form HTML ____________________________________________________________ 75
68. Figure: Insert AA example from HTML source _____________________________________________________ 75
69. Figure: Datapool iteration – multiplicity setup in BP _______________________________________________ 77
70. Figure: Datapool iteration – connect datapool to the TC in Xmlin _____________________________________ 78
71. Figure: Datapool iteration - using datapool columns in helper references ______________________________ 78
72. Figure: Datapool iteration – result in the Xmlout __________________________________________________ 79
73. Figure: Create new phase in BP ________________________________________________________________ 80
74. Figure: Items which can be inserted into a suite ___________________________________________________ 84
75. Figure: Selecting TSCs to be executed in Suite property editor ________________________________________ 85
76. Figure: A Main suite with execution result in the Log Folder Browser for each phase _____________________ 86
77. Figure: Creating report from RB context menu ____________________________________________________ 87
78. Figure: Report wizard for stylesheet-based reports ________________________________________________ 88
79. Bug report Zip creation _____________________________________________________________________ 102
80. Figure: Test design - Build ___________________________________________________________________ 104
81. Figure: Test design - Link ____________________________________________________________________ 105
82. Figure: Test design - Organize ________________________________________________________________ 106
83. Figure: Error handling - reason _______________________________________________________________ 107
84. Figure: Comparing test results ________________________________________________________________ 108

Page 116 of 116