User Guide

FOR VERSION 3.0

 Guide 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 __________________________________________________________ 7
1.2.5 Privileges ___________________________________________________________________ 7
1.3 TESTSTUDIO INSTALL _______________________________________________________________ 7
1.3.1 The TestStudio download / update site ____________________________________________ 7
1.3.2 Download of the TestStudio installer ______________________________________________ 8
1.3.3 Installation _________________________________________________________________ 10
1.4 LICENSING ______________________________________________________________________ 10
1.4.1 Online Licensing ____________________________________________________________ 10
1.5 W ORKSPACE ____________________________________________________________________ 10
2. TestStudio setup ____________________________________________________________________ 12
2.1 TESTSTUDIO SETTINGS ____________________________________________________________ 12
2.1.1 TestStudio/configuration/log4j.ini________________________________________________ 12
2.1.2 TestStudio/configuration/config.ini_______________________________________________ 12
2.1.3 Content of TestStudio/TestStudio.ini file __________________________________________ 12
2.1.4 Content of TestStudio/configuration/taris.properties file ______________________________ 14
2.2 GENERAL PREFERENCES ___________________________________________________________ 14
2.2.1 Build information ____________________________________________________________ 15
2.2.2 Datapool configuration ________________________________________________________ 16
2.3 PERSPECTIVE OVERVIEW ___________________________________________________________ 16
2.3.1 TestStudio Design perspective _________________________________________________ 17
2.3.2 TestStudio Debug perspective _________________________________________________ 19
2.4 RUN_PARAMETERS DATAPOOL SETTINGS ____________________________________________ 19
2.5 SVN SETUP _____________________________________________________________________ 23
3. Test projects _______________________________________________________________________ 25
3.1 PROJECT OVERVIEW ______________________________________________________________ 25
3.1.1 Create Project ______________________________________________________________ 25
3.1.2 Import project _______________________________________________________________ 29
3.1.3 Convert project _____________________________________________________________ 30
3.2 RELATIONS BETWEEN PROJECTS______________________________________________________ 30
3.3 T24 CONNECTION SETUP ___________________________________________________________ 32
3.3.1 Browser connection __________________________________________________________ 32

Page 2 of 108
 Guide User Guide

3.3.2 Common connection setup ____________________________________________________ 33

4. Basic design _______________________________________________________________________ 35
4.1 STRUCTURAL OVERVIEW – HOW TO PLAN A TEST SCENARIO __________________________________ 35
4.1.1 Organizing test scenarios _____________________________________________________ 35
4.1.2 Creation of TSC structure _____________________________________________________ 35
4.2 VERSION, ENQUIRY, REPORT ________________________________________________________ 37
4.3 VALUES, EXPECTED VALUE CHECKS ___________________________________________________ 39
4.4 ENQUIRY RESULT RANDOM SELECTOR __________________________________________________ 44
4.5 HELPERS, DYNAMIC VALUES _________________________________________________________ 44
4.6 OTHER DESIGN OBJECTS ___________________________________________________________ 46
4.6.1 T24 COS __________________________________________________________________ 46
4.6.2 T24 TAB ___________________________________________________________________ 47
4.6.3 T24 Arrangement Architecture _________________________________________________ 47
4.6.4 Change company____________________________________________________________ 47
4.6.5 Java Script and jAgent ________________________________________________________ 47
4.6.6 Choice ____________________________________________________________________ 48
5. TestStudioBasic execution ____________________________________________________________ 49
5.1 EXECUTION WITH XMLINEXECUTOR____________________________________________________ 49
5.2 EXECUTION MONITORING ___________________________________________________________ 50
6. Log analysis ________________________________________________________________________ 51
6.1 XMLOUT, IOXML ________________________________________________________________ 51
6.2 INFORMATION IN RESOURCE BROWSER _________________________________________________ 53
6.3 TESTSTUDIO LOGS ________________________________________________________________ 54
7. Advanced design ____________________________________________________________________ 55
7.1 PACKAGES, PARAMETERS (INPUT, OUTPUT, LOCAL)________________________________________ 55
7.1.1 Design a package ___________________________________________________________ 55
7.1.2 Callable – once or many ______________________________________________________ 55
7.1.3 Create package _____________________________________________________________ 55
7.1.4 Call a package ______________________________________________________________ 58
7.1.5 Local parameters ____________________________________________________________ 60
7.2 DATAPOOLS_____________________________________________________________________ 60
7.3 MULTI-LEGGED TRANSACTIONS _______________________________________________________ 61
7.4 POPUP WINDOWS _________________________________________________________________ 61
7.5 T24 AA AUTOMATION _____________________________________________________________ 62
7.5.1 AA datapools _______________________________________________________________ 63
7.5.2 AA tab on Resource Browser __________________________________________________ 65
7.5.3 Automate AA New Arrangement ________________________________________________ 65
7.5.4 HTML source or Example ID ___________________________________________________ 68
7.5.5 Expected value checking in AA _________________________________________________ 69

Page 3 of 108
 Guide User Guide

7.5.6 Multi SubVersion support _____________________________________________________ 69

7.5.7 Using AA in See mode from T24 Command line ____________________________________ 73
7.5.8 Automate AA Activities _______________________________________________________ 73
7.5.9 Executing AA Test Scenarios __________________________________________________ 75
7.5.10 Non-English language support _________________________________________________ 76
7.5.11 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 WITH ENQUIRIES _______________________________________ 81
8.5 CONDITIONAL EXECUTION WITH LOGICAL EXPRESSIONS _____________________________________ 81
9. Non-English language support _________________________________________________________ 82
9.1 LANGUAGE SUPPORT WITH ENQUIRY TABLE ____________________________________________ 82
9.2 EB.DICTIONARY ________________________________________________________________ 82
9.3 GENERAL CASES – TXN COMPLETE AND TXN VERIFIED ____________________________________ 82
10. Advanced execution _______________________________________________________________ 83
10.1 SUITES ________________________________________________________________________ 83
10.1.1 Create Suite ________________________________________________________________ 83
10.1.2 Suite structure ______________________________________________________________ 83
10.2 MAIN SUITE, STANDALONE SUITE _____________________________________________________ 86
10.3 DESIGNING TESTSTUDIO SUITE FOR PARALLEL EXECUTION___________________________________ 87
10.3.1 Multiple User Groups _________________________________________________________ 88
10.3.2 Multiple T24 users ___________________________________________________________ 89
10.3.3 Synchronization Points _______________________________________________________ 89
10.4 MONITORING THE TESTSTUDIO EXECUTION ______________________________________________ 92
10.5 EXECUTION FROM COMMAND LINE _____________________________________________________ 92
10.6 ERROR HANDLING SUPPORTS ________________________________________________________ 93
11. Reporting ________________________________________________________________________ 94
11.1 REPORTS FROM DATABASE (BIRT) ____________________________________________________ 94
12. Interfaces ________________________________________________________________________ 96
12.1 INTERFACE DESIGN _______________________________________________________________ 96
12.2 INTERFACE CONNECTIONS IN INTERFACE ENGINE _________________________________________ 96
13. Regression testing _________________________________________________________________ 98
13.1 BASELINE RUN, CONTROL RUN – GENERAL METHODOLOGY __________________________________ 98
13.2 DIFFERENCES, MAINTENACE _________________________________________________________ 99
13.3 COMPARE VIEW _________________________________________________________________ 100
13.4 DEFECT HANDLING _______________________________________________________________ 101

Page 4 of 108
 Guide User Guide

13.5 DEFECT REPORT ________________________________________________________________ 101

13.6 DEFECT SYNCRONIZATION _________________________________________________________ 101
13.7 ERROR REPORTING ______________________________________________________________ 101
14. What is new in TestStudio 3.0 _______________________________________________________ 103
14.1 TARIS REPOSITORY INTEGRATION ____________________________________________________ 103
14.1.1 TestStudio Setup for TestStudio Integration ______________________________________ 103
14.1.2 TestScenario Import Process from Taris Repository ________________________________ 103
14.1.3 TestScenario Import TestScenarios with Prerequisites______________________________ 104
14.2 AUTOMATIC PACKAGE GENERATION___________________________________________________ 104
Terminology ___________________________________________________________________________ 105

Page 5 of 108
 Guide User Guide

1. Introduction
1.1 Terms and abbreviations
This chapter contains information about how to start using TestStudio. Most of the connected tasks
should be done by system administrators, so to have all information in these topics please refer
TestStudio 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:
• TestStudio: this is the abbreviation of TestStudio, 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 TestStudio. A list of
TCs which to be perform during test process (without input and output data).
• ENQ: T24 enquiry
• RB: TestStudio’s Resource Browser
• IE: Interface Engine

1.2 Requirements
TestStudio 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

Atoma recommends the following configuration for a TestStudio 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 minimum of 1280*1024-pixel resolution

1.2.2 Supported platforms

