Page|1

Process Design Document

Process Definition Document - PDD

IC Banking Regression Testing
Republic Bank Ltd.
Prepared by:

Juan Camilo Hernández – RPA Tech Lead

Globaltek Security S.A.S.

Page|2
 Process Design Document

TABLE OF CONTENTS

1. Document Control...............................................................................................................2

1.1 Version Control..........................................................................................................2

1.2 Document Review and Sign-Off.................................................................................2

2. General Process Description................................................................................................3

2.1 Process Summary.......................................................................................................3

2.2 Data Flow & Applications..........................................................................................3

2.2.1 Applications Interacted With..............................................................................3

2.3 Process Flow – AS-IS.................................................................................................4

2.4 Process Flow – TO-BE...............................................................................................4

3. Step-by-step Process Documentation..................................................................................5

3.1 Login to IC Banking Portal.........................................................................................5

3.2 Execution of the Test Cases........................................................................................8

3.2.1 Execution in General........................................................................................10

3.2.2 Additional Considerations for RET_N...............................................................1

3.3 Logout of IC Banking Portal.......................................................................................2

3.4 Results Verification....................................................................................................3

4. Exceptions...........................................................................................................................3

4.1 Known Exceptions......................................................................................................3

4.2 UnKnown Exceptions.................................................................................................4

5. Variables & Reports............................................................................................................4

6. Additional Details................................................................................................................5

7. Additional Process Considerations......................................................................................5

8. Appendix.............................................................................................................................6

8.1 Glossary......................................................................................................................6

Page|3
 Process Design Document

1. DOCUMENT CONTROL

1.1 VERSION CONTROL

Version Date Description Author

Juan Camilo
1.0 dd-mm-aaaa PDD first release version.
Hernández

1.2 DOCUMENT REVIEW AND SIGN-OFF

Name Business Role Action Date Reviewed

Manager Technology Deployment
Rehan Mohammed
ITM Division
Nazma Mohamed QA Department Supervisor

Page|4
 Process Design Document

2. GENERAL PROCESS DESCRIPTION

2.1 PROCESS SUMMARY

Ejecución de pruebas de regresión sobre la plataforma IC Banking web, para verificar

que ciertas funcionalidades continúan operando correctamente luego de cualquier
cambio en la plataforma. El equipo de aseguramiento de calidad del Banco ha
definido 33 casos de prueba, cuya ejecución garantiza el correcto funcionamiento de
algunas configuraciones específicas de seguridad de los clientes del banco, así como
también permiten validar ciertas transacciones entre los productos financieros y el
pago de servicios del cliente.

2.2 DATA FLOW & APPLICATIONS

2.2.1 APPLICATIONS INTERACTED WITH

Application Interface General Purpose Comment
IC Banking Web Banking Transactions web portal for .NET technology
Browser – the execution of the regression test
Google cases.
Chrome
Excel Microsoft Data source where the data required Microsoft 365 MSO
Windows for the execution of the test cases is (16.0.14026.20294)
Server taken from. 64-bit
2016
Outlook Microsoft Email application through which the
Windows process notifications and final cases
Server report are sent.
2016

En adelante en este documento usaremos los siguientes términos "AS-IS" y "TO-BE"

para denotar :

AS-IS : Los pasos o actividades que se realizan en el proceso manual actual.

TO-BE : Los pasos, actividades o consideraciones para la ejecución del (los)
bot(s) dentro del proceso automatizado.

También usaremos los siguientes términos para referirnos a los archivos utilizados en
el proceso y que se encuentran como anexos al actual documento:

Excel of Test Cases: “US - IC Retail - Repetitive Test Cases - NEW.xlsx” Archivo
Excel,
donde se encuentra descrito, el paso a paso para la
ejecución

Page|5
 Process Design Document

de todos los casos de prueba.

Data Source : “Data Source 290721.xlsx” Archivo Excel, que contiene los
datos de insumo que se requieren para la ejecución de
todos
los casos de prueba.

2.3 PROCESS FLOW – AS-IS

Insert high level diagram as – is.

2.4 PROCESS FLOW – TO-BE

Insert high level diagram to – be.

Page|6
 Process Design Document

3. STEP-BY-STEP PROCESS DOCUMENTATION