TestStudio is supported on the following operating system versions:
• Microsoft Windows 7 Professional / Enterprise / Ultimate, 64-bit edition, Service Pack 1 or
above.
• Windows 2008, 2012, 2016 Server 64-bit edition
• Windows 10

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

Page 6 of 108
 Guide User Guide

1.2.3 Supported Java™ versions

TestStudio is an Eclipse based application; therefore, a JAVA SDK or JRE must be present on the
workstation.
TestStudio requires Sun / Oracle Java™ 8 64-bit edition Java™ Runtime version update 91 or 92 or
later.
NOTE:32-bit edition of TestStudio is not supported anymore.
Error message appears if Java is not presented on the computer, or default Java is not added to the
PATH or its version is not matching requirements above. In case Java is present, but can’t be included
in the PATH, a location can be given to TestStudio in its .ini file under –vm argument. Please check
Section 2.1.3 for further information.

1.2.4 Additional softwares

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

1.2.5 Privileges
TestStudio 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 TestStudio install

1.3.1 The TestStudio download / update site
The official downloads / update page of TestStudio (and other products of Atoma):
can be found in Taris site
https://url:port/taris-sso/
Url and Port can be varied as per the company.

Page 7 of 108
 Guide User Guide

1. Figure: Login page of Taris

1.3.2 Download of the TestStudio installer

Atoma can provide information about the latest stable version of Taris which includes TestStudio to
be downloaded for installation.

Steps of the download process:

1. Open Taris, by using your company Taris site

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

2. Figure: Fill user name and password to login Taris

Page 8 of 108
 Guide User Guide

3. Figure: Click on “TestStudio” tab in the Atoma Taris Modules

4. Figure: Click on “TestStudio install Pack”

Page 9 of 108
 Guide User Guide

1.3.3 Installation
The installation of TestStudio does not require administrator or power user privileges.
The installation needs at least 400 MB free disk space - TestStudio can generate a lot of big-sized
execution log files - 100 GB free disk space is recommended.
Atoma recommends selecting other disk partition than the operating system partition for the
TestStudio installation if possible.
The TestStudio installer is a ZIP compressed file - it must be uncompressed to a new folder (even if
an earlier version of TestStudio has 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 TestStudio installation to the operating system user which will
use TestStudio.

1.4 Licensing
TestStudio requires a valid license to operate. It can be setup during first start of any TestStudio
product.

1.4.1 Online Licensing

License requires a license server operating in the visible network. TestStudio licenses are stored on
this license server, and if there is any available one, TestStudio product occupies one for the time it
is running. In this model, the total number of TestStudio 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 TestStudio license on the server, a green OK appears and the “OK” button becomes
enabled, TestStudio can start. License server settings are stored in TestStudio workspace, it will be
checked automatically every start, and if there is a free TestStudio license, the dialog window won’t
appear.

4. Figure: Floating license dialog

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

Page 10 of 108
 Guide User Guide

When first start TestStudio then the first workspace is automatically created in the TestStudio root
directory.

5. Figure: Creating a new workspace

In case a non-existing location is selected, TestStudio automatically creates new workspace in the
given location.
Please note that there cannot be “white space” or special character in the path of the workspace.

Page 11 of 108
 Guide User Guide

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

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

2.1.3 Content of TestStudio/TestStudio.ini file

Specific memory usage and Java information can be changed in TestStudio.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 TestStudio should use.
With this setting, a specific Java can be attached to TestStudio. Useful if more than one Java instances
are installed on the workstation. This setting has to be used if the PATH doesn’t contain 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.
When TestStudio is installed on a Windows Server, it can be used by multi users.
Starting the same TestStudio instance will use the same workspace.
-data parameter has to be changed in this way:
-data
%HOMEPATH%/workspace
Which will open a workspace from the home directory of the user
Memory setting is very important part for proper work. If more memory allocation is set for TestStudio
than what is even possible, then TestStudio won’t start. Memory is used dynamically, which means
that TestStudio 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)
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 64-
bit version Java with 4 GB total RAM.

Page 12 of 108
 Guide User Guide

6. Figure: Example for TestStudio.ini

There is an option to start automatically a suite execution by a Windows command.

The following 2 parameters have to be added:
• runSuite
• shutdownAfterRun
For more details, please check automated suite runner functionality part.

‘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. TestStudio 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

Page 13 of 108
 Guide User Guide

2.1.4 Content of TestStudio/configuration/taris.properties file

The taris.properties file contains the connection URLs to connect to TARIS. From the TARIS Test
Assistant module Test Scenarios manually recorded Test Scenarios could be imported. Single-
Sign_on authentication settings of TARIS have to be used here.
For proper connection the following settings have to be updated in this configuration file:
sso.context=
The default context which is “taris-sso”.
sso.user=
A TARIS user created in the EnvironmentManager to use to authenticate for importing TestScenarios.
sso.password=
The TARIS user password.
sso.host=
The TARIS host name.
sso.port=
The TARIS Single-Sign-On authentication service port number.
ta.context=
The default context for the TestAssistant REST API which is tats/rest.
ta.host=
The TestAssistant host name.
ta.port=
The TestAssistant port number.

7. Figure: Example of the taris.properties file

2.2 General preferences

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

Page 14 of 108
 Guide User Guide

8. 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 TestStudio Suite are automatically regenerated on saving the
TestStudio 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 108
 Guide User Guide

2.2.2 Datapool configuration

9. Figure: Datapool configuration

• TestStudio specific settings

• Datapool Server settings
o The name or IP address of the host running the RMI 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 TestStudio should
scan the project directory for datapool files

2.3 Perspective overview

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

Page 16 of 108
 Guide 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 TestStudio window
• Functions: Open Perspective, Reset Perspective, Close Perspective, Close All Perspectives
• TestStudio views are automatically assigned to different perspectives

10. Figure: List of default perspectives

The default TestStudio specific perspectives are the following:

2.3.1 TestStudio 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 TestStudio 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 TestStudio design and environment projects
and their relations. It shows the active (selected) design project too.
o Test suite: Shows all created TestStudio 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 Packages: TestStudio package objects are shown here, which are test templates used
in advanced test methods.
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.

Page 17 of 108
 Guide User Guide

o COS: Similar to the Versions but T24 COS screens are shown here.
o TAB: Similar to the Versions but T24 TAB screens are shown here.
o Menu: Shows downloaded T24 menus.
o Datapools: all datapool related functions and settings can be managed here.
o Interfaces: Shows all TestStudio implementations for interfaces. These are version like
layers which help creating interface message contents or check interface message
results.
o Scripts: Shows all available java scripts, including internal TestStudio scripts.
• File Explorer: a system-based view of the TestStudio projects
• Problems: a list of warnings and java build problems.
• Defects: a view to organize and report regression test defects.

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

Page 18 of 108
 Guide User Guide

categories such as TestStudio.general, TestStudio.execution, TestStudio.design using the

Group by Plugin option in the right top of the window.
• Stylesheet Admin View: a view with all xslt based transformations, 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 TestStudio Debug perspective

• Execute TestStudio Suites
• Monitor the execution process – progress information
• Debug exceptions, errors occurred during run

2.4 RUN_PARAMETERS Datapool settings

Run Parameters is a technical datapool, which contains environment specific settings, and setup
options 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.
RUN_PARAMETERS datapool can be edited in TestStudio Datapool perspective with a valid
TestStudioTestStudio environment project.

Page 19 of 108
 Guide User Guide

12. Figure: RUN_PARAMETERS

Page 20 of 108
 Guide 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 file.
• #UNIX_LOGIN_PROMPTS: used for UNIX login
• #VERSION_PATTERN: used only for desktop
• #T24RXX_XSLT: the T24 version is being 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. Multiple scripts 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. Multiple scripts 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.
• #ENV_ROOT: The parameter is used as a reference in MessageTargetDescription in
IN_Config_DP which is important for Interface testing. TestStudio resolves
RP[#ENV_ROOT] in Interface Engine to the current environment project location only if the
parameter doesn't exist in Run Parameters. Otherwise it is resolved for the value of the
parameter.
Further parameters can be:
• #PHASES: the list of test phases to use in the Business Process.
• #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 21 of 108
 Guide 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 being 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: “.TestStudioFileLog.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 TestStudio
saves only the first page’s screenshot of the ENQ result, because of size problems. In case
the user needs all screenshot it can be set with this key.
• #FILTER_BY_TRID: a logical selection for interface messages caught by TestStudio. 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 TestStudio keeps the message as it was created based on
one of TestStudio’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.

Page 22 of 108
 Guide User Guide

• #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.
• #XMLIN_EXECUTOR_TIMEOUT: time to wait to finish the execution. The session is still alive
so if starting a new execution there will be no need to login again.
• #projName: project name to display in the reports.
• #sutVersion: version of the System Under Test to display in the reports.
• #testCycle: test cycle description to display in the reports.
• #testStartDate: the starting date of the testing to display in the reports.

2.5 SVN setup

A version controller, like SVN or CVS is recommended to store TestStudio 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, TSCs created in different TestStudio instance can be shared this way between project
members.
An existing Version controller can be attached to the TestStudio 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.

Page 23 of 108
 Guide User Guide

13. Figure: Create new SVN repository connection

From a live connection, TestStudio 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 TestStudio, showing its state 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 24 of 108
 Guide User Guide

3. Test projects
3.1 Project overview
TestStudio organizes Test Cases into projects. TestStudio uses two types 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 accessed in the TestStudio Design perspective’s Projects tab of the RB, where
projects can be created, imported or edited. Project name must be unique; TestStudio checks it during
project creation and gives error message in case of conflict.

3.1.1 Create Project

14. Figure: New Design Project – Resource browser

Page 25 of 108
 Guide User Guide

15. Figure: New TestStudio Project

New TestStudio Design Project can be created 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 → TestStudio Design Project
o New → TestStudio Environment Project

Page 26 of 108
 Guide User Guide

16. Figure: New Environment Project

Icons:
• TestStudio Design Project
• TestStudio Environment Project

TestStudio Design Project – is a place to create XML Call packages, Business Processes, Test
Scenarios, TestStudio Suites, to store local java source codes
TestStudio 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 TestStudio Environment Projects are shown under the related Design
Project. The selected project is marked by bold; it can be activated by double clicking on the selected
Project.
All log files from the selected environment project can be deleted from the Resource Browser using
the context menu’s “Delete execution logs” menu item.It is also possible backup the log files with the
Create Snapshot menu item from the same RB context menu. The result is a zip archive containing
all log results from the log and scenarios folder.

Page 27 of 108
 Guide User Guide

17. Figure: TestStudio Projects – Resource Browser

18. Figure: TestStudio Design Project

19. Figure: Delete execution logs

Page 28 of 108
 Guide User Guide

3.1.2 Import project

TestStudio projects can be imported into the workspace with the Import project context menu option.

There are two options:

• Select a root directory, from where the projects can be imported or

• Select archive file to import a zipped archive which could contain more projects.

Projects cannot be overwritten. TestStudio recognizes the 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 TestStudio 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.

The link between the test scenario and test scenario execution will be automatically established.

In addition, the .xsd files for .vsd and .bp files will be automatically generated so no rebuild will be
needed after importing a design project.
If there are any missing descriptor files (.vsd) then TestStudio starts to download them as part of an
automatic rebuild. Note that info user must be uniquely created and the same user must not be used
for execution or there could be a Security Violation on the instance used for execution.

20. Figure: Import project form with selected projects

Page 29 of 108
 Guide User Guide

3.1.3 Convert project

TestStudio 3.0 can convert TestStudio 2.6.13 projects. If the project to be imported was made with an
earlier version of TestStudio then first it has to be converted to TestStudio 2.6.13 version, then it can
be imported to TestStudio 3.0 and to be converted.
After performing the project conversion, a relearn and rebuild action must be executed!

21. Figure: Convert project to current version

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.

22. Figure: Connected design and env projects

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

Page 30 of 108
 Guide User Guide

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

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.
Like the connection settings, there are additional preference pages such as:

• AA parameters
• Browser specific settings
• Builders
• Desktop specific settings
• Environment project preference
• Generic logging
• Interface handling
• Other Property Page
• Report settings
• T24 Environment specific settings
• T24 login and user definition
• Test execution specific settings

Page 31 of 108
 Guide User Guide

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

25. Figure: Connections in RB

3.3 T24 connection setup

T24 environment connection can be setup in the environment project’s Preferences page, under “T24
login and user definition” screen. This form contains all information required for login.

3.3.1 Browser connection

BrowserWeb connection can be setup in the T24 tab. It requires host name, port and proper folder
information of the environment. TestStudio supports different type of browser protocols from R8 to
R20, 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 TestStudio
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.

Page 32 of 108
 Guide User Guide

TestStudio 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 (in T24 communication date appears with ‘-‘ separations instead of space).

26. Figure: Browser specific T24 connection

3.3.2 Common connection setup

Columns to be filled for user setup are:
• “T24 name”: is the SIGN.ON.NAME of the user
• “T24 password”: which is defaulted to 123456
• “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 TestStudio can answer
these questions automatically. Can left blank in case there is no teller open for the user.

TestStudio 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 deprecated. It was used for desktop connections to disconnect hanging users
during the execution.
• 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.

Page 33 of 108
 Guide User Guide

27. Figure: User definition screen

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.
Defined user’s login can be tested individually for Info user and SOR user by pressing Test button.
Pressing “Test all” button tests all defined user’s login including Globus test users. The initiated test
all job can be cancelled as it may take too much time when the environment is not available.

Page 34 of 108
 Guide User Guide

4. Basic design
4.1 Structural overview – how to plan a test scenario
Basic element of a test design is called Business Process (BP). This is the skeleton of the test, a high-
level workflow structure, containing all test cases in the correct order, as they appear during the
workflow. A BP covers an end-to-end 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.

28. Figure: Test Scenario structure

4.1.1 Organizing test scenarios

First level of organizing test scenarios is the 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 TestStudio. 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 TestStudio Design
perspective. Best option is the Resource Browser, which offers all required tools and information which
are needed during design.

Page 35 of 108
 Guide User Guide

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.
New sequences can be added to “Phase” named items in different ways.
• By right clicking on it and select “Add new…”
• If a T24 menu was downloaded earlier, one or many menu items 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.
• TestStudio packages can also be added with drag & drop.
For every sequence in the BP a specific user should be assigned. This can be a default user. In this
case no extra action should be done. Default rule is that Default Auth user do authorization mode test
cases, 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.
TestStudio 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 must be selected manually for each sequence where
this would be used. For OFS protocol the OS login section should be filled with a user who is in T24
group (login promt is in jShell). In this protocol TestStudio 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 36 of 108
 Guide User Guide

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 TAB Screen
• T24 Composite Screen (COS)
• Interface
• Java Script
• TestStudio Package
• Choice
• Change Company
• jAgent

29. Figure: Insert new items into a BP

Each screen 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)

Page 37 of 108
 Guide User Guide

• S(ee)
• V(erify)
• D(elete)
• R(everse)
Saving the BP triggers an automatic schema download process, when TestStudio tries to get structural
information for each version, enquiry, COS and AA. With the help of this information TestStudio can
show a T24 look and feel editor to fill input data. TestStudio 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 TestStudio tries to open the given record, and builds version schema
based on that record.
The version design download process is the following:
1. Tries to open version I mode with NEW id
2. If fails, re-tries to open version I mode with NEW1 id
3. If fails, re-tries to find a suitable id by executing the %VERSION.NAME enquiry and then open
version in I mode
4. If fails, reties in S mode
If it still fails, the user will receive a very detailed error log about the full process.
In case the version design to be downloaded contains sub-versions (and it is not an AA product),
then a html source has to be provided to this particular version. It can be added on the Resource
Browser’s ‘Versions tab’. First the html source has to be copied to the clipboard by opening the
version manually in browser, then from context menu switch to show page source, then select all
(CTRL+A) and copy (CTRL+C). Then in TestStudio on versions tab locate the particular version,
and its context menu select “Create descriptor using html”. As a result TestStudio will take the
content of the clipboard, and create the sub-version contained version schema.

Page 38 of 108
 Guide User Guide

30. Figure: TC modes

4.3 Values, expected value checks

After creating BP structure, XMLINs should be created. It can be done from Test Case Editor’s “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.

31. 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, then expand it to the main version level
(or any required sub-version level) 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. TestStudio will fill this field with this value.

Page 39 of 108
 Guide User Guide

For easy navigation TestStudio offers a search panel where a field name or a part of it can be entered.
Then TestStudio focuses automatically on 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 TestStudio 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
TestStudio 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, TestStudio also offers them during design time. In case of dropdown
fields TestStudio checks that the input value exists in the choice list. If it doesn’t then the field value
settings do not happen but an error is logged unless the field is set as invalid. Multiline field can be
designed with a help of #ML() helper.
In some cases T24 automatically generates a deal slip during a transaction commit. TestStudio 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. TestStudio 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 TestStudio 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.
TestStudio supports capturing and checking status bar messages for each window. This can be set
through an attribute similar to deal slip.

32. Figure: Fill input data to a version