1.1 LOGIN TO IC BANKING PORTAL.

Step 1: El analista de QA ingresa al portal de IC Banking web a través de Google

Chrome y utilizando la URL https://icbuat.rfhl.com.

Step 2: Ingresa usuario en el campo de texto.

Step 3: Hace click en botón “Next”.

Page|7
 Process Design Document

Step 4: Ingresa la contraseña en el campo indicado.

TO-BE: para el proceso automatizado, la acción de verificación visual de seguridad

no se realiza, pues la imagen nunca cambia durante la ejecución de los casos.

Step 5: Hace click en el botón “Next”.

Step 6: Ingresa el código SMS en el campo indicado.

TO-BE: el proceso automático asume que la validación del código SMS está
desactivada. En este paso se ingresará en el campo el valor definido en el archivo
“Data Source”. El campo es un valor numérico entre 1 y 6 dígitos.

Step 7: Hace clic en el botón “Confirm”.

Page|8
 Process Design Document

Step 8: Aproximadamente un segundo después, en la misma ventana del navegador;

se muestra el “Dashboard” o página principal de la aplicación IC Banking web.

Page|9
 Process Design Document

1.2 EXECUTION OF THE TEST CASES

Para el propósito de este documento y dado que todos los casos de regresión
llevados a cabo por parte del equipo de QA presentan multiples similitudes, en la
sección 3.2.1 se describirán los aspectos generales en común y que representan la
totalidad de los casos. En las secciones inmediatamente siguientes se describirán los
aspectos específicos o particularidades al ejecutar ciertos casos atipicos.

Los 33 casos de prueba llevados a cabo por el equipo de QA se describen a

continuación:

Test Case ID Test Case Description Objective

Transfer between Your
To ensure a customer can successfully transfer
RET_1 Own Accounts TTD to
same currency funds Between Own Accounts
TTD
Transfer between Your To ensure a customer can successfully transfer funds
RET_2 Own Accounts USD to Between Own Accounts from a foreign currency
TTD account to a TTD account.
To ensure a customer can successfully transfer
Transfer between Your
funds Between Own Accounts from a foreign
RET_3 Own Accounts USD to
currency USD account to a same currency USD
USD
account.
To ensure a customer can successfully transfer funds
Transfer between Your
RET_4 Between Own Accounts from a credit card to a TTD
Own Accounts CC to TTD
account.
Transfer to Third Party To ensure a customer can successfully transfer funds
RET_5 Republic Bank Account from their own account to another person's account
TTD>TTD in Republic Bank.
Transfer to Third Party To ensure a customer can successfully transfer funds
RET_6 Republic Bank Account from their own USD account to another person's
USD>TTD TTD account in Republic Bank.
Transfer to Third Party To ensure a customer can successfully transfer funds
RET_7 Republic Bank Account from their USD account to another person's USD
USD to USD account in Republic Bank.
Transfer to Third Party To ensure a customer can successfully transfer funds
RET_8 Republic Bank Account from their own Credit Card account to another
CC>TTD person's TTD account in Republic Bank.
Transfer to Third Party To ensure a customer can successfully transfer funds
RET_9
Local Bank from their own account to a Local Bank
Transfer to International
To ensure a customer can successfully transfer funds
RET_10 Bank Account (From TT
from their own account to an International Bank
Account)
Transfer to International
To ensure a customer can successfully transfer funds
RET_11 Bank Account (From
from their own account to an International Bank
USD Account)
To ensure a customer can successfully transfer more
RET_12 Multiple Transfer
than one transfer at the same time
To ensure a customer can successfully transfer
RET_13 Cardless Cash
cardless cash
RET_14 Credit Card Payment To ensure the customer can pay the TT and US side

Page|10
 Process Design Document