Page 40 of 108
 Guide User Guide

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. TestStudio 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), TestStudio
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/static data or dynamic, calculated values.
For each version field TestStudio can check its enrichment, the “comment” text appears next to the
field value. This check works like the field value checks, except this expected value has to be set as
a field attribute.
TestStudio recognizes dynamic schema changes such as hot field changes during version execution.
In case a hot validation changes another field as hot validation field, TestStudio 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 TestStudio can check field values in the second level filter. In this case TestStudio
checks the expected value for all fields in the selected column, so in this case best practice is to have
a single row as result. To get this one specific row to be checked a second level filter option helps to
find the requested row. TestStudio can create many second level filter selections 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 row is selected to be checked, no popup menu action
should be used!
For better understanding TestStudio can filter empty rows from enquiry result in the log. This option
has to be set in the enquiry editor.
Enquiry Header fields are properly recognized by the schema downloaded from ENQUIRY and
ENQUIRY,DESIGNER T24 applications and shown in the execution result in header line and their
values related fields. They are also available for filtering in the second level filter and can be identified
by their description names if exists in the T24 design otherwise by their technical names. If the filter
field name is different in execution time than in design time, in the second level filter’s field name
column the name can be edited manually after a double click on it. This way any fields or columns can
be filtered no matter what the schema contains.

Page 41 of 108
 Guide User Guide

33. Figure: Edit enquiry second level filter field

TestStudio supports check of all fields in the enquiry result header. Expected value has to be set
similar as any other field in rows.
T24 Report content can be checked with enhanced regular expressions. Search patterns can be
created with regular expressions combined with TestStudio 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 tags can be checked.
TestStudio 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

Page 42 of 108
 Guide User Guide

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

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

Page 43 of 108
 Guide User Guide

TestStudio supports Unicode character encoding. Default code page is UTF-8.

4.4 Enquiry result random selector

When implementing a Test Scenario we might encounter the situation that requires using a different
value each time we execute it. Good example is usage of migrated data instead of synthetic data
when the requirement is to pick up different existing identifications from database by launching an
enquiry with a specific filtering.

The random selector is an Enquiry Attribute that can take the following values:
• TRUE TestStudio will pick one item from the enquiry result records.
• FALSE TestStudio will pick the first item from the resulted records.

To add the random selector attribute to the enquiry:

1. Select the Enquiry and expand its Input Data

2. Select the “Result Section” and click on it to show its XML Attributes
3. On the XML Attributes View press “A” or click on the “Add new attribute” window
4. Select the randomSelection
5. Set the value to TRUE

Even though we have added the randomSelection attribute to our Enquiry, if we were to execute the
Enquiry we will notice that not selection is being done, for this we need to use the popUpMenu actions
from the Second Level Filter, depending on the type of Enquiry we should set its value to anything
besides the default “None” option. This means that random selector is activated with a drill down action
only.

4.5 Helpers, dynamic values

To make connections between each TC in an Xmlin or between different TSCs, TestStudio offers a
large variety of special field values, which are the so called “Helpers”. They are TestStudio built in
functions which help in design time to connect one field to another, or to make the TSC “environment
free”.
Helper engine can be initiated in any version fields, enquiry fields and in any attributes in XML Attribute
View by pressing CTRL+Space. Then the helper engine will guide the expression creation process
providing the proper syntax of the selected function.
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.

Page 44 of 108
 Guide User Guide

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 environments giving
the possibility to check the difference between each T24 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 TestStudio 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.

36. Figure: Initializing helper – first selection

Page 45 of 108
 Guide User Guide

37. Figure: Using helper – second selection

38. Figure: Helper – full expression

4.6 Other design objects

4.6.1 T24 COS
TestStudio 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 result, then the first level selection

Page 46 of 108
 Guide User Guide

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.
TestStudio offers these containers automatically. They are downloaded as COS schema, similar then
a version or enquiry schema. For those cases, where there are missing drilldowns or sub screens
after design downloading, a warning icon is displayed and it can be checked by expanding the details
of the object.
Every area touched during execution has to be a separated COS test case in the BP.

4.6.2 T24 TAB

Like T24 COS, TestStudio can open any kind of Tab separated objects (TAB), but only one part of it
at a time (like manually). 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 test case in the BP.

4.6.3 T24 Arrangement Architecture

Using TestStudio 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 chapter
7.5 T24 AA Automation.

4.6.4 Change company

This test case can “move” the selected T24 user to a different T24 company. Result does the manual
process for change user’s company. It has two parameters, first is the user nick used in TestStudio,
the other is the target company’s name. TestStudio 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, the user remains in the selected company as
long as its session is active, or change again with another change company test case. After a new
login user is put to its default company. One test case in a BP has effect on one user only.

4.6.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 must be part of the TestStudio project, which means that if it was not created
in TestStudio, it has to be imported (perform a refresh in File explorer) into TestStudio (Eclipse). Java
scripts can contain any commands, therefore 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 the help of Java scripts TestStudio can support Selenium test executions on a non-T24 system
(e.g. TCIB or Triple A), or even a mobile app test (e.g. TCMB).
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 47 of 108
 Guide User Guide

4.6.6 Choice
Choice test case is a container which can contains multiple number of any other test case types,
where every one of them has a condition. During execution the first TC in its content list will be
executed which condition is true, and the rest will be skipped. It is useful, if the same logical step in a
business process flow has different T24 object depending on some conditions, e.g. in case of a teller
cash in the version might be different if the currency is local or foreign.
For more details about conditions please refer chapter 8.5.

Page 48 of 108
 Guide User Guide

5. TestStudioBasic 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, TestStudio 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. TestStudio 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 TestStudio 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.

39. 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).
When a TSC is executed, either with XmlinExecutor or with any other test suite, the remaining of the
TSC execution will be skipped in case a blocker error happens in any TC (even if the TC is in a
previous day or phase). A blocker error is a failed status caused by a transaction with a failed commit
or a drill down action that couldn’t be executed. This feature can be switched off in the suite launch
property page (Run configuration window access from the toolbar then “Skip test cases after blocker
errors” option for TestStudio suites).

Page 49 of 108
 Guide 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 TestStudio 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.

40. Figure: Users view

Page 50 of 108
 Guide User Guide

6. Log analysis
6.1 XMLOUT, IOXML
Execution result appears in two main log files, 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 and the “Time”
columns showing when certain test cases and test steps were executed. 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 executions
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: TestStudio 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 TestStudio 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 51 of 108
 Guide User Guide

41. Figure: Version expected value check in Xmlout

42. 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.
Xmlouts can be opened in TestStudio Design perspective, when a TSC is opened in the Test Case
Editor. The last tab opens the corresponding log result.

Page 52 of 108
 Guide User Guide

IOXml can be opened from the Log folder browser view, when a suite is opened in the Test Case
Editor.

43. 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 found runtime
• 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.
Design errors resulted during the BP or TSC automation are marked with an error icon in the Test
Scenario tab where folders also show inherited design errors. These design errors can be identified
by analysing the files themselves without executing them.
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 53 of 108
 Guide User Guide

44. Figure: Execution result in Resource Browser

6.3 TestStudio logs

While working TestStudio creates some log files which contains information about the whole process.
These log files are only important if an error occurred in TestStudio.
Main log file is “ts2.log”, which is in the root directory of TestStudio. It contains all information which
was printed to the screen, and a lot more Info, 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.
Another log file called “.log”, located under “workspace\.metadata”, contains TestStudio 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 54 of 108
 Guide 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 package

A package should contain test cases 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 its 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 test case, only the last result will remain because all execution will
overwrite the previous ones. To avoid this problem a group of input parameters should be set as
“postfix” parameters, where the actual value of them will form a unique text. Adding this text to the
name of the pack file name will keep all log results because the name of the pack will be different.
This setup can be done in BP level, while selecting an Input parameter, then in the XML Attribute view
change the postfix attribute to true for each members of the set.

7.1.2 Callable – once or many

What makes a package to be a package is an attribute in the top element of its Business Process’
XML, called callable. For standard test scenarios this attribute’s value is false. When it is not false,
then the Business Process, and the test scenarios created based on it are considered as packages.
The other values are “once” or “many”.
Once – is used when the content of the package can’t be executed more than once but has to be part
of the test pack. When a package is callable once, then at its first occurrence it will be executed, but
its execution log is stored separately. For every following call for this package will link this first
execution result and use the parameter values from there.
Many – the package can be called without limitation (this is default behaviour); every time is executed
normally and creates execution result for every execution. The result is every time creates different
transaction in T24.

7.1.3 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 must 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 55 of 108
 Guide User Guide

45. 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 and
value which should be used in the pack.
Input parameters are used for transferring values into the pack, while output parameters are returning
data. There is no other way to get values from the pack, just through output parameters.

46. Figure: Create Input parameters in pack Xmlin

Page 56 of 108
 Guide User Guide

47. 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 which values should be stored 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 domain.

48. Figure: Assigned Output parameter in pack Xmlin

Page 57 of 108
 Guide User Guide

7.1.4 Call a package

Packages must be called by a “standard” 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.

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

50. Figure: Fill parameter values for a called pack

Page 58 of 108
 Guide User Guide

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

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

Page 59 of 108
 Guide User Guide

7.1.5 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 like 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 like in packages: 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.

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 Resource Browser’s Datapool tab. 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 five 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.
• FIFO datapool: this is a virtual datapool, exists only while TestStudio is running, so any data
stored in it will be lost when TestStudio 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 or server as well.
Datapools can be read and write with the use of helpers:

Page 60 of 108
 Guide User Guide

• #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 field’s expected value. In case the key doesn’t exist,
TestStudio will automatically create it.
o In case of enquiries with multiple results, #DPP (and other similar actions) will be
called automatically for each row. The result value can be stored in the first column of
the datapool (key value) using the expression #DPP(‘datapool name’). If multiple
values from the same entry should be written in the same record in the datapool, the
other fields can be stored with #DPP(‘datapool name’, #EFIELD('key field'), ’column
name’), where ‘key field’ is the enquiry field used as key value.
There are some technical datapools which are created automatically with the environment project:
• RUN_PARAMETERS datapool contains technical parameters connected to the environment
• TransactionID datapool 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.
• GLOBUS_TEST_USERS datapool 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 TestStudio is that it opens a screen, gives some input, do a commit
then returns to the T24 command line screen. In T24 there are some transactions where input goes
through many versions, or enquiries. Typical 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 TestStudio must follow T24, that after “committing” a test case the next test case will
automatically open and therefore a different opening procedure has to be taken (practically the next
screen will be opened without doing anything). This following screen opening is detected
automatically, it just requires a corresponding test case with input data in the business process and
test scenario, depending what T24 object is coming.

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

Page 61 of 108
 Guide User Guide

7.5 T24 AA Automation

TestStudio supports AA test case design the same way as for all versions, through the Version editor.
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 a time.
The way in which TestStudio learns the AA schemas is not the same as how it learns Versions, for
these ones, a series of multiple steps are performed which results in a properly created schema of the
desired AA.
TestStudio 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.
TestStudio uses the AA Product Catalog for both default AA schema download and AA TSC execution.
By default, the core Product Catalog is taken. We also support the Bank’s specific Product Catalog(s).
When first interact with an AA product in test scenario design, TestStudio offers to learn AA Product
Catalog’s structure from the selected T24 environment and store it in a file. This download is optional,
however strongly recommended as it helps a lot in test scenario design. The AA structure will appear
in Resource Browser’s AA tab as well, and the recognized products will appear for drag&drop
automatically. AA structure download also offered in case of test scenario import.
TestStudio uses the following enquiries 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
If a customized Product Catalog needs to be used, in case of testing AA product in a Bank specific
and customized T24 environment, these Enquires can be overridden in the datapool
AA_PARAMETERS using the following keys:
• #ENQ_NAME_OF_PRODUCT_LINE: customized product line enquiry name
• #ENQ_NAME_OF_PRODUCT_GROUP: customized product group enquiry name
• #ENQ_NAME_OF_PRODUCT_CATALOG: customized product catalog enquiry name
If there are still products in the test pack using the standard Product Catalog, however for some special
products there is a need to use the customized version. It is possible to use the customized AA version
from the enquiry as a drill action designed as part of the Test Scenario. Html source for schema
download should be provided otherwise TestStudio downloads the standard product by default.
However, if there are more Test Scenarios using customized products than the standard one then the
best solution is to overwrite the variable(s) in the AA_PARAMETERS datapool by providing the
enquiry name pointing the customized product catalog. Then this will be the default product catalog
used within TestStudio. Test Scenarios using standard products will be accessed via the standard
enquiry as a drill action and same way as above the html source for schema download has to be given
by the user. In all cases, it is recommended to provide sample for CUSTOMER and CURRENCY
variables to avoid the possible case when the user taken by TestStudio to download the schema is
not suitable for the AA product, causing the schema retrieval to fail.
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.

Page 62 of 108
 Guide User Guide

7.5.1 AA datapools
TestStudio uses two helper datapools for storing the required data, “AA_PARAMETERS” and
“EXAMPLE_IDS”. These datapools are automatically created for each new TestStudio environment
project.
• AA_PARAMETERS – AA related customization can be setup in this datapool, like the name
of customized product catalog.
In case not the standard Product Catalog needs to be used and/or TestStudio 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 to help TestStudio. All changes done
on AA Parameters item of Preferences window are automatically written into AA_PARAMETERS
datapool. There are hints for each variable as well giving additional information about their usage.

53. 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 should be a valid currency for AA
transaction capture and any customer number, not compulsory to have any AA transaction for this
customer. TestStudio tries to find the values automatically, however if it fails then 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’s customized Product Catalog (see above). The exact technical names of Enquiries
should 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’s specific Product Line enquiry in case the column containing Product Line
doesn’t match with the defaulted value.

Page 63 of 108
 Guide User Guide

#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’s 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
AA.PRODUCT.CATALOG-PRODUCTS enquiry. Its default value is 2". It has to be defined for Bank’s
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. It is used for AA schema automatic download. In case TestStudio 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 TestStudio 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 TestStudio 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 64 of 108
 Guide User Guide

54. Figure: EXAMPLE_IDS datapool

7.5.2 AA tab on Resource Browser

AA tab shows all AA products used in the current selected TestStudio Design project, and after a
successful AA structure download it shows the content of the Product Catalog of the selected T24
environment. 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.
AA Products can be downloaded here clicking on the “Retrieve AA structure” item of the AA tab context
menu.

55. Figure: Retrieve AA structure

7.5.3 Automate AA New Arrangement

The process for implementing a new AA Arrangement or Activity is like how the versions are created,
nevertheless it consists extra steps. The process of creating a new T24 AA test case in TestStudio is
the following:

Page 65 of 108
 Guide User Guide

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). If the AA
structure has not been downloaded TestStudio will ask to download the AA structure.

56. Figure: Insert AA Test Case

2. Select first product line, then product group then the product. For all case TestStudio fills the
dropdown list with the proper values. TestStudio. For first interact with AA test case, TestStudio
will offer to learn AA structure, which is the content of the Product Catalog. This will fill up all
related attributes: mode, productLine, productGroup and product. To relearn the
TestStudiocontent, the config file has to be deleted from the design project’s .descriptors folder
called aaStructure.xml.

If no group and line values are provided, then AA Product can be directly set. Some products do
not have group and line parameters and using only product value is recommended for these cases.

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

Page 66 of 108
 Guide User Guide

3. Change the mode to “New Arrangement”, “Simulate” or any other available value from drop
down list. New Arrangement or Simulate modes are only required when the test scenario
doesn’t contain the “navigation” steps as test cases. In this case TestStudio will use the
“default” navigation through the AA Product Catalog, and in this process at some point there
is an ENQ popup menu action with those values. With the New Arrangement or Simulate
modes we instruct TestStudio which popup menu action should be selected in the default
navigation. Otherwise all cases when value is set on an AA field, and the navigation steps are
also part of the test design are ‘I’ mode.
4. Saving the Business Process triggers download the AA multi version schema from T24.
5. In some cases when TestStudio cannot automatically download the AA schema and design
error is displayed in the Resource Browser, example ID usage and/or the “Create descriptor
using html” context menu action is required. The steps of the two options are:
a. 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”. This
will show a popup window where you should paste a valid ID of an AA product that you
wish to design. Existing AA ID can be retrieved manually from T24 browser. Click on
the “Re–download design” from the context menu and wait for the schema download
action result.
b. For HTML source there is a need to open an AA transaction then choose View Page
Source item from right click menu on the AA screen in your browser, then select its
content and copy into Clipboard. Next, go to TestStudio, and in Resource Browser’s
AA tab, right click on the mode you need to download, and select the “Create descriptor
using html”. As result, the html file is saved into Design project’s “.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
TestStudio. Using HTML source is not affected by database restore case in the
meaning that schema download still succeeds after T24 database.

\
58. Figure Pasting html to create AA descriptor

In Test Scenario AA versions look different than standard Versions. Version editor is opened
separately for each sub-version, but only when the main version of the required sub-version is
selected. For all sub-version the corresponding schema 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.

Page 67 of 108
 Guide User Guide

59. Figure: Complexity of AA Test Case Design

In case of authorization is required, 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.
TestStudio 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 TestStudio would take in case there is no html source given.
TestStudio support multi subversions as well, however only the existing versions what means that
expand subversion is not yet supported.

7.5.4 HTML source or Example ID

In general, TestStudio version schema downloading process is the following:
1. If there is a downloaded HTML source of the version, then TestStudio tries to process it then
quits.
2. TestStudio tries to open the version in I mode using the New Deal option (F3).
3. If it fails, then tries to open an existing record in I mode, as in case of I mode are all fields
visible.
If the above automated schema download processes fail or provide an incorrect schema, then manual
support is required. Example ID can be provided which will be used as Transaction ID to be opened,
and TestStudio will get the schema of the screen which is opening as a result. Alternatively, after
manually opening the version, its HTML source can be added to TestStudio to use as base of the
schema. It is very important, that when the Example ID is provided, then the schema will be generated
whatever result the version open will have, and TestStudio will ignore the HTML example. If the
schema should be generated by a HTML source, then first any example ids must be removed.
The rule is similar in case of AA versions, but there are some differences:
1. If there is a downloaded HTML source of the version, then TestStudio tries to process it then
quits.
2. Using the %AA.ARRANGEMENT enquiry TestStudio gets a CUSTOMER ID and CURRENCY
for the AA.
3. TestStudio opens the AA using the AA.PRODUCT.CATALOG enquiry.
4. Using the CUSTOMER ID and the CURRENCY a validation will be performed to get the
subversions.