TT>TT and TT>US of a credit card from a TTD account
Credit Card Payment To ensure the customer can pay the TT and US side
RET_15
US>TT and US>US of a credit card from a USD account
Credit Card Payment To ensure the customer can pay the TT and US side
RET_16
CC>TT and CC>US of a credit card from a credit card
Payment to Republic
To ensure the customer can pay the TT and US side
RET_17 Bank Credit Card TT>TT
of a third party Republic Bank from a TT account
and TT>US
Payment to Your Loan To ensure the customer can make a payment to their
RET_18
(installment Only) loan
Payment to Your Loan To ensure the customer can make a principal
RET_19
(Principal Only) payment to their loan
Utility Payment from TT To ensure a customer can make a utility payment
RET_20
Account debiting a TTD account
Utility Payment from US To ensure a customer can make a utility payment
RET_21
Account debiting a USD account
Utility Payment from a To ensure a customer can make a utility payment
RET_22
Credit Card Payment using a credit card
Schedule a New Transfer
To ensure a customer can successfully schedule a
RET_23 Bewteen Your Own
transfer funds Between Own Accounts
Accounts
To ensure the customer can schedule a payment to
Schedule a Payment to
RET_24 the TT and US side of a credit card from a TTD
Your Credit Card
account
Schedule a payment to To ensure the customer can make a payment to their
RET_25
loan loan
Schedule a New Utility To ensure a customer can make a utility payment
RET_26
Payment debiting a TTD account
Add a New Payee- Thrid
To ensure a customer can successfully add a
RET_27 Party Republic Bank
Republic Bank Account as a Third Party Beneficiary
Chequing Account
Add a New Cardless Cash To ensure a customer can successfully add a new
RET_28
Payee cardless cash payee
Pre Register a New To ensure a customer can successfully register a
RET_29
Utility new utility payee
Load Own VTM from a To ensure a customer can successfully load VTM
RET_30
TT account Card from a TT account
Load Own VTM from a To ensure a customer can successfully load VTM
RET_31
US account Card from a US account
Change the Secret To ensure a customer can successfully change their
RET_32
Question and Answer secret question.
To ensure a customer can successfully change their
RET_33 Change Password
password

3.1.1 EXECUTION IN GENERAL

Para la ejecución de todos los casos de prueba, se cumplen las siguientes reglas:

Page|11
 Process Design Document

A. Los casos de prueba se llevan a cabo cuando el equipo de QA lo requiere, no

existen hora de inicio, disparadores, ni fechas como criterios de ejecución.

B. Tres personas (un supervisor y dos analistas) se dividen la ejecución de los

casos de prueba utilizando 3 diferentes usuarios con el mismo perfil.

TO-BE: en el proceso automatizado se utilizará un unico usuario para ejecutar

todos los casos de prueba.

C. El orden de ejecución de los casos de prueba es indiferente.

TO-BE: en el proceso automatizado, todos los casos de prueba serán

ejecutados desde RET_1 al RET_33 de manera secuencial.

D. Antes de ejecutar el set total de casos de prueba, se acondicionan los datos,

cuentas, saldos y estados para que puedan efectuarse normalmente una sola
vez. Si los casos de prueba deben ejecutarse varias veces y existe alguna
restricción, los datos deben ser reacondicionados en la aplicación para poder
volver a ejecutarlos normalmente.

E. Luego de ejecutar cada caso de prueba y evaluar el citerio de exito establecido

en el archivo “Excel of Test Cases”, solo es possible un resultado “Passed” or
“Failed” resultado final de un caso de prueba para el log solo puede ser Passed
o Failed.

F. El analista informa el incidente y si es possible reintenta el mismo caso o

continua innediatamenbte con la ejecución del siguiente.

TO-BE: en el proceso automatizado, si ocurre un error desconocido (no

conocido por el cliente o previsto por los diseñadores), se detendrá la
ejecución para evitar comportamientos inesperados, como se especifica en la
sección 4.2 del presente documento.

G. Por cada ejecución del test y para cada paso, existen un resultado obtenido y
un resultado esperado, estos son revisados por el analista de QA.

Page|12
 Process Design Document

TO-BE: en el proceso automatizado, no se evalúa el estado actual contra el

esperado para cada paso, solo se evalúa el mensaje resultante al completar el
caso.

Ejemplo: Para el caso RET_23, el resultado del test se considerará “Passed” si

se obtiene el mensaje "Your transfer has been successfully scheduled"

A continuación se describen los pasos típicos de ejecución de todos los casos de

prueba:

Step 9: El analista de QA navega través del menú principal del IC Banking hacia la
pantalla donde ejecuta los pasos propios del caso de regresión. Lo realiza
utilizando la función y sub-función correspondientes, tal y como se especifica en
los pasos de cada hoja RET_N en el archivo “Excel of Test Cases”:

Test Step No. 5: Click on the Menu Icon on the top left hand of the home page.

Test Step No. 6: Select Function from the menu options.

Test Step No. 7: Select SubFunction from the menu options.

Ejemplo: (Function: “Manage”, Sub-Function: “Third-Party Beneficiaries”)

Nota: Alternativamente, existe un menú de navegación el cual siempre es accesible.

Contiene todas las funciones y sub funciones necesarias para llevar a cabo los casos
de prueba. Adicionalmente cuenta con la Función “Settings” útil en casos específicos
como RET_30 y RET_31.

Page|13
 Process Design Document

Ejemplo: Function: “Settings”, Sub-Function: “Change Password”.

Step 10: El analista de QA procede con la ejecución del paso a paso del caso, tal
como se especifica en la correspondiente hoja RET_N del caso en el archivo “Excel
of Test Cases” a partir del “Test Step No. 8”.

TO-BE: Los datos que se requieren para efectuar el caso de prueba, provienen del
archivo “Data Source”. Por cada caso de prueba existe una hoja RET_N
correspondiente con la información distribuida de forma tabular. Los
encabezados refieren a los campos a diligenciar o a acciones a realizar en
pantalla; también se incluyen la URL de acceso al portal y las credenciales de
usuario. Se asume que los datos proporcionados son apropiados y suficientes
para ejecutar el caso normalmente, por lo cual no se deben efectuar validaciones
adicionales sobre los mismos.

A continuación una imagen del “Data Source”:

Page|14
 Process Design Document

Step 11: Para cada caso de prueba RET_N, hacia el final del paso a paso, existe
una acción de confirmación o de guardado de los cambios efectuados. El analista
hace click en el botón “Confirm” o “Save” según sea el caso.

Nota: Puede presentarse una ventana de carga de aproximadamente 2 segundos al

realizar la confirmación o guardado.

Step 12: El analista de QA evalúa los resultados del caso de prueba RET_N en
pantalla y determina mediante la información visualizada, si el mismo es Exitoso o
Fallido.

Ejemplo de un paso de confirmación típico:

Page|15
 Process Design Document

TO-BE: Para cada caso de prueba RET_N, se encuentra consignado en el archivo

“Excel of Test Cases”, en la correspondiente hoja y en el paso de confirmación, el
mensaje o condición específico que se debe validar para establecer si el caso es
exitoso o fallido.

Step 13: Para cada caso de prueba RET_N el analista de QA registra el resutado
obtenido en un índice o libro Excel compartido entre los miembros del equipo de
QA. En este libro se consolidan los resultados de todos los casos de prueba.

Nota: Si el caso RET_N resulta fallido, el analista de QA crea un log y eleva el caso
al departamento correspondiente mediante una aplicación de tracking.

Page|16
 Process Design Document

TO-BE: La acción de registro de novedades en la aplicación de tracking se

encuentra fuera del alcance del proceso automatizado. Se creará un log con el
resultado de la ejecución de cada caso de prueba en formato CSV, el cual al final
de la ejecución de la automatización se guardará localmente y se enviará copia al
supervisor de QA vía email.

Step 14: El analista de QA hace clic en la acción o en el icono “Home” para

regresar al “Dashboard” de IC Banking.

3.1.2 ADDITIONAL CONSIDERATIONS FOR RET_N

Add additional considerations for RET_N …

Page|17
 Process Design Document

3.2 LOGOUT OF IC BANKING PORTAL

Una vez el analista de QA ha terminado de realizar todos los casos de prueba

asignados, procede a salir de la aplicación ejecutando los siguientes pasos.

Step 15: Hace Click en la acción “Logout”. Esta acción siempre se encuentra visible en
la barra de título de la aplicación.

Step 16: En la ventana emergente “Log Off”. Hace Click en el botón “Confirm”.

La aplicación regresa automáticamente a la página de Login.

Page|18
 Process Design Document

3.3 RESULTS VERIFICATION