Page 68 of 108
 Guide User Guide

5. TestStudio creates a schema from this AA version.

6. TestStudio opens the AA.DETAILS.NEW.ACTIVITIES and uses ARRANGEMENT as a filter
to get the Activities list and fills the Activities folder in the RB.
In case of AA main product schema download, the Example ID and the HTML source can be used at
the same time, because they have different purpose. Downloading a main product schema (New
arrangement) contains two actions: download the product schema and download the possible activity
list. If any of these fails, the schema download process fails. Therefore, if the New Arrangement can’t
be open automatically, then a HTML source must be provided to it. Example Id is used to get possible
activities to complete the activity list.
Activity list is created based on a “live” existing arrangement, which means the arrangement status is
CURRENT by default. In case the live arrangement’s status is not CURRENT, but e.g. AUTH, then
an example id has to be provided. Based on that example TestStudio will open activity list. This means
that in this exception both example id and example HTML can be filled.
The case is different when downloading activity schema, as here again the default rule works: only
one should have value, otherwise example id will be used only. Example id provides and arrangement
from where the activity can be opened. It is possible however, that on the main version some data
must be filled before performing validate and open the full subversion screen. This event (fill more
fields on main version) is not supported by the automated schema download process, (except the
customer and currency for the main product version).

7.5.5 Expected value checking in AA

Expected value checking is done in the same way as in case of T24 versions. TestStudio checks the
fields’ expected values based on the verify attribute value in the meaning that if it has the default value
as true, then 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. (e.g. 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 checking them in different mode. (e.g. A, New Arrangement etc.)
If all modes result the same error than there is no option to check them with TestStudio.
TestStudio supports testing negative cases in AA main version. In this case TestStudio
validates and not commits the transaction. Expected result “fail” expects a failed validation
and not a commit failed message.

7.5.6 Multi SubVersion support

The “++” button on T24 browser allows the usage of multi-subversions. Multi-subversions are
recognized automatically in the schema, and you can add new items from the Test Case
Editor’s context menu.

Page 69 of 108
 Guide User Guide

1. Figure: Multi-subversion is indicated by the [1] after the SubVersion.

Page 70 of 108
 Guide User Guide

2. Figure: Multi-Subversion structure shows SubVersion in two levels

You can add additional subversion from the context menu of one of the existing subversions:

Page 71 of 108
 Guide User Guide

The SubVersion item has a “subVersionTitle” attribute, which can be edited in the XML Attribute view.
Here you can set the date which has to be provided while creating a new multi-subversion manually
in T24. You can use here both static and dynamic values, e.g. helpers.

You must make sure that the dates in the multi-subversion’s title must be in an ascending order!

Page 72 of 108
 Guide User Guide

When in your test design you add a multi-subversion, the “++” button will be automatically pressed by
TS, you don’t need to add anything else.

7.5.7 Using AA in See mode from T24 Command line

In TestStudio schemas for AA products in S mode are downloaded via the View Activity for
Arrangement activity, therefore the transaction id has to contain the value structure such as
Arrangement identification concatenated by -VIEW-ARRANGEMENT string. This is defined in
TestStudio 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.8 Automate AA Activities

All actions performed with an AA arrangement have to be done through activities. Downloading a
product in TestStudio 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” if the test scenario doesn’t contain
navigation steps, otherwise it is I, or any other mode.
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.

60. 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. TestStudio 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

Page 73 of 108
 Guide User Guide

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.

61. Figure: AA Activity example 1

62. Figure: AA Activity example 2

After getting the name of the activity, one of the activities from the activity list of the AA should be drag
and drop then replace the product name and the mode of the activity. The name should be the one
picked 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.

63. Figure: Manipulate AA Product

After performing the actions mentioned above and saving the Business Process, TestStudio 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 108
 Guide User Guide

64. Figure: Get AA Example form HTML

And pasting it to TestStudio by right clicking the added activity and selecting the “Create descriptor
using html” from the context menu.
Then TestStudio will generate the schema based on this example HTML source.
TestStudio 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.
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.9 Executing AA Test Scenarios

TestStudio 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.
TestStudio 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 should be checked in
order to find the root cause of the error.

Page 75 of 108
 Guide User Guide

7.5.10 Non-English language support

TestStudio supports AA schema download and execution with non-English T24 user as well in such
a way that TestStudio 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.
For further details in non-English language support please refer chapter 9.

7.5.11 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, then 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 should 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 TestStudio.ini file which is
stored in the TestStudio root folder.
In case the product needs 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 could 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 work properly.
Schema errors are displayed in the editor and 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.

There might be cases when the AA Subversion name is changed in T24 for a specific AA product. In
this case the schema(s) need to be re-downloaded and as its result TestStudio automatically
refactors the related Test Scenarios by keeping the original version fields of the Subversion but
moved to the end of the Subversion list and marked in red. The new Subversions will be shown
above this list.

Old Subversion content can be copied into the new Subversions inside the Test Scenario source
(open the xmlin file in text mode and copy-paste the required parts). The old Subversions can then
be removed from the Test Scenario by right clicking on each of them and selecting the delete action
or by a mass deletion from the Test Scenario source file.

Page 76 of 108
 Guide 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 like
iterating with local parameters, but this time the iteration will be executed only on one sequence of the
BP. For example, if many different accounts need 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 TestStudio
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 should contain those fields where
data changes in the iterations. Datapool must be a table or a Excel datapool, 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. TestStudio automatically goes through the datapool and executes the TC with each row.
NOTE: 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.

65. Figure: Datapool iteration – multiplicity setup in BP

Page 77 of 108
 Guide User Guide

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

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

Page 78 of 108
 Guide User Guide

68. Figure: Datapool iteration – result in the Xmlout

8.2 XPath
In case there are more than one Input Data for a TC, TestStudio helpers may have trouble to locate
a proper value. This case XPath expressions should be used to find a value. TestStudio allows to use
XPath 2.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 TestStudio 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 2.0 standard.

8.3 Multi phase, multi day scenarios

8.3.1 Phases
TestStudio’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 “Prepare”, “Test”, “Check”,
“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 changes 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 108
 Guide User Guide

69. Figure: Create new phase in BP

Phases used in BPs has to be listed in RUN_PARAMETERS datapool under the key #PHASES.
Phase names have to be listed here in the exact order they are coming during a Day of a BP.
TestStudio 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 TestStudio will replace the log section of the phase. It is important to fill
#PHASES, because TestStudio will find the location of the phase based on this list. In case of the
phase which is repeated is not in the list, TestStudio 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 TestStudio 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 TestStudio 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.
New day can be added like adding a phase. From context menu on a day item in BP select “Add Day
after” or “Add Day before”. Value is mandatory for day item. An empty phase is automatically created
for each new day.

Page 80 of 108
 Guide User Guide

8.4 Conditional execution control with enquiries

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

8.5 Conditional execution with logical expressions

Every phase and TC item in the Business Process has a “Condition” attribute, which tells TestStudio
if the actual item should or should not be executed. Its value is a logical value: true or false, by default
it is “true”. This logical value can be a result of a logical expression like =#PARAM('OPTION')='1'. In
this logical expression all TestStudio helpers and XPath functions can be used to calculate the result.
E.g. Condition: =#INPUT_PARAM('pack_Account_1','4','CURRENCY_3')=’EUR’. The result should
be 'true' to enable the specific item.
In the TestCase Editor this new attribute is also available for the Day, the Sequence and the
InputMessage (Input Data) element. The Day and the Sequence has also a "bpCondition" attribute
which is defaulted from the value set in the BusinessProcess and cannot be changed. If the "condition"
variable is empty, then the "bpCondition" will be evaluated. If it is not empty, then the "bpCondition" is
ignored and only the "condition" is evaluated. For InputMessage(Input Data) there is only "condition".
This can be useful when having multiple InputMessage for one Sequence, or it turns out during
execution which version should be used. This solution can also be used when the TSC preparatory
shall come from different sources, e.g. pick an existing record from the system, or create new test
data. This also can be “decided” with this condition attribute.

Page 81 of 108
 Guide User Guide

9. Non-English language support

Language support could work in multiple ways in T24. From these TestStudio supports two solutions.
Language support is critical for enquiries only, as in case of versions all fields are identified by their
technical name which is the same in any language.
Different language causes different design for enquiry result column headers (names) and popup
menu action texts. These texts must be the same in the TSC design and in the execution. This means
that if a Spanish language user is executing the test then all enquiry related labels (texts, names) must
be in Spanish also in the design.
Recognized language alternatives appear in the editor as additional column name or popup menu
action, and in the design the proper one has to be selected.

9.1 Language support with ENQUIRY table

First option of language support is when the different language alternatives are stored in the ENQUIRY
or ENQUIRY.DETAILS tables. In this case names are stored as a multivalue field value, and
TestStudio can capture them automatically, no additional action is required.

9.2 EB.DICTIONARY
The other type of language support is when T24 uses a dictionary for translation. In this case first the
dictionary has to be downloaded.
To download the dictionary file the INFO user must have the non-English language selected. Then
from the Environment project’s context menu select “Dictionary Download” option, and TestStudio will
download the dictionary file for the corresponding language. Result is a dict.xml file in the design
project’s root folder.
After the dictionary file is downloaded, a relearn has to be executed with the non-English language
INFO user. During this process TestStudio will automatically search the translation in the downloaded
dictionary for all required texts and add the translations as additional selection options.

9.3 General cases – TXN Complete and TXN Verified

Expected Transaction complete and transaction verified messages can be defined in any language 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, or directly in the
RUN_PARAMETERS datapool.

Page 82 of 108
 Guide User Guide

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

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
TestStudio can access T24 environment directly, no server side “agent” is required for connection.

Page 83 of 108
 Guide User Guide

Agent is a process running on the environment server which opens a port for TestStudio to access
the environment. This application is part of TestStudio and has to be copied to server if needed. For
detailed information contact Atoma.
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
• Day and phase iterator

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

Page 84 of 108
 Guide User Guide

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.
The element "Day and phase iterator" iterates through day and phases automatically and can
distribute the content between multiple virtual users defined in the Usergroup item.
It is important to set up phases in the right order in the RUN_PARAMETERS datapool. In case any
script is needed (COB/backup/restore) or a specific action (eg. start/stop services) is to be used as
part of the Suite, these must be designed under a specific phase as part of a Test Scenario. It is
possible to use suites/subsuites under the Day and Phase iterator, but only "container type" suites
should be called. Such suites should contain only ONE user group and only Business Processes or
xmlin’s (the CloseSession script must be removed from the container suite).
Suite can execute another suite in sequential way, but not in parallel mode. It is good for organizing
purposes, grouping together TSCs which are connected to the same product or specification
document. 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 enabled or disabled. It is easier to disable items for some executions than remove them,
because they are usually not put back to the suite later and will be skipped “forever”.

Page 85 of 108
 Guide User Guide

72. 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 TSCs 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 86 of 108
 Guide User Guide

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

10.3 Designing TestStudio suite for parallel execution

TestStudio has the capability of executing multiple test scenarios at the same time. This dramatically
reduces the time needed for large suite executions.
The key in both ways is to increase the number of java virtual users which practically means the
parallel threads of the execution. This can be achieved primarily by increase the main suite user
number on the top of the execution suite. By default, this number is 1. This number is used as a base
number of parallel java virtual users. Every usergroup defined in the execution suite can use maximum
this number of java virtual users.
On the usergroup level the number of virtual users can be set as a fixed number or as a percentage.
The percentage always calculated based on the main number of users set at the top of the execution
suite. The greater number of virtual users assigned to a usergroup the more parallel threads are
started to be executing. These parallel threads are all executing the same usergroup content, but if
the test scenarios have been linked to the execution suite by their business process then the business
process automatically distributes the scenarios among the parallel threads. Business processes are
also acting as synchronization points among the different threads which means that even there are
no more executable test scenario for a thread it will wait all others to finish before moving on to the
next item in the usergroup. For example, if there are three test scenarios under one business process
in the usergroup and two virtual users assigned to it then when execution started then two parallel
threads start running, first takes the first scenario while second takes the second. The one finishes
faster will take the third one to finish the execution.
Parallel threads are connecting to the T24 environment at the same time. This means that they will
require as many different T24 users as many threads are running parallel because T24 doesn’t allow
multiple parallel login for the same user. In TestStudio in test scenarios there are user roles (nick
names) linking the actual T24 users to the test cases. For parallel execution there must be as many
entries in the Globus users table for every user role as many parallel threads are planned to run. For
example, if there are three java virtual users assigned for a usergroup then there must be three

Page 87 of 108
 Guide User Guide

DEFAULT_INPUT_USER each with different T24 user and three DEFAULT_AUTH_USER as well.
Every thread will pick one unused user from the table guaranteeing no user conflict during execution.
The element "Day and phase iterator" can be used to iterate through day and phases automatically
and it can distribute the content between multiple virtual users defined in the Usergroup item. Only
"container type" suites can be called under the Day and Phase iterator (suites that contain only ONE
user group and only Business Processes or xmlin’s). The main suite can contain more than one
UserGroup, but only one of the UserGroups can contain a Day and Phase iterator.
The method used until now for parallel execution using UserGroups is still supported. However, in the
case where suites and/or subsuites are part of UserGroups, they will be executed sequentially and
not in parallel within a UserGroup created with more than one user. Therefore, we recommend that
changes are made to the current suite by the creation of Scenario elements, including Bps and Test
scenarios, and then use these under the UserGroups items. This will ensure that the content is
executed in parallel.
Making parallel execution for single-day scenarios is easy. Just the number of users assigned to the
default usergroup should be increased and make sure all test scenarios to be executed are linked to
the suite by their business process. During execution business processes distributing test scenarios
among threads, and they also synchronizing them automatically. Therefore, phase changes will have
effect in all threads at the same time, no further synchronization is required.

10.3.1 Multiple User Groups

Multi day scenarios can be also executed in a parallel way however in this case there must be multiple
usergroups introduced in the execution suite. In this case a specific scope of test scenarios has to be
defined for all usergroups. It is still possible to assign multiple virtual users for every usergroups to
increase the number of parallel threads processing each usergroup’s content. In case of multiple
usergroups phases and days should be controlled by only one usergroup because these values are
global values. All other usergroups should be synchronized for that by using synchronization points
before and after the phase and day changes.

74. Figure: A Main suite set up for parallel execution

You can create a Usergroup by right-clicking on the suite top level, New, UserGroup.
UserGroup attributes:

Page 88 of 108
 Guide User Guide

• Name: UserGroup name

• Type: The type of the number field, either fixed (integer) or percent.
• Number: If type is fixed, the number is a integer and corresponds to the number of users(threads)
to be used. If type is percent, number is the percentage of the users defined in the main test suite
block. In the above screen is 2 user(s), and each UserGroup uses one user(thread) (50%).
The general execution time is decreased according to the number of UserGroups used. I.e. decreased
by 50% if two UserGroups are used.

10.3.2 Multiple T24 users

Each UserGroup uses a different set of users. This means that additional T24 users need to be
created, using the same nickname. I.e. the following image shows that the Nickname
DEFAULT_INPUT_USER has two entries but different Globus/T24 users
(TESTUSER14/TESTUSER15).

75. Figure: Multiple T24 users

10.3.3 Synchronization Points

One important configuration when using parallel execution, it's the use of synchronization points. They
guarantee that the execution on the UserGroups can start and end at the same time at these points.
Their use is crucial when there are multiple phases on a Test Scenario. Phase and Day value are
global within the test suite's Java process - if one UserGroup changes the Phase value then the other
UserGroups will get the new value on next reading.
Let's assume that you have the following 3 Phases in your test suite: 'First', 'Second', 'Third'. You need
at least 5 SynchronizationPoints in your concurrent UserGroups:

// beginning of UserGroup Scenario block

setPhase(First)
- SynchronizationPoint FirstStarted
... bps and scenarios...
- SynchronizationPoint FirstFinished
setPhase(Second)
- SynchronizationPoint SecondStarted
... bps and scenarios...

Page 89 of 108
 Guide User Guide

- SynchronizationPointSecondFinished
setPhase(Third)
- SynchronizationPoint ThirdStarted
.... bps and scenarios...
// end of UserGroup's Scenario block.

Page 90 of 108
 Guide User Guide

76. Figure: Synchronization points in a Suite

Page 91 of 108
 Guide User Guide

On the image above the Synchronization point 'Close' guarantees that each UserGroup execution will
reach this point at the same time and then continue to the next one, in that case the script for close
the session on UserGroup1.
SynchronizationPoints must be defined at the bottom of the test suite in block "SynchronizationPoints"
before you can use them.

77. Figure: Adding a Synchronization point

Each Synchronization point has one attribute name. This name must be unique within the test suite
and must follow these rules:
• name must start with letter (of the English alphabet),
• it may not contain space or any special characters just alphanumeric characters and
underscore character ( _ ).

10.4 Monitoring the TestStudio execution

During the suite execution, it's possible to see the UserGroups running concurrently

78. Figure: Parallel execution of UserGroups

UserGroup2 already reached a synchronization point and is waiting for UserGroup1 concludes its task
and reach the same point.

10.5 Execution from command line

Execution of suite from command line without opening the TestStudio graphical interface is also
supported. The application will start in the background, execute the given suite from the specified
design project and stop when finished.
Command line arguments for headless run looks as follow:
TestStudio.exe -nogui -dp <name of design project> -ep <name of the environment
project> -url <url to access t24 browser interface> -suite <project relative path
to the suite with extention>
Example: TestStudio.exe -nogui -dp DemoDesignProject -suite suites/suite.ptxml

Page 92 of 108
 Guide User Guide

10.6 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 93 of 108
 Guide User Guide

11. Reporting
11.1 Reports from database (BIRT)
The source of reports is the design model of TestStudio. For this kind of reporting TestStudio has a
built-in BIRT reporting tool which has several pre-defined reports to help following the design status
of the project.

79. Figure: Reports

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.
• Execution status report contains information about how many Test Cases of the Test Scenario
have been executed and with an execution statistic of error/warning numbers. The report is
able to reflect the files structure under the “Test scenarios” tab and including the whole “Test
scenarios” content as well as separately for a subset of folders or for each folder. In order to
see exact T24 error messages in the report you need to re-execute Test Scenarios then
generate Execution status report.
There are two options on report details, Test Scenario and Test Case levels. In case of
erroneous Test Scenario/Test Case there are links to see the exact T24 look&feel snapshots
located at the end of the report in a separate section. Back hyperlink helps us to jump back to
the original Test Scenario/Test Case.
• 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.
TestStudio saves the reports as PDF into the design project’s generated reports folder and it tries to
open them with a system viewer.

Bank logos could be added into the generated reports.

The default empty icon needs to be replaced by the Bank specific logo under the icons folder of birt
plugin accessed from TestStudio root folder

Page 94 of 108
 Guide User Guide

(eg. d:\TS_3.0\plugins\com.fotgroup.birt.connector_2.2.8553\icons\

Page 95 of 108
 Guide User Guide

12. Interfaces
12.1 Interface design
TestStudio 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 TestStudio 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 multi-value) can be added in the TSC Editor area. At
this point, only the existence of a field is important, because TestStudio automatically orders them.
Main rule is that first single value fields are coming, then the multi-value fields. Mixing them is not
possible.
In case of an Input interface the “connection” attribute, while in case of Output interface the “datapool”
attribute has to be set.

12.2 Interface connections in Interface Engine

Second part of interface development is the connection definition. TestStudio has a built-in tool called
Interface Engine, which gives a straightforward 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 some datapools, from which at this point the IN_CONFIG_DP and the
OUT_CONFIG_DP should be mentioned. All connections should 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 should be transported to T24 or where to
check it.
• Converter Description: contains which fields and in which order should 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.
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 should be started before any other execution starts,
then in the end it should be manually stopped with executing a “Terminator” suite.

Page 96 of 108
 Guide User Guide

Interface Engine can be replaced with java programs, where connection and converter rules should
be programmed. This is an advanced way to operate interfaces and requires expert programming
skills.

Page 97 of 108
 Guide User Guide

13. Regression testing

13.1 Baseline run, Control run – general methodology
Regression testing type is supported by TestStudio. The aim 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 TestStudio
will know from this that which results has to be compared.
Results of compare are the differences. These differences have to be analysed and organized into
defects.
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.

Page 98 of 108
 Guide User Guide

Differences are not necessarily mean problem. Many differences happen because executions were
performed in 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.

13.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 setting a new environment, TestStudio 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. It is possible to perform the Relearn action only in designs that are used in test
cases by checking the ‘Do you want to limit the re-download to the used design elements only?’ option
in the Relearn popup window, or to just those schemas which have been successfully downloaded
earlier by unchecking the ‘Do you want to re-download the designs which failed last time?’.

80. Figure: Relearn settings

In the environment project’s T24 login properties page, you can set how many parallel threads should
be used when schema download is on the way. It can be set in the INFO user’s box by changing the
default “4” of the “Max parallel sessions during relearn” field.
If there are conflicts in the already implemented test scenarios, TestStudio shows the location of these
differences. 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.
If the changed items are not used in any test scenarios, then no error will occur, but TestStudio 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 selecting the ’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 108
 Guide User Guide

81. Replace baseline with current execution result

13.3 Compare view

Compare should 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 the 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 should
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 TestStudio 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.
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).