Step 17: Terminada la ejecución de la totalidad de los casos de prueba por los
analistas de QA, el supervisor del área realiza una validación manual externa para
verificar los balances para los productos utilizados.

TO-BE: El proceso automático asumirá que este paso de verificación manual y

externo de información, continuará realizándose de la forma actual; es decir, este
paso se encuentra fuera del alcance de la automatización.

4. EXCEPTIONS

Page|19
 Process Design Document

1.3 KNOWN EXCEPTIONS

1. “Pink error”, como es identificado por el equipo de QA, es una excepción que
sucede durante la ejecución de los casos de prueba esporádicamente. La causa
de falla puede ser debido a un problema de conexión a la red u otro.

Para retomar la operación, el analista de QA hace click en el botón “Back” y

vuelve a intentar ejecutar el caso de prueba.

El dato de ID es de utilidad para que el equipo de IT pueda consultar los

detalles de la causa del error.

TO-BE: Cuando este error ocurra, se obtendrá el ID y se colocara en el Log de

eventos, como también el resultado de la ejecución del caso de prueba
(Failed). Se realizarán un máximo de 3 intentos de ejecución del caso antes de
detener el proceso automatizado.

2. Si se omite el valor de algún campo del formulario durante la ejecución de

algún caso de prueba, no es posible continuar con su ejecución y se mostrará
un error que impide continuar.

Page|20
 Process Design Document

TO-BE: Previo a la ejecución de un caso de prueba, se verificará si falta algún

dato necesario en el “Data Source” de alguno de los campos. Si este es el caso,
se escribirá esta causa en el log de eventos, se marcará el caso de prueba
como fallido en el log CSV de resultados y se procederá con la ejecución del
siguiente caso.

3. Si al ejecutar cualquier caso de prueba falta alguna función o campo de

formulario, el analista de QA escala el caso al departamento técnico interno o
al proveedor de la plataforma (IC Banking).

TO-BE: Este error muy rara vez se presenta y existen muchas posibilidades que
pueden generarlo, por lo cual se manejará como un error desconocido de
acuerdo a la metodología que se describe a continuación.

1.4 UNKNOWN EXCEPTIONS

Al presentarse un error desconocido, de acuerdo a la metodología de manejo de

errores propuesta:

1. Se registrará en el Log de eventos del robot la línea y causa del error

identificados por la plataforma A360.

2. Se tomará una captura de pantalla del escenario en el cual se generó el error

desconocido.

Page|21
 Process Design Document

3. Se notificará al usuario encargado via email el error adjuntando la captura del

paso 2.

4. Se tomarán acciones en el equipo runner para eliminar archivos temporales,

incompletos y cerrar aplicaciones que puedan quedar como remanentes de la
ejecución parcial.

5. Se detendrá la ejecución del proceso automatizado.

5. VARIABLES & REPORTS

1. Log CSV con el resultado de la ejecución de los 33 casos de prueba, que

incluye el código del caso RET_N y el resultado de ejecución Passed o Failed.

6. ADDITIONAL DETAILS

1. El envío de notificaciones de email se realiza mediante Outlook.

2. El Sistema operativo utilizado durante el proceso es Windows Server 2016.

3. La resolución del equipo donde se ejecutará la automatización es 1024 x 768.

Page|22
 Process Design Document

7. ADDITIONAL PROCESS CONSIDERATIONS

Process Questionnaire:

Question Answer
What is current Schedule of execution? NA.

What is the average volume of Transactions 33 Test cases by business day (7 hours).
for given frequency?
How long does it take to go through one 12.72 minutes.
Transaction/Cycle?
How many Persons execute process 3 people
concurrently currently?
Can multiple instances of process execute Yes.
concurrently? Do the Systems/Apps support
that?
Does process involve Personally Identifiable No.
Information (PII)?
What are the main goals/targets? ☒ Faster execution

☒ Error Reduction/High Accuracy

☒ Higher up time/Multiple executions

☒ Timely completion
Is this process event triggered, time/day No.
triggered, or as needed?

8. APPENDIX

8.1 GLOSSARY

Page|23
 Process Design Document

Acronym / Term Description

TTD / USD Trinidad & Tobago Dollar / United States Dollar

CC Credit Card

VTM Visa TravelMoney

Page|24