Page 100 of 108

 Guide User Guide

13.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 currently 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 attached 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.

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

13.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 TestStudio 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 TestStudio is dedicated as master, and for all other TestStudio instances
this dedicated TestStudio’s location should be set in TestStudio.ini. The key to be used is: “-
DTM.defect.host” where the master TestStudio’s IP has to be put. In case of changing this value, a
TestStudio restart should 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.

13.7 Error reporting

TestStudio supports bug report creation which 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 TestStudio helps collecting
all relevant data for the issue, then compressing the files and attaches it to the issue it creates.
In case of TestStudio related issues use the black bug button to export all the relevant information into
a zip file.

Page 101 of 108

 Guide User Guide

82. 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 are part of the selected Design and
Environment project. The archive will contain hidden files because TestStudio uses some of them for
its operation.

Page 102 of 108

 Guide User Guide

14. What is new in TestStudio 3.0

14.1 Taris Repository Integration
TestAssistant scenarios can be imported into TestStudio from the Taris Repository.

14.1.1 TestStudio Setup for TestStudio Integration

The taris.properties file has to be updated with the proper TARIS URLs before starting TestStudio.
Setting can be found in Chapter 2.1.4.

14.1.2 TestScenario Import Process from Taris Repository

The process could be initiated in TestStudio by using the context menu “Import” in Resource Browser’s
Test Scenarios tab. There are three options here:
1. Import / Test Scenario from file: the integration “script” can be manually loaded into TestStudio
as a file
2. Import / Test Scenario(s) from Taris Repository: automatically offers all scenarios recorded by
TestAssistant
3. Import / Test Scenario(s) from Taris Repository by Test Cycle: this menu item imports recorded
test scenarios grouped by test cycles.

83. Bug report Zip creation

In case of options 2 and 3 multiple number of test scenarios can be selected by using the CTRL and
SHIFT keys with the mouse click.
The folder structure and the names of the imported scenarios will be synchronised from Taris
Repository.
After successful import, some values have to be changed manually from static to dynamic, such as
transaction ids, and other field references with the use of the TestStudio helpers. All other values will
be set automatically.
For successful import the following needs to be make sure:
1. In TA there shall be no grammar errors in the recorded scenarios. Test blocks with grammar
errors are skipped from integration script.

Page 103 of 108

 Guide User Guide

2. In TA all used COS and TAB names must be provided by the user. Unfortunately, T24 doesn’t
send in the browser level the name of the COS and TAB in use, therefore it must be set by the
user. TA offers a specific layer for this. For further information please refer to TA user guide.
3. In TestStudio learning AA structure is required if there are any AA used in the imported
scenarios.

14.1.3 TestScenario Import TestScenarios with Prerequisites

TestAssistant offers the possibility to link different scenarios as each other’s prerequisite. This way
the user doesn’t need to capture customer creation for every scenario, just set it as prerequisite after
the first recording.
When a test scenario is imported into TestStudio which has prerequisite, TestStudio will create
packages for every prerequisite scenario. These packages should be changed similar than the main
scenarios for the first time to be ready for dynamic execution.
When a scenario is set as prerequisite for multiple other scenarios, TestStudio will create only one
package the first time, then for every following occurrences it links the first package.

14.2 Automatic package generation

TestStudio offers the possibility to generate package of any part of an existing Xmlin. This feature can
be used from the context menu of the top level of any TC with Input data. The TC clicked first will be
the first TC in the package, and it can be defined how many following TCs should be part of the
package. Package type TCs are excluded, as TestStudio doesn’t support package in a package.
The created package will contain all selected TCs with the actual input data. The generation makes
input parameters for all input values on version, AA and ENQ.
Any possible output param must be defined and set manually.

Page 104 of 108

 Guide User Guide

Terminology
automated Test execution cycles while all defects are corrected inside one phase of project.
regression 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 step 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.

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

Page 105 of 108

 Guide User Guide

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,
TestStudio 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 datapools
project 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 functions,
testing 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.

interface A boundary across which two independent systems meet and act on or
communicate with each other.

Page 106 of 108

 Guide User Guide

Interface
Engine Globus/T24 Server
TestManager

T24
DeskTo
InterfaceEngine 3rd partysystem
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 TestStudio 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)

regression Regression testing helps to find out whether or not certain changes in the system
testing 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.

Page 107 of 108

 Guide User Guide

regular Regular expressions provide a concise and flexible means for identifying strings of
expressions 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 TestStudio, 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 output
is TSC) data of the function and the required, expected functioning during the testing.

test The test specification describes Test Scenarios in detail, 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

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