Tesina Currao Junio 2022

Licenciatura en Informática
Análisis de Automatización de Testing para sitios Web

Currao, Domingo Yamil (Matrícula 501-11186)
Tutor: María Belén Piedrabuena (Legajo 8906)
Facultad de Tecnología Informática
2022
2022
Currao, Domingo Yamil
Agradecimientos
A la Lic. María Belén Piedrabuena, que con todos sus consejos, predisposición y empatía
impulsó a que se desarrolle esta tesina.
A la Mg. Paula Angeleri, por su constante ayuda y apoyo durante toda la carrera de
Licenciatura en Sistemas.
Al Mg. Sergio Aguilera, por su motivación y ayuda constante durante toda la carrera de
Al PhD. Alejandro Mitaritonna, por todos los conocimientos y dedicación en la carrera de
A todos mis compañeros, amigos y familia, por brindar la ayuda necesaria para realizar esta
tesina y carrera.
Licenciatura en Informática - 501 2/93

2022
Agradecimientos 2
Índice de tablas 6
Índice de figuras 6
Resumen 7
Abstract 8
Introducción 9
Contexto del problema 9
Justificación 13
Organización de la tesina 14
Alcance 14
Limitaciones 16
Objetivos 17
Objetivo general 17
Objetivos específicos 17
Objetivos personales 18
Hipótesis 19
Marco teórico 19
Proceso de evaluación 19
Características 23
Característica Adaptabilidad 24
Característica Calidad de los artefactos 25
Característica Eficiencia 27
Característica Instalabilidad 28
Característica Satisfacción de los usuarios 29
Característica Usabilidad 30
Antecedentes 31
Bug 31
Debugging 32
Quality Management 33
Estado del arte 34
Desarrollo de la tesina 34
Java y Selenium 34
Introducción Herramienta 35
Java 35
Selenium 35
Maven 37
TestNG 38
Framework generado 38

2022
ATDD 39
Katalon 49
Groovy 52
Katalon TestOps 52
Katalon Recorder 53
Katalium 54
Cucumber 63
Gherkin 63
Junit 64
Maven 64
Selenium 64
BDD 65
Realizar las Pruebas 73
Tabla comparativa de métricas de herramientas 73
Analizar las Evaluaciones 77
Resultados 78
Conclusiones 79
Líneas futuras de investigación 80
Bibliografía 81

2022
Glosario 83
Anexos 86
Proceso de evaluación: MyFEPS 86
Escala Likert 86
Tipos de metodologías de Testing 87
Testing Relámpago 88
CI/CD 89
Page Object Model (Pattern) 89
ISTQB 89
Test Management Tools 90
XPath 91
Código de las herramientas 93

2022
Índice de tablas
Tabla 1: Marco de trabajo MyFEPS
Índice de figuras
Figura 1: Ventajas de automation 9

Figura 2: Herramienta HP UFT/QTP 11
Figura 3: Herramienta Cypress 12
Figura 4: Características y subcaracterísticas 20
Figura 5: Alta cohesión y bajo acoplamiento 22
Figura 6: Modularidad ejemplo Phoneblocks 23
Figura 7: UI vs UX 26
Figura 8: The First "Computer Bug" 27
Figura 9: Debugging 28
Figura 10: Selenium IDE 31
Figura 11: Webdriver 32
Figura 12: ATDD 35
Figura 13: Eclipse IDE 39
Figura 14: Archivo pom.xml 40
Figura 15: Caso de prueba TestNG Java 41
Figura 16: Help 43
Figura 17: Test suite 44
Figura 18: Xpath 44
Figura 19: Katalon Groovy 49
Figura 20: Ruta Katalon instalador 51
Figura 21: Acceso Katalon 51
Figura 22: Upgrade 52
Figura 23: Help Eclipse 54
Figura 24: Gherkin 56
Figura 25: Código fuente Java 59
Figura 26: Memoria ram 60

2022
Figura 27: Escala Likert 76

Figura 28: Sistema operativo Linux 35
Figura 29: Katalon recorder 47
Figura 30: TDD 57
Figura 31: Archivo Cucumber, JUnit y Selenium 61
Figura 32: Hoja “Resultado total“ de la herramienta 1.0 64
Figura 33: Evaluación por el Developer Lead (SR) Federico 63
Figura 34: Hoja “Resultado total” de la herramienta 2.0 65
Figura 35: Hoja Valores de referencia herramienta 2.0 66
Figura 36: Hoja “Resultado total” de la herramienta 3.0 66
Figura 37: Puntaje evaluador herramienta 3.0 67
Figura 38: Valores de referencia 68
Figura 39: Preguntas realizadas en las evaluaciones 68
Figura 40: Certificación ISTQB 78
Figura 41: Testrail - Test management tool 79
Figura 42: XPath absoluto ejemplo 80
Figura 43: XPath relativo ejemplo 80
Figura 44: Repositorios de código de las herramientas 81
Resumen
La tesina desarrollada consta del análisis de la automatización del testing aplicado a sitios
Web, otorgando conclusiones que mencionan por qué se debe utilizar en las empresas de software
de hoy en día, por qué es importante realizar testing automatizado y cómo debemos automatizar y
probar nuestros sistemas Web.
Se realizó en dicha tesina la evaluación de tres (3) opciones de herramientas de testing
automatizado. El primero Java y Selenium (herramienta 1.0), el segundo Katalon (herramienta 2.0) y
el tercero Cucumber (herramienta 3.0), utilizando de referencia la Arquitectura MyFEPS que permitió
obtener conclusiones no sólo de la evaluación realizada sino de la importancia del Testing
Automatizado.
Se investigaron varias herramientas (o frameworks) que se utilizan en las empresas de hoy

2022
en día1 para automatizar las pruebas manuales de los casos de pruebas de sitios Web.
En las evaluación realizadas se aplicaron métricas tomando como referencia la arquitectura
elegida y se ponderaron las características evaluadas de las herramientas para obtener resultados
sobre la importancia del testing automatizado.
Finalmente con los resultados obtenidos de la evaluación y junto a la investigación realizada
del testing automatizado, se elaboraron conclusiones finales que dieron espacio a líneas futuras de
investigación.
Por otro lado se expusieron fundamentos propios y también obtenidos de la Arquitectura
MyFEPS que indican por qué se debe utilizar la automatización del testing en las empresas.
Abstract
This final work consists of the analysis of the automation of testing applied to websites, giving
conclusions that mention why it should be used in today's software companies, why it is important to
make automated testing and how we should automate and test our web systems.
In this work, the evaluation of three (3) options of automated testing tools was developed. The
first Java and Selenium (Framework 1.0), the second Katalon (Framework 2.0) and the third
Cucumber (Framework 3.0) using references of MyFEPS Architecture, which allowed conclusions to
be drawn not only from the evaluation developed, but also from the importance of Automated Testing.
A lot of tools (or frameworks) are used in the businesses of today. In this evaluation, metrics
of the chosen architecture were applied and the evaluated characteristics of the tool were weighted to
obtain results on the importance of automated testing.
Finally, with the results obtained from the evaluation and together with the research carried
out on automated testing, final conclusions were drawn up that gave space to future lines of research.
Also, fundamentals were exposed and also obtained from MyFEPS Architecture that indicate why
testing automation should be used in companies.
1
Se comenzó el desarrollo de esta tesina en el mes de junio de 2019.

2022
Introducción
Contexto del problema
En la actualidad hay muchas empresas2 de desarrollo de sistemas de software, tanto a nivel

mundial como en Argentina.3 Las pequeñas y medianas empresas que empiezan a crecer cada vez
más, notan que sus productos de software necesitan pruebas más profesionales que las manuales
no pueden otorgar.
Cabe destacar que muchas empresas quizás nunca detectan la importancia de probar las
aplicaciones que desarrollan, no detectan la importancia de crear casos de prueba que incluyan
cuáles son los puntos que se deben probar y menos que menos la crucial importancia de comenzar a
automatizar las pruebas que se tienen que realizar en sus productos de software.
El testing manual es el primer enfoque o acercamiento que las empresas suelen aplicar a los
proyectos en curso. Si bien esto es importante y ayuda mucho, no suele servir del todo cuando hay
muchas iteraciones de código (nuevas versiones4, releases, etc. ) que se suben (implementan) a
producción de una forma desordenada.
2
The Software Report - Recuperado el 19 de abril de 2021
https://www.thesoftwarereport.com/the-top-100
CESSI - Cámara de la industria Argentina del Software - Recuperado el 19 de abril de 2021
https://www.cessi.org.ar/empresas_argentinas
3
Telam - Recuperado el 24 de mayo de 2019
http://www.telam.com.ar/notas/201905
4
Mercurial - The Definitive Guide - Recuperado el 26 de junio de 2019
http://hgbook.red-bean.com/read/how-did-we-get-here.html

2022
Figura 1: Se muestra gráficamente las ventajas de automation comparadas con tareas manuales 5
Utilizando sólamente el testing manual tampoco ayuda cuando no hay una buena gestión en
las empresas que deberían focalizar la calidad de sus productos en vez de las subidas a producción.
La gestión debe priorizar la calidad de los sistemas frente a las promesas de funcionalidades que se
comprometen con los clientes y stakeholders, si esto no se realiza así, se incurrirá en errores o fallas
del sistema que impactarán directamente al usuario o cliente.
Aprovechando la automatización de las pruebas, para que en menos tiempo se puedan
probar más cosas, se pueden entregar funcionalidades del sistema a producción, satisfacer al cliente
en menor tiempo y con una cobertura de calidad aceptable.
De ahí surgen las pruebas automatizadas, que tienden a reemplazar gran parte de las
pruebas que se realizan de forma manual. Esto se podría también pensar como la automatización de
las tareas repetitivas, que en este caso, son las pruebas manuales.
Este reemplazo de las pruebas manuales por las automatizadas tiende a cubrir, al principio
del pasaje, un porcentaje chico de coverage o cobertura de pruebas, pero lo ideal es que el mismo
crezca cada vez más, lo que le dará robustez a las pruebas de regresión que se realicen.
El coverage6 indica cuál es el porcentaje de pruebas que tiene un proyecto. Las mismas
pueden ser automatizadas o manuales. Es importante tener separado esto en secciones para poder
realizar un seguimiento mayor de cuantas pruebas son manuales, cuantas automatizadas, cuantas
5
Recuperado el 11 de mayo del 2022 -
https://www.professionalqa.com/manual-testing-vs-automation-testing
6
Recuperado el 25 de enero del 2022 -
https://www.guru99.com/test-coverage-in-software-testing.html

2022
de un tipo de pruebas y cuantas de otros tipos. (Ver en el anexo de esta tesina Test Management
Tools).
Lo importante de la cobertura de pruebas es que al necesitar probar nuevamente el producto
(un sistema web, cualquier tipo de aplicación o software) que tenemos cubierto, sólo tenemos que
ejecutar esos casos de prueba nuevamente para aprobar o no la salida a producción del mismo,
teniendo en cuenta si el porcentaje de cobertura es igual al porcentaje de aprobación de la ejecución
realizada.
La herramienta que más se utilizan hoy en día para realizar la automatización de sitios Web
es Selenium7 (con el lenguaje de programación Java, por ejemplo). Selenium posee una de las
comunidades de desarrolladores más grandes en internet, lo que permite a los programadores
obtener soporte de forma rápida al necesitar resolver inconvenientes en el desarrollo8.
Durante mis años de experiencia en el área de QA he insistido e impulsado el uso de Java y
Selenium para todo tipo de pruebas en desarrollos Web. Si bien hay muchas otras herramientas
(tools9) que compiten (y conviven) con Java y Selenium, no tienen la misma comodidad para trabajar
con ellas, no tienen la misma comunidad extensa, escalabilidad, entre otras cosas que mencionamos
en esta tesina.
De todas formas, uno como líder de un área de QA siempre tiene que plantear la idea de
cómo quiere que el área crezca y se desarrolle, pero por otro lado, y quizás esto sea hasta más
importante, debe escuchar la opinión de los técnicos que trabajan con él o para él, ya que un líder de
QA suele estar enfocado en la gestión y pierde el foco de las tecnologías de automation que salen al
mercado y mejoran cada vez más las automatizaciones y la calidad de lo sistemas que prueban.
Algunas otras opciones que existen en el mercado actual son:
● HP UFT/QTP10, que implementa el diseño de objetos para encapsular ciertas funcionalidades

y facilitar al tester las pruebas automatizadas, dando la opción de realizar las pruebas a
través de código como con el recorder o grabador que posee la solución. Sólo disponible en
su versión paga.
7
Testingbaires - Recuperado el 24 de mayo de 2019 https://testingbaires.com/2017
8
Seleniumhq - Recuperado el 26 de junio de 2019- https://www.Seleniumhq.org/support/
9
Tools de testing - Recuperado el 25 de junio de 2019 -
https://www.guru99.com/automated-testing-tools.html
10
Sitio Web oficial de HP QTP - Recuperado el 25 de junio de 2019 -https://www.microfocus.com/

2022
Figura 2: Capturas del sitio oficial de HP sobre la herramienta HP UFT/QTP11
● Katalon12, que también permitiendo el desarrollo de objetos permite realizar los casos de
prueba de un sitio Web a testear. Tiene una versión gratuita para principiantes o proyectos
propios y una versión paga para organizaciones. Esta herramienta es una de las evaluadas
para la obtención de conclusiones en esta tesina.
● Cucumber13, que cada vez su puesta en escena es más fuerte14, es una herramienta que
permite el desarrollo basado en el comportamiento, donde con un lenguaje natural nos
permite acercarnos a lo que quiere el cliente y luego programarlo para realizar nuestras
pruebas automatizadas. En esta tesina utilizamos esta herramienta a modo demostrativo de
cómo se utiliza.
● Webdriver.io15, que utilizando la simpleza para programar de Javascript permite desarrollar
pruebas para Web como para aplicaciones mobile. Esta herramienta es un framework que se
utiliza junto a Node.js.
● Cypress16, que como se define en su propia página web, es un framework que es rápido ya
que utiliza Javascript y permite probar todo lo que se ejecuta en un navegador o browser.
Este framework tiene su versión gratuita o paga según cantidad de usuarios, entre otras
cosas.
11
Imagen obtenida del sitio oficial - Recuperado el 11 de mayo de 2022 -
https://www.microfocus.com/en-us/products/uft-one
12
Sitio Web oficial de Katalon - Recuperado el 25 de julio de 2019 - https://www.katalon.com/
13
Sitio Web oficial de Cucumber- Recuperado el 25 de julio de 2019 - https://cucumber.io/
14
Recuperado el 25 de julio de 2019 - Conclusión en base a la experiencia que se tiene trabajando
en esto y desde el sitio: https://www.guru99.com/automated-testing-tools.html
15
Sitio Web oficial de Webdriver.io - Recuperado el 16 de mayo de 2022 - https://webdriver.io/
16
Sitio Web oficial de Cypress- Recuperado el 25 de julio de 2019 - https://www.cypress.io/

2022
Figura 3: Capturas del sitio oficial de Cypress17
Por último, las compañías de hoy en día tienen que analizar cuál de todas las soluciones
existentes en el mercado les permiten resolver la automatización de las pruebas manuales que
tienen implementadas en su compañía para así mejorar la calidad de los sitios Web desarrollados.
Esto deben realizarlo en conjunto con su equipo ya que ellos son los que van a utilizar las
herramientas y son los que tienen que tener el expertis de las tools para utilizarlas de la forma más
eficiente posible.
Justificación
Hoy en día, y cada vez más, las empresas necesitan implementar herramientas de testing
automatizado18 para garantizar la cobertura de las pruebas en sus proyectos.
Cuando una empresa, que posee un servicio web, crece, también lo hace dicho servicio web
mencionado. Cuando esto pasa, al ser esta web un sistema que comienza a escalar, empieza a no
17
Sitio oficial - Recuperado el 25 de julio de 2019 - https://www.cypress.io/features
18
Computing - Recuperado el 24 de mayo de 2019 - http://www.computing.es/analytics/informes

2022
ser viable tener casos de prueba que se ejecutan de forma manual debido al tiempo y costo que esto
lleva.
Se propuso a través de esta tesina realizar investigaciones, análisis, evaluaciones y
proporcionar conclusiones para que todo este trabajo junto pueda ser utilizado como un documento
que le sirva a todas las empresas (tengan un sistema web o no) y también a los analistas de calidad
(QA, QC, Testers), Desarrolladores, PM’s, entre otros interesados.
Organización de la tesina
Se menciona a continuación las secciones que posee esta tesina:
1. Introducción: Se compone del contexto del problema, justificación de la tesina, alcance de

la misma, sus limitaciones y todos los objetivos que la misma pretende cumplir (Objetivos
generales, específicos y personales).
2. Marco teórico: Se mencionan los conceptos fundamentales para el desarrollo de esta
tesina. Algunos de ellos son el proceso de evaluación que menciona las características a
evaluar en las herramientas de testing utilizadas. Se mencionan modelos de calidad,
antecedentes y el estado del arte.
3. Desarrollo de la tesina: Se mencionan las tres herramientas evaluadas tomando como
referencia el proceso de MyFEPS (sus componentes, sus características) y también otras
herramientas o métodos mencionados en la tesina.
4. Evaluación de software: Se mencionan las normas, frameworks o herramientas que se
utilizaron de base para realizar las evaluaciones de las herramientas de automation.
5. Resultados: Se mencionan los resultados de las evaluaciones realizadas en la tesina de las
herramientas de automation Web.
6. Conclusiones: Se mencionan las conclusiones en base a toda la tesina y los resultados
obtenidos de las evaluaciones realizadas. Se incluyen también en esta sección las líneas
futuras de investigación.
Alcance

2022
El alcance de esta tesina comprende los siguientes puntos:
● Investigación de herramientas de automation (se hace foco en herramientas de automation

para sitios web pero se mencionan algunas otras). En la tesina se mencionan las
herramientas que más se utilizan en las empresas de software de hoy en día.
● Desarrollo de un framework en Java y Selenium (herramienta 1.0) para mostrar a modo de
ejemplo pruebas de automation aplicadas a una Web real. Sobre esta herramienta se aplicó
la evaluación mediante conceptos obtenidos del framework MyFEPS entre otros métodos
mencionados en la tesina.
● Desarrollo de pruebas automatizadas mediante Katalon Studio (herramienta 2.0) para
mostrar a modo de ejemplo pruebas de automation aplicadas a una Web real. Sobre esta
herramienta también se realizó la evaluación mediante conceptos de MyFEPS a modo de
evaluación de la misma.
● Desarrollo de un framework en Cucumber (herramienta 3.0) para mostrar a modo de
ejemplo pruebas de automation aplicadas a una Web real. Se aplicaron conceptos de
MyFEPS para la evaluación realizada de la herramienta 3.0.
● Documentación y fundamentos de por qué se eligió Java y Selenium (herramienta 1.0) como
la herramienta recomendada y principal de las conclusiones de esta tesina.
● Otras herramientas de las cuales también se habla en este trabajo son HP QTP, Appium,
JMeter, Postman, entre otras.
● Desarrollo de las conclusiones que recomiendan Java, Selenium y otras tools para ser
utilizada por las pequeñas y grandes empresas para el desarrollo de las pruebas
automatizadas para sitios Web. También se mencionan conclusiones de por qué es
importante el uso de herramientas de automation en las empresas de hoy en día.
● Si bien en esta tesina se hablan de varias herramientas de automatización de pruebas para
sitios Web, el alcance de las evaluaciones realizadas mediante uso de conceptos de
MyFEPS, comprenden únicamente las herramientas Java y Selenium, Katalon y Cucumber.
● Las características del framework MyFEPS que se utilizaron como referencia para las
evaluaciones realizadas se mencionan a continuación:
1. Adaptabilidad
2. Calidad de los artefactos
3. Eficiencia
4. Instalabilidad
5. Satisfacción de los usuarios

2022
6. Usabilidad
● Para poder evaluar las características, subcaracterísticas y atributos anteriormente

mencionadas, se utilizaron tres (3) proyectos (también llamados programas) hechos en Java
y Selenium, Cucumber y Katalon que se analizaron tomando como referencia el framework
MyFEPS.
● En el alcance de este trabajo también se incorporaron tres (3) Test Suites en total (una por
cada herramienta). Cada conjunto de pruebas (cada Suite) se conforma de un grupo (o set)
de pruebas automatizadas que al ejecutar las mismas prueban el sitio Web elegido.
● La Web que se utilizará a fin de medir las herramientas para la evaluación es la siguiente:
https://testingrelampago.com/
● La tesina incluye los resultados y conclusiones obtenidos en la evaluación mencionada,

describiendo cuáles son los puntos de investigación que se podrían continuar y que están
relacionados con los resultados o análisis realizados.
● El alcance de estos resultados o conclusiones mencionados servirá para las pequeñas y
grandes empresas que aún no han involucrado la automatización de sus pruebas a sus
sistemas Web.
● Esta tesina podrá también ser utilizada para todo interesado en las pruebas automatizadas
ya sea para sistemas Web, de escritorio, aplicaciones mobile, entre otros sistemas, ya que la
tesina será de mucha ayuda para readaptar la misma, elegir otras herramientas de
automation y aplicar los conceptos a lo que se necesite probar.
Limitaciones
Las limitaciones de esta tesina se mencionan a continuación:
● Las Test Suites desarrolladas son en las herramientas Java y Selenium, Katalon y Cucumber,
no se realizaron casos de prueba o test suites en otras herramientas mencionadas.
● No se desarrollaron todos los casos de prueba que testean a todo el sitio Web propuesto a
modo de ejemplo, sino un conjunto de casos de prueba de los atributos a probar en la
evaluación a realizar con los conceptos de MyFEPS.
● Los casos de prueba y test suites fueron desarrollados en local, se ejecutan en local para las

2022
pruebas de la tesina y se subirán en un repositorio para el control de las versiones

necesarias.
● No se utilizará ningún servidor en la nube para estas pruebas, o sea, no se utilizará
integración continua (CI/CD).
● No se utilizó el framework MyFEPS en su totalidad, sino que se utilizaron algunos de los
conceptos que tiene el mismo para enriquecer la tesina realizada.
Objetivos
Objetivo general
El objetivo principal de esta tesina es determinar la importancia del uso de herramientas de

automatización para el desarrollo de pruebas de las empresas. Para esto se realizaron evaluaciones
con conceptos del framework MyFEPS y se ponderaron las evaluaciones para elegir una de las
herramientas como candidata a ser la opción a las empresas al iniciar el automation de sitios Web.
Hay que tener en cuenta que las pruebas manuales tienen sus limitaciones, por ejemplo, si
es necesario tener que probar una aplicación en un corto tiempo no es posible realizar el testeo de
regresión de todas las funcionalidades de forma rápida, completa y correcta. Por eso a través de esta
tesina se pretende fomentar el uso de soluciones automatizadas para realizar pruebas correctas, con
mayor alcance y evitar problemas que se puedan llegar a generar en el testeo manual.
Otro de los objetivos también principales es incorporar a través de esta tesina el concepto de
automatización (automation), para generar dudas sobre para qué sirve el mismo, si es viable aplicarlo
a su empresa, cómo se puede aplicar, entre otros interrogantes que puedan surgir del lector.
Objetivos específicos
Los objetivos específicos que esta tesina desarrolla son:
● Evaluación de las herramientas 1.0, 2.0 y 3.0 mediante los conceptos de la metodología
MyFEPS.
● Utilización de algunos de los procesos del framework MyFEPS como guía para esta

2022
evaluación a realizar.
● Realización de tres (3) Test Suites (colección de casos de pruebas automatizados) en las
herramientas mencionadas apuntando al sitio Web de prueba elegido.
● Ponderación de las herramientas en base a los puntos (características elegidas) a evaluar.
● Obtención de las conclusiones de la evaluación a desarrollar.
● Exponer ideas propias frente a las conclusiones obtenidas, y frente a estas, permitir la
utilización de la herramienta elegida para uso de empresas u otros analistas de calidad.
● Impulsar el automation en todas las empresas tengan un sistema web a probar o no, trabajen
en sistemas o no. (Automatizar los procesos o sistemas de las empresas considero que es el
futuro de todas las empresas).
Objetivos personales
Los objetivos personales que se incluyen en esta tesina son:
● Aplicar todos los conocimientos obtenidos en la carrera Licenciatura en Sistemas de la

Universidad de Belgrano.
● Otorgar herramientas a través de lo escrito en esta tesina para todo aquel que lo necesite,
sea para aplicarlo en su trabajo, empresa o estudios.
● Fomentar el estudio de las herramientas de Automation, que si bien esta tesina habla de
herramientas de automatización de sitios Web, también se mencionan herramientas de todo
tipo de automatizaciones, que son la base para las empresas de sistemas del futuro.
● Fomentar el pensamiento de la automatización de tareas repetitivas. Más allá de las pruebas
manuales, hay muchas tareas que son repetitivas y que pueden automatizarse, uno de estos
casos son las pruebas manuales que se realizan en QA pero no debe quedar el pensamiento
sólo allí sino expandirlo a otras funcionalidades.
● Otorgar esta tesina a todo el interesado que la requiera y fomentar la misma por las redes
sociales que se consideren al finalizar la misma. (Por ejemplo Linkedin19)
19
Sito oficial - Recuperado el 11 de mayo de 2022 - https://www.linkedin.com

2022
Hipótesis
Se propone como hipótesis de esta tesina demostrar que el testing automatizado es una
práctica imprescindible para las empresas de hoy en día. Para demostrar esto, se realizaron
evaluaciones de tres herramientas mencionadas para otorgar la conclusión sobre una de ellas como
buena práctica para que las empresas tengan como referencia una herramienta a utilizar para la
automatización de sitios Web.
La investigación realizada en esta tesina demuestra mediante su contenido y los ejemplos
desarrollados en las herramientas de testing automatizado que se puede aplicar lo mencionado en la
misma en las empresas de hoy en día.
Marco teórico
Proceso de evaluación
En esta tesina se evaluaron tres herramientas utilizando el marco de trabajo MyFEPS como
guía. Se utilizó para la evaluación de las herramientas el proceso ágil de evaluación MyFEPS (en la
sección Bibliografía se mencionan los documentos utilizados de MyFEPS).
Este proceso ágil se compone de las etapas definidas en la siguiente tabla y que son
compatibles con la norma ISO/IEC 25040.20
ID21 Actividad o tarea de MyFEPS Descripción
2 Establecer el Propósito de la El propósito de esta tesina es comparar las herramientas

Evaluación de automation, productos de igual propósito, para estimar la
calidad de cada uno de ellos y seleccionar uno entre ellos
20
Sitio oficial ISO/IEC 25040- Recuperado el 06 de julio de 2019 -
https://iso25000.com/index.php/normas-iso-25000/iso-25040
21
El id es el indicador de la actividad a realizar en la documentación de MyFEPS. Para mayor
información ir a la sección de Bibliografía de esta tesina

2022
como la mejor opción
3 Identificar el Producto a Los productos a evaluar son las tres herramientas de

Evaluar testing automatizado ya mencionadas. Los componentes de
cada una de ellas se mencionan y detallan en el desarrollo
de esta tesina
4 Identificar los Requerimientos Definiciones:

de Calidad ● Evaluador: Domingo Yamil Currao
● Stakeholders:
○ SDET22 (SR): Agustín
○ Developer Lead (SR): Federico
○ Tester Automation (SSR): Hernán
○ Evaluador QA Lead (SR): Domingo Yamil
Currao
● Requerimientos de calidad: Se optó en esta tesina
por trabajar con el modelo QSAT23. Las
características a evaluar son las mencionadas en la
sección Características dentro del apartado
Proceso de evaluación
14 Definir Recursos para la Los recursos a utilizar por el evaluador son:

Evaluación
● Computadora con sistema operativo Windows 11
(como laboratorio de pruebas para el evaluador)
donde se instalarán las tres herramientas y se las
pondrán a prueba.
● Computadoras de los stakeholders (ejecutando
Mac, Linux o Windows en distintas distribuciones
para realizar algunas pruebas con los interesados)
17 Establecer Ponderación de Las características que se utilizarán para ponderar las

Ítems de calidad herramientas de automation son las siguientes:
● Adaptabilidad
22
SDET - Recuperado el 25 de enero de 2022 - https://www.linkedin.com/pulse/que-es-un-sdet
23
QSAT - MyFEPS - Recuperado el 06 de julio de 2019 - Sitio oficial:
https://sites.google.com/a/comunidad.ub.edu.ar/myfeps/qsat-1

2022
● Calidad de los artefactos

● Eficiencia
● Instalabilidad
● Satisfacción de los usuarios
● Usabilidad
Estas características son las que los stakeholders,
mencionados en la actividad “Identificar los Requerimientos
de Calidad” de esta tabla, seleccionaron como importantes
o muy importantes.24
Si bien se analizaron los resultados de las evaluaciones de

las tres herramientas, damos por aprobada la evaluación de
cualquiera de las características cuando su medición es
mayor o igual a 70%, entre valores de 0% a 100% (o que
es lo mismo 0,7 entre valores de 0 a 1).
Los valores que completaron los stakeholders son los

mencionados a continuación y que tienen un peso
(ponderación) que luego se tuvo en cuenta en la conclusión
final (Importancia Relativa25):
1 - Primer ponderación que se les dió a los interesados

como opciones:
● Muy importante: Peso de 100%

● Importante: Peso de 75%
● Medianamente importante: Peso de 50%
● Algo importante: Peso de 25%
● Totalmente sin importancia: Peso de 0%
2 - Segunda ponderación que se les dió (escala Likert

mencionada en el Anexo de esta tesina):
24
Documento MyFEPS ágil. Para mayor información ir a la sección de Bibliografía de esta tesina
25
Documento MyFEPS ágil. Para mayor información ir a la sección de Bibliografía de esta tesina

2022
● Excelente: Peso de 100%

● Muy bueno: Peso de 75%
● Bueno: Peso de 50%
● Indiferente: Peso de 25%
● Malo: Peso de 0%
21 Preparar Recursos e Para este punto se realizaron reuniones con los

Infraestructura stakeholders ya mencionados, se les explicó la evaluación
a realizar y los objetivos.
Se utilizó la herramienta de Google Sheets26 para la

realización de la evaluación de cada una de las
herramientas por cada uno de los stakeholders.
Cada uno de los stakeholders utilizó su propia computadora

para analizar las ponderaciones de las características a
evaluar, siempre con la orientación y ayuda del evaluador
por cualquier inconveniente.
Los casos de prueba de la evaluación a realizar por cada

stakeholder (con la guía del evaluador) son los definidos en
la sección de esta tesina llamada Características, que
también se incluyen en las características a evaluar en el
documento de Google Sheet.
30 Realizar las Pruebas Se pidió a los stakeholders que ejecuten los casos de
prueba de la evaluación (ejecución de las características)
guiados por el Evaluador
35 Medir los Atributos requeridos Se realizó junto a los stakeholders la ponderación de la

por las Métricas Importancia Relativa (y de la escala Likert según
corresponda) en la herramienta Google Sheet.
En la documentación de MyFEPS menciona como
26
Google Sheets - Recuperado el 06 de agosto de 2019 - Sitio oficial
https://www.google.com/sheets/about/

2022
sugerencia Excel27 pero ambas herramientas cumplen con

los mismos objetivos para la evaluación que se realizó.
Esta evaluación se realizó con cada una de las
herramientas a evaluar.
39 Analizar y Calcular los En las secciones “Conclusiones y Resultados” de esta

resultados tesina se mencionan cuáles fueron los resultados finales de
las herramientas evaluadas y si se alcanzó o superó el
grado de calidad de 70% mencionado en la tesina.
Se adjuntan en esta tesina los documentos

correspondientes a las evaluaciones de las herramientas
por cada uno de los stakeholders.
Tabla 1: Marco de trabajo MyFEPS
Se omitió en esta tabla las precedencias de cada una de las actividades a realizar, pero las
mismas se detallan en la documentación de MyFEPS definida en la Bibliografía de esta tesina.
Características
Como se menciona en el documento de MyFEPS ágil, el proceso de evaluación es para

productos de similar propósito (en nuestro caso herramientas de testing automatizado) y uno de los
objetivos es el de comparar dos o más herramientas (en nuestro caso tres) que tengan similar
funcionalidades.
Se seleccionó y tomó como referencia este framework ya que se pensó en seleccionar una
de las herramientas evaluadas frente a ciertos criterios (características) para obtener una
recomendación objetiva (aunque también subjetiva) y MyFEPS resolvía de una forma sencilla y
práctica muchos de los criterios que se necesitaban y que ayudaban para las evaluaciones a realizar.
Este framework posee características que se dividen en subcaracterísticas. A estas últimas
se las divide en atributos a los cuales se le asignan métricas para medir los atributos de las
características del software a analizar, que en nuestro caso son tres herramientas de testing.
27
Excel - Recuperado el 06 de agosto de 2019 - Sitio oficial
https://www.microsoft.com/es-ar/microsoft-365/excel

2022
Se muestra a continuación un gráfico que clarifica mejor el párrafo mencionado

anteriormente:
Figura 4: Características y subcaracterísticas
Se mencionan a continuación las características que se utilizaron como referencia para medir
las herramientas y llegar a las conclusiones indicadas en esta tesina:
Característica Adaptabilidad
Nos habla de cómo la herramienta de automation se puede instalar en diferentes entornos,

en diferentes computadoras o utilizando distintos navegadores.
Utilizamos del framework MyFEPS las siguientes subcategorías de la característica
Adaptabilidad:
1. Adaptabilidad a diferentes entornos, que posee los siguientes atributos utilizados para la
medición en esta tesina:
a. Esfuerzo en horas hombre para la adaptación de la herramienta elegida en los
diferentes entornos a utilizar (en este caso la computadora a utilizar)
b. Tiempo necesario para la adaptación del framework a instalar en el entorno o
computadora a utilizar
c. Valor monetario que se necesita para implementar la herramienta (o framework de

2022
automation) en la computadora del automation sumando todos los recursos a utilizar
2. Adaptabilidad a diferentes idiomas, que posee los siguientes atributos:

a. Esfuerzo que se necesita (horas hombre) para la adaptación del framework en los
diferentes idiomas necesarios en la computadora a instalar
b. Tiempo necesario para la adaptación del framework de automation en los idiomas
necesarios
c. Valor monetario para la adaptación del framework en los idiomas necesarios
sumando todos los recursos a utilizar
Característica Calidad de los artefactos
Nos habla de la calidad que poseen cada uno de los componentes utilizados en nuestro
framework de automation. En esta tesina evaluamos algunos atributos como la cohesividad,
acoplamiento, trazabilidad, modularidad, reusabilidad, existencia de documentación estándar y
calidad de código fuente.
Utilizamos del framework MyFEPS las siguientes subcategorías de la característica Calidad
de los artefactos:
1. Cohesividad, es el grado de unión entre los componentes del framework a analizar. Indica
qué tan dependientes son los componentes entre sí.
El marco de trabajo MyFEPS menciona que se debe ejecutar un Parser para analizar el
grado de cohesividad de un software.
2. Acoplamiento, es el grado de independencia entre los componentes. Es lo contrario a la

cohesividad y suele ser necesario para los softwares que tengan grados altos de
acoplamiento y bajos de cohesión.
MyFEPS menciona que se debe ejecutar un Parser para analizar el grado de acoplamiento
de un software.

2022
28
Figura 5: Alta cohesión y bajo acoplamiento
3. Trazabilidad, es la posibilidad de que los componentes de un framework a analizar puedan

ser trazables entre sí, o sea que se puedan relacionar todos los componentes del software a
analizar mediante un indicador que relacione sus componentes.
Se debe contar la cantidad de hijos y padres trazables del software a analizar
4. Modularidad, es la división del software en componentes que se intercomunican entre sí.

Mientras más modulado está un software, más simple es analizarlo, incrementar sus
funcionalidades, entre otras cosas.
a. Grado de Modularidad, por cada artefacto del framework de automation a evaluar, se
deberán evaluar también los artefactos o componentes de los mismos para obtener
sus grados de modularidad.
28
Alta cohesión y el bajo acoplamiento - Recuperado el 07 de agosto de 2019 -
https://blog.koalite.com/2015/02/cohesion-y-acoplamiento/

2022
Figura 6: Se muestra la modularidad con un ejemplo de Phoneblocks29
5. Reusabilidad, es permitir que los componentes o artefactos de un software, o framework de

automation a evaluar, sean reutilizables por el mismo framework y por sus componentes.
Esto es que no se dupliquen artefactos o componentes del framework. Media de
Reusabilidad, es un grado de reusabilidad de los componentes.
6. Existencia de documentación estándar, es la cantidad de componentes o artefactos que

están documentados del framework de automation a evaluar.
7. Calidad de código fuente, es la calidad que el código del framework de automation a

evaluar tiene en cada uno de los componentes a utilizar en el mismo.
a. Atributo de calidad de código fuente, MyFEPS menciona que se tiene que ejecutar
un parser para determinar el grado de la calidad del código de automation realizado
en la herramienta a evaluar.
Característica Eficiencia
Nos habla de la cantidad de recursos mínimos que necesitamos para permitir realizar
29
Sitio oficial de Phoneblocks - Muestra la modularidad - Recuperado el 11 de mayo de 2022 -
https://www.onearmy.earth/project/phonebloks

2022
nuestras pruebas automatizadas con éxito. Esto quiere decir que desarrollaremos nuestras pruebas
de la forma más rápida y con la menor cantidad de recursos disponibles.
Eficiencia:
1. Eficiencia en la interfaz del usuario, es la cantidad de recursos mínima que se utilizaron o

que se necesitan en la interfaz de la herramienta a evaluar.
a. Cantidad de horas-hombre utilizados en la interfaz que se necesitan para realizar las
pruebas automatizadas.
2. Eficiencia en los tiempos de respuesta, es el tiempo mínimo que se necesita para la

interacción con la herramienta. Se evaluará si la herramienta responde con una eficiencia
mínima en comparación del resto de las herramientas
a. Tiempo de respuesta de la herramienta
b. Cantidad de artefactos que se utilizaron para evaluar el tiempo de respuesta de la
herramienta
3. Eficiencia en la utilización de memoria interna, se evaluó la memoria interna mínima que

requiere la herramienta a evaluar. Se analizaron los requisitos mínimos de memoria interna a
utilizar por la herramienta a evaluar
a. Memoria interna utilizada para ejecutar la herramienta
4. Eficiencia en la utilización de otro hardware, se evalúa la eficiencia propia de la

herramienta con respecto a la cantidad mínima de hardwares que necesita para realizar las
pruebas automatizadas
5. Disponibilidad, se evalúa la eficiencia de recursos que la herramienta de automation

necesita para poder realizar las pruebas correspondientes.
Característica Instalabilidad
Nos habla de la facilidad de instalar o reinstalar nuestra herramienta sin necesidad de

recursos adicionales.

2022
Instalabilidad:
1. Primera instalación, es la facilidad de instalar la herramienta de automation para una

persona que recién aborda el proyecto de automation. Se evalúa también según el seniority
del programador de pruebas, (SR, SSR y JR)
2. Upgrades, es la facilidad que la herramienta tiene al realizar las actualizaciones de software

una vez que la tool ya está instalada en la computadora o dispositivo de la persona que la va
a utilizar.
Característica Satisfacción de los usuarios
Nos indica la facilidad de uso de esta herramienta que en este caso son los programadores
de pruebas automatizadas.
satisfacción de los usuarios:
1. Confort físico, nos indica el grado de comodidad que cada stakeholder tiene al utilizar la
herramienta de automation. O sea se evalúa el confort del uso de la herramienta de
automation.
2. En el acceso a las funciones, nos indica la facilidad de acceso a las funciones de la

herramienta de automation. Medimos estas funciones en base a la experiencia del
desarrollador de pruebas.
3. En la comprensión de las salidas del sistema, nos indica el grado de comprensión de las
salidas de la herramienta, o sea el output que la misma nos otorga para demostrar que una
prueba fue ejecutada de forma correcta, incorrecta, entre otra información de salida al
usuario de la herramienta.
4. En la estética, nos indica el grado de estética percibido por el usuario de la herramienta, o

sea que tan llamativo es la herramienta de automation para el usuario que la utilice.
5. En el conocimiento del sistema, es el grado de conocimiento de las operaciones que se

2022
realizan en el sistema por parte del desarrollador de las pruebas de automation. Se podría
indicar como el grado de conocimiento de los procesos de la herramienta que tienen los
desarrolladores de la misma.
6. Satisfacción total, es el grado de satisfacción que el usuario de la herramienta percibe al

utilizar la herramienta de automation. Se podría indicar como el grado de satisfacción que el
desarrollador siente al utilizar la herramienta.
Nota: Se muestra como complemento pero relacionada a esta característica la diferencia de

UX y UI (se explican en el Anexo de esta tesina) que se relaciona con la subcaracterística de
Satisfacción total:
Figura 7: UI vs UX 30
Característica Usabilidad
Nos indica la facilidad para que un usuario pueda desempeñar las pruebas automatizadas de
una forma eficiente.
30
UX vs UI - Recuperado el 11 de mayo de 2022 -
https://openclassrooms.com/en/courses/4556206-design-the-visual-side

2022

Usabilidad:
1. En el aprendizaje, es el tiempo de aprendizaje de la herramienta de automation para cada

nuevo desarrollador de las pruebas. También incorpora el tiempo de aprendizaje intuitivo
para cada usuario de la herramienta.
2. En la coherencia de la IU, incluye el número en promedio de interfaces que el desarrollador

visita hasta completar una tarea de automation específica.
3. En la entrada manual de información, es la cantidad de caracteres, entradas, cantidad de

tareas, que se tienen que realizar de forma manual para desempeñar tareas de
automatización en la herramienta
4. En el acceso a las funciones, es la velocidad en el acceso a funciones de la herramienta,

artefactos orientados a mejorar la velocidad de la herramienta y la velocidad de acceso a las
funciones.
5. En lo legal, es el grado en el que la herramienta cumple o no con la disposición legal

referente a la usabilidad
6. Efectividad del Help, es el grado de ayuda que posee la herramienta para ayudar al usuario
en toda la usabilidad de la herramienta de automatización
Antecedentes
Bug
Comenzaremos este apartado citando una de las frases más conocidas en el área de
pruebas de software:
“Las pruebas de software son el proceso de ejecutar un programa con la intención de

2022
encontrar errores” — Glenford J. Myers.31

La primer mención de un problema en un sistema fue mediante la palabra bug (que tiene
relación con debugging) el 9 de septiembre de 1947 cuando Grace Murray Hopper junto a un equipo
de sistemas encuentran en un relé electromagnético una polilla electrificada que había provocado un
fallo en el sistema.
En el informe que se realiza sobre este error, incorporaron la evidencia de la polilla como se
muestra a continuación:
Figura 8: El primer bug de computadora (The First "Computer Bug") 32
Esto muestra cómo frente a un error encontrado en el sistema se destaca en el informe el

problema encontrado adjunto, o sea, la polilla.
Debugging
El término debugging también está relacionado al término bug, pero en este caso se refiere
al arreglo de este error encontrado. Este término si bien fue anterior al mencionado refiere ya no a
31
Recuperado el 25 de enero de 2022 01:42 pm
https://sites.google.com/a/comunidad.ub.edu.ar/myfeps/introduccion
32
Recuperado el 25 de enero de 2022 01:41 pm
https://www.nationalgeographic.org/thisday/sep9/worlds-first-computer-bug/

2022
algo de sistemas, pero si está relacionado a ingeniería. El mismo fue escrito en un periódico llamado
Journal of the Royal Aeronautical Society de 1945. 33 34
Figura 9: Tomada de la herramienta 3.0 donde se visualiza la posibilidad de realizar un debug del
test case automatizado. También se visualiza en la línea de código 27 un breakpoint (se explica la
definición en el Anexo de la tesina).
Quality Management
La gestión de la calidad se remonta a los años 1924 donde William Edwards Deming,
considerado el padre del Quality Management, propuso aplicar a las empresas de producción
armamentista el método propuesto por Walter Shewhart sobre el control de calidad. 35
Esto ocurrió durante la segunda guerra mundial, lo que ocasionó que las empresas que
utilizaban estos métodos estadísticos en los procesos mejoren su eficiencia sin sacrificar la seguridad
de los empleados o de los productos.
William Edwards Deming es considerado el padre de la gestión de calidad y existe un premio
en su nombre. Este premio es uno de los más importantes referido a la calidad que se le puede
33
Recuperado el 25 de enero de 2022 01:21 pm http://www.worldwidewords.org/qa/qa-bug1.htm
34
Sitio web oficial de Royal Aeronautical Society https://www.aerosociety.com/
35
Recuperado el 25 de enero de 2022 - https://www.etq.com/blog/the-history-of-quality-management/

2022
otorgar a las empresas.36 Se empezó a otorgar en Japón gracias a la ayuda que Deming ofreció al
país y a sus empresas luego de finalizada la segunda guerra mundial.
También, cuando hablamos de la gestión de la calidad de sistemas, tenemos que mencionar
la ISO 9000 que es la familia de estándares que ayuda a las organizaciones a encontrar las
necesidades de los clientes y la de los interesados. La primera publicación de la ISO 9000 fue en
1987 por la ISO (International Organization for Standardization).
Estado del arte
En esta sección a modo resumen se menciona lo que se investigó en todo el desarrollo de

esta tesina:
● Se realizaron investigaciones de herramientas de automatización de casos manuales que

utilizan las empresas internacionales o nacionales para poder ejecutar de forma automática
los casos de pruebas que testean los proyectos.
● Se analizaron antecedentes a las herramientas de testeo automático que se utilizan en esta
tesina.
● Las fuentes de esta tesina, que se mencionan en la bibliografía y en los pie de página, son
libros, información de la experiencia desarrollando frameworks de automation en empresas
que estuve anteriormente, entre otras cosas.
● Se obtuvo mucho material de sitios web que fueron referenciados correctamente para que el
lector pueda incorporar o ampliar más de lo que se menciona en esta tesina.
● Muchos de los conceptos incluidos en esta tesina se pueden ampliar para enriquecer la
misma y a los lectores.
Desarrollo de la tesina
Java y Selenium
36
Recuperado el 25 de enero de 2022 - https://hmong.es/wiki/Deming_Prize

2022
Introducción Herramienta
Comenzaremos definiendo algunos conceptos sobre la herramienta Java y Selenium.

Utilizaremos a partir de ahora el alias “herramienta 1.0” para referenciar al conjunto de estas
tecnologías.
Java
La plataforma Java es una tecnología que nos permite ejecutar aplicaciones en múltiples
sistemas operativos. Estas aplicaciones se desarrollan en el lenguaje de programación Java que
posee una máquina virtual que nos permite ejecutar un programa realizado en este lenguaje. Existen
también un conjunto de herramientas conocidas como JDK (Java Development Kit) para el desarrollo
de estas aplicaciones en el lenguaje Java.37
Selenium
La tecnología selenium es un conjunto de herramientas para automatizar páginas en los

navegadores Chrome, Firefox, Safari, entre otros (también a los browsers los llamaremos drivers
cuando los utilicemos junto a web driver).
Tenemos varios componentes que se desprenden de la tecnología selenium, en esta tesina
utilizaremos principalmente Selenium Webdriver junto al lenguaje de programación Java, pero
también los principales usos o herramientas que tiene selenium.
Selenium IDE
Esta herramienta permite, mediante una interfaz gráfica o IDE, automatizar de forma sencilla,
grabando mediante el navegador Firefox, las acciones que se realizan a una página web. La
herramienta Selenium IDE posee un lenguaje llamado Selenese38, que realiza acciones sobre los
37
¿Qué es Java? - Recuperado el 26 de enero de 2022 - Sitio oficial de Java
https://www.java.com/es/about/whatis_java.jsp también se adjunta la documentación de Oracle
(dueño de Java) https://www.oracle.com/java/technologies/javase-documentation.html
38
¿Qué es Selenese? - Recuperado el 26 de enero de 2022 -
https://www.tutorialspoint.com/what-is-selenese

2022
objetos del DOM39 (Document object model o en español Modelo de objetos del documento) de un
sitio web para poder interactuar con los mismos.
Si bien el Selenium IDE es una herramienta muy fácil de usar, ya que graba las acciones que
se realizan en un sitio web, cuando se necesita modificar el código que genera, no es tan robusto
como otro de los componentes de Selenium llamado Webdriver que mencionaremos a continuación.
Figura 10: Se muestra el uso de Selenium IDE con el sitio utilizado para las pruebas de la tesina
Selenium WebDriver
Esta herramienta nos permite automatizar las pruebas realizadas en un navegador de un

sitio web de una forma más robusta y programable. Lo que realizaremos con Webdriver y Java es
desarrollar en esta tesina pruebas automatizadas que simulan las acciones de los usuarios en el
navegador.
Hay múltiples tipos de lenguajes de programación mediante los cuales Webdriver puede
integrarse, algunos de ellos son Python, PHP, C#. En esta tesina sólo utilizaremos el lenguaje de
programación Java.
Se muestra a continuación una imagen que menciona la asociación entre los lenguajes de
programación que se relacionan con Webdriver y con los navegadores.
39
Glosario DOM - Recuperado el 26 de enero de 2022 -
https://developer.mozilla.org/es/docs/Glossary/DOM

2022
Figura 11: Se visualizan a modo ejemplo los 3 componentes para conectar los casos de prueba
(tests en el lenguaje que se desee), selenium (con web driver) y los navegadores (o drivers utilizados
en el framework a crear).40
Selenium Grid
Este componente de Selenium nos permite ejecutar en múltiples servidores, de forma

paralela, las pruebas automatizadas que desarrollemos con la herramienta Selenium Webdriver.
Como referencia se podrían mencionar dos conceptos importantes que son el paralelismo y
la concurrencia, sus definiciones se explican en el Anexo de esta tesina.
En esta tesina no se utilizará la función de Selenium Grid.
Maven
Esta herramienta, también a utilizar en la herramienta 1.0, nos permitirá instalar las
dependencias necesarias para este framework creado. Maven41 permite mediante el lenguaje de
marcas extensibles XML42 instalar y ordenar en Java otros componentes necesarios para la creación
de nuestro framework, como pueden ser TestNG (explicado a continuación) o los drivers de los
navegadores como Chrome o Firefox que utilizaremos.
40
Recuperado el 05 de abril de 2022 -
https://www.dataart.com.ar/news/como-utilizar-selenium-webdriver
41
Sitio oficial de Maven - Recuperado el 05 de abril de 2022 - https://maven.apache.org/
42
Recuperado el 25 de enero del 2022 -
https://developer.mozilla.org/es/docs/Web/XML/XML_introduction

2022
Lo que se realizó con Maven es poder incorporar en el XML (o archivo pom.xml) las
versiones que necesitamos y que se puedan descargar esas dependencias ya mencionadas en el
archivo XML.
Los paquetes disponibles a descargar por Maven se encuentran en el sitio oficial de esta
herramienta.43
Esta herramienta de gestión de dependencias pertenece a la Apache Software Foundation44
y es gratuita. Está basada también en el concepto (patrón) Project Object Model.45
TestNG
La herramienta TestNG46 es un framework qué está basado en Junit47 y que le permite al

desarrollador de pruebas gestionar los casos de prueba de una forma más sencilla y ordenada.
TestNG incorpora dentro de su framework anotaciones que nos permitirán marcar cuáles son casos
de prueba, cuáles son conjuntos de casos de prueba (suites), qué funciones de Java se ejecutan
antes que otras, cuáles funciones se ejecutan después, entre otras funcionalidades.
TestNG trabaja con el lenguaje de programación Java y está orientado para las pruebas que
desarrollamos en esta tesina del tipo funcional, de integración, entre otras.
Framework generado
Si bien ya hemos definido las herramientas o componentes por separado, en este apartado
hablaremos del framework realizado uniendo estas herramientas.
Utilizando un entorno de desarrollo como Eclipse,48 construimos en esta tesina un framework
(herramienta 1.0) que puede realizar pruebas automatizadas de un sistema Web y que también, en
un futuro, ese mismo framework al ser escalable pueda crecer y crear pruebas automatizadas para
Apis.
43
Repositorio del sitio oficial de Maven - Recuperado el 25 de enero del 2022 -
https://mvnrepository.com/
44
Sitio oficial de Apache - Recuperado el 25 de enero del 2022 - https://www.apache.org/
45
Recuperado el 25 de enero del 2022 - https://www.guru99.com/page-object-model
46
Sitio oficial de TestNG - Recuperado el 25 de enero del 2022 - https://testng.org/doc/
47
Sitio oficial de Junit - Recuperado el 25 de enero del 2022 - https://junit.org/junit5/
48
Sitio oficial de Eclipse (IDE de desarrollo) - Recuperado el 25 de enero del 2022 -
https://www.eclipse.org/downloads/

2022
Con Java y Selenium utilizaremos un patrón, que también se explica en el Anexo de esta
tesina, llamado Page Object Model, que es muy utilizado en pruebas de automation para crear un
repositorio de objetos Web con los cuales se puede interactuar para la creación de casos de prueba.
La creación de este framework (herramienta 1.0) es completamente de código abierto y
gratuita, la cual llevó la creación de clases y funciones necesarias para la realización de Test Suites
(o conjuntos de casos de pruebas agrupados con un fin). También este framework nos permite la
ejecución de los casos de prueba por separado o en conjunto (mediante Test Suites).
Se crearon ambientes (o también llamados perfiles) que nos permitieron guardar datos
específicos de un entorno. Para explicar un poco más esto, sería tener distintos ambientes de
pruebas por ejemplo uno de Test y uno de Producción, los cuales tendrán urls distintas que simularán
cómo se crean estos perfiles para las empresas que necesiten utilizarlos. Cambiando estos perfiles
uno puede apuntar un Test Suite a la url o ambiente de producción o a un ambiente de pruebas, sin
tener que modificar los casos de prueba.
ATDD
El desarrollo impulsado por las pruebas de aceptación (ATDD49 Acceptance test–driven

development) es la metodología de trabajo que se implementó para el desarrollo de los casos de
prueba en la herramienta 1.0.
Lo que nos permite esta metodología es el desarrollo de los criterios de aceptación en las
historias a desarrollar por todo el equipo (clientes, desarrolladores, project managers, qa) de
sistemas que vaya a construir un sitio Web y quiera que su calidad sea acorde a lo pedido por el
cliente.
ATDD es un proceso que une el conocimiento de una historia a desarrollar, que posee todo el
equipo, y lo plasma en una historia a través de los casos de prueba (o criterios de aceptación). Estos
criterios de aceptación son los que luego el área de calidad probará en sus casos de prueba. Frente
a algún problema con los mismos, pueden ser modificados, se pueden crear más casos que cubran
el faltante de la historia y luego modificar los casos automatizados asociados a esos casos.
49
Recuperado el 30 de enero de 2022 - https://www.agilealliance.org/glossary/atdd/

2022
Figura 12: Se muestra en la imagen los pasos a realizar con ATDD. Discutir las historias a realizar,
Destilar las pruebas a realizar en un formato compatible, Desarrollar las pruebas, Demo de las
pruebas desarrolladas. 50 51
Adaptabilidad a diferentes entornos: La herramienta 1.0 requiere de conocimientos

previos o buena documentación para ser instalada. Al utilizar herramientas como Java, Selenium,
TestNG y Maven, y al ser todas herramientas gratuitas, esto permite a cualquier desarrollador de
pruebas probar las mismas en la computadora que posee sin tener que incurrir en gastos monetarios
para implementar la herramienta.
Las herramientas que están incluidas en esta tool desarrollada son multiplataforma, por ende
pueden ser instaladas en Windows, Linux o macOS.
50
Recuperado el 05 de abril de 2022 -
https://josepablosarco.wordpress.com/2015/03/31/tdd-vs-bdd-vs-atdd/
51
Recuperado el 11 de mayo de 2022 -
https://www.digite.com/es/agile/el-desarrollo-orientado-a-pruebas

2022
Figura 28: Se muestra Java y Selenium corriendo en un sistema operativo Linux.
Todas las herramientas de desarrollo de Java pueden ser descargadas en cualquiera de los
sistemas operativos mencionados.52
Selenium también es una herramienta multiplataforma que se puede utilizar en todos los
sistemas operativos mencionados que la instalaremos en nuestro proyecto a través de Maven. 53
TestNG es una característica que se le aplica al proyecto de Java para ser utilizado como un
proyecto de pruebas, también es multiplataforma y su instalación al proyecto la haremos a través de
Maven.54
Maven también es multiplataforma y nosotros lo instalaremos a través del Eclipse y luego
crearemos un proyecto en Java de tipo Maven. 55
El esfuerzo en horas hombre para la adaptación de la herramienta depende mucho del
seniority del desarrollador de pruebas, pero hay que considerar que son todas las herramientas
mencionadas utilizadas por una comunidad muy grande en internet y que puede buscarse y
encontrarse mucha documentación fácilmente por internet.
Para la instalación de la herramienta 1.0 no es necesario crear una cuenta personal con un
email válido, como si hay que hacerlo con Katalon.
52
Sitio oficial de descarga de Java -
https://www.oracle.com/java/technologies/downloads/#jdk17-linux
53
Sitio oficial de descarga Selenium - https://www.selenium.dev/downloads/
54
Sitio oficial de descarga TestNG - https://testng.org/doc/download.html
55
Sitio oficial de descarga Maven - https://maven.apache.org/download.cgi

2022
Adaptabilidad a diferentes idiomas: La herramienta 1.0 al ser desarrollada con tools que
son multiplataforma, con una comunidad muy amplia, tools gratuitas y de software libre, permiten
customizar la herramienta 1.0 creada mediante el idioma necesario.
La configuración del idioma a utilizar por ejemplo del Eclipse se puede setear en el mismo
IDE de desarrollo.
El idioma del código desarrollado ya dependerá del definido por el equipo de pruebas ya que
por lo general, y para esta tesina, se desarrolla en Java y TestNG en el idioma inglés, tanto para los
comentarios, para el código de pruebas o para los casos de prueba.
El esfuerzo en horas hombre para la implementación del idioma en la herramienta es bajo ya
que para esta tesina se considera el inglés como el idioma de la herramienta 1.0.
La calidad de los artefactos que componen la herramienta 1.0 está dada por las versiones
liberadas de cada uno de sus componentes (Java, TestNG, Maven, Selenium), los años de
comunidad en internet que poseen las herramientas y otras subcaracterísticas que se mencionan a
continuación:
Cohesividad: Sobre este punto, cada herramienta utilizada es independiente con relación al
resto y cada herramienta tiene su forma de configurarla. En el caso que no queramos utilizar una de
ellas, se puede prescindir de la misma y no utilizarla. Frente a esto se puede modificar la herramienta
1.0 para que sea compatible y para que todo funcione por esta falta de una de las herramientas. Esta
subcaracterística está relacionada con la de Acoplamiento, y dice que un bajo acoplamiento viene
dado por una alta cohesividad, o sea, que los componentes de nuestra herramienta 1.0 sean lo más
independiente de los otros y que no sean dependientes entre sí.
Acoplamiento: La herramienta 1.0 es una tool que posee un bajo acoplamiento de sus
herramientas. Se puede prescindir de alguna de ellas y reemplazarla por otra. Por ejemplo en esta
tesina utilizamos para la herramienta 1.0 TestNG pero podría ser reemplazado por JUnit, esto quiere
decir que posee un bajo acoplamiento.56
56
Recuperado el 06 de enero de 2022 - https://techandsolve.com/alta-cohesion-y-bajo-acoplamiento

2022
Trazabilidad: Los componentes de la herramienta 1.0 pueden ser relacionados de forma

correcta mediante los archivos que se desarrollan en el IDE Eclipse. Por ejemplo Maven posee un
archivo pom.xml donde se cargan las dependencias a utilizar en el proyecto, ejemplo versiones de
selenium o versiones de TestNG. Tanto Java como Eclipse de forma interna relacionan los archivos
según la estructura del proyecto creado desde la sección File de Eclipse, esto lo hace el IDE de
forma interna.
Modularidad: La división de la herramienta 1.0 es alta, esto quiere decir que cada
herramienta es independiente con relación a las otras. Luego de desarrollar esta herramienta 1.0, la
misma se puede desarmar y cambiar sus componentes, por ejemplo reemplazar TestNG por JUnit,
realizar las conexiones correspondientes y continuar automatizando.
Reusabilidad: La reutilización de componentes es alta para esta herramienta. Por ejemplo al

utilizar el patrón page object model (pom), estamos evitando copiar código y volverlo a pegar en otro
caso de prueba. Al implementar POM en esta herramienta se evita repetir código y nos permite
llamar clases o funciones que ya existen y que no hace falta volver a crear.
Existencia de documentación estándar: Todos los componentes utilizados en la

herramienta 1.0 poseen mucha documentación en internet, desde sitios web con ejemplos de cómo
desarrollar la herramienta, pasando por videos explicativos de cómo crear casos de prueba con estos
componentes, entre otras cualidades.
Calidad de código fuente: La calidad del código de la herramienta 1.0 es alta ya que, por
ejemplo utilizando el patrón POM, no se repite código y sólo con llamar ciertas funciones de las
clases se estarían aprovechando las funciones ya creadas en el framework.
Para el desarrollo de la herramienta 1.0 se requieren conocimientos previos en programación

y automatización de pruebas. Si bien hay mucha comunidad de las tools utilizadas en esta
herramienta 1.0 hay que saber qué buscar para el desarrollo de la misma. Los recursos mínimos

2022
para el desarrollo de esta herramienta son un una computadora con cualquier sistema operativo
(Linux, macOS o Windows), una persona que conozca de desarrollo o de pruebas automatizadas,
conocimiento de cómo y qué buscar para comenzar a desarrollar la herramienta.
Eficiencia en la interfaz del usuario: para el desarrollo de la herramienta 1.0 se necesitó de

un seniority ssr como mínimo. El desarrollo de esta herramienta, si bien no es complejo por la
comunidad de internet que existe y que enseña cómo puede desarrollarse este framework, se
necesita de un expertise mayor o igual al de un ssr ya que un junior de automation podría encontrar
algunas dificultades.
La cantidad de horas-hombre utilizadas de un rol ssr para el desarrollo sólo de la herramienta
1.0 es de 10 horas.
Eficiencia en los tiempos de respuesta: el tiempo de respuesta de la herramienta 1.0 es

mínimo ya que al no utilizar una interfaz compleja, sino sólo lo programado en Java, la respuesta es
muy rápida. La herramienta responde con una eficiencia mínima al resto de las herramientas ya que
no posee interfaces por encima del Eclipse que hagan que su respuesta sea más lenta.
Eficiencia en la utilización de memoria interna: se evaluó la memoria utilizada por la

herramienta 1.0 y para el desarrollo de las pruebas utilizadas es eficiente con respecto al resto de las
herramientas analizadas
Memoria interna utilizada para ejecutar la herramienta: Mínimo 300 mb
Eficiencia en la utilización de otro hardware: En esta herramienta 1.0 se utilizó una Asus
Rog Zephyrus G1457 y no hubo otro hardware utilizado. Las pruebas ejecutadas no requieren de otro
hardware externo a utilizar y se ejecutaron de forma eficiente en la computadora mencionada.
Disponibilidad: La herramienta 1.0 utiliza disco y memoria ram de la computadora

mencionada (Asus Rog Zephyrus G14).
Primera instalación: Para realizar la instalación de la herramienta 1.0 hay que comenzar
57
Sitio web oficial - Recuperado el 12 de mayo 2022 -
https://rog.asus.com/ar/laptops/rog-zephyrus/rog-zephyrus-g14-series/

2022
con la descarga e instalación de un entorno de desarrollo (IDE). En esta tesina utilizaremos Eclipse.
Luego tenemos dos opciones en base al estado del proyecto de automation:
1. Si el proyecto de casos de prueba automatizados ya existe, o sea ya fue creado en la
computadora de otro programador, habría que descargar el código desarrollado (o hacer un
pull del repositorio a través de una tecnología llamada git)58 y abrir la carpeta del proyecto a
través del Eclipse.
2. Si el proyecto de casos de prueba no existe, habrá que crearlo a través de la sección en el
Eclipse File->New->Other->Maven Project. Luego hay que instalar las dependencias a utilizar
con Maven, como es el caso de TestNG y los drivers del Selenium. Los drivers de Selenium
son los que nos permiten, al ejecutar pruebas automatizadas, levantar una instancia de un
Navegador (Firefox o Chrome por ejemplo) e interactuar con él y con el sitio web a testear.
Figura 13: Se muestra una imagen del Eclipse IDE59
Este punto a evaluar se realizó a través de encuestas a los tres perfiles de automations
mencionados en la sección de Marco teórico->Proceso de evaluación, por ende la primera instalación
del proyecto depende del expertise del automation, pero cabe destacar que que se necesita
experiencia en programación para realizar esto.
Si bien la comunidad de Java, Selenium, TestNG y Maven es muy amplia, se requiere de
conocimientos como desarrollador para la primera instalación.
58
Git - Sitio oficial - Recuperado el 12 de mayo 2022 -https://git-scm.com/
59
Se obtuvo la imagen del IDE de las herramientas 3.0 y 1.0

2022
Upgrades: Las actualizaciones o upgrades en la herramienta 1.0 se realizan por un lado a

través del archivo pom.xml donde el mismo posee las dependencias necesarias para utilizar el
proyecto. El ide Eclipse, al detectar un cambio en el pom.xml, actualiza las bibliotecas a utilizar por el
proyecto en la carpeta Maven Dependencies desde el repositorio específico indicado en este archivo
de dependencias.
Figura 14: Se muestra captura del archivo pom.xml que utiliza la herramientas 1.0
Dentro de la sección de Help también el IDE Eclipse posee una sección de Eclipse
Marketplace y de Check for Update que permite mantener actualizado el IDE Eclipse.
Para el desarrollo de la herramienta 1.0 se necesita de recursos que tengan un expertise ssr
o más. Para el desarrollo de sus pruebas no es necesario que el seniority sea elevado, siempre y
cuando se tenga a quien consultar o el junior pueda consultar en la comunidad de internet que es
amplia. La facilidad de uso para la herramienta 1.0 es de nivel medio con respecto al resto de las
herramientas.
Confort físico: Tanto Eclipse, Java o TestNG son las herramientas de automation más

2022
utilizadas para la automatización de sitios Web. El grado de comodidad para los programadores de
pruebas es alto.
Figura 15: Se muestra un caso de prueba de la herramienta 1.0 (puede leerse en la imagen la
mención a TestNG).
En el acceso a las funciones: El acceso a las funciones mediante la herramienta 1.0 es

alto. Se puede acceder fácilmente a través del Eclipse a todas las clases creadas, todas las carpetas
o documentos desde la sección Package Explorer, entre otras cosas. El Eclipse nos da una facilidad
alta de acceso a todo lo desarrollado y las bibliotecas que se utilizan. Cualquier programador de
pruebas puede acceder fácilmente a todos los archivos que posee la herramienta 1.0.
En la comprensión de las salidas del sistema: la herramienta 1.0 utiliza, a través del
Eclipse, la sección de output Problems o Console que proveen los resultados, errores o información
necesaria para comprender los problemas o resultados de la ejecución de las pruebas
automatizadas.
En la estética: Al utilizar Eclipse, que es uno de los entornos de desarrollo más utilizados
para las pruebas, la herramienta 1.0 provee una interfaz que se actualiza con las versiones de
Eclipse que se van liberando.

2022
En el conocimiento del sistema: Ya que la herramienta 1.0 es desarrollada desde cero por
los desarrolladores de pruebas, el conocimiento del sistema tiene que ser total. Si bien los
automation juniors pueden no necesitar conocer todas las integraciones de la herramienta 1.0,
pueden hacerlo ya que el código de la herramienta 1.0 es visible por todo desarrollador de pruebas
que lo utilice (o sea no tiene funciones propietarias como si Katalon).
Satisfacción total: El grado de satisfacción de la herramienta 1.0 es alto ya que se puede

customizar al gusto del equipo de automation que desarrolla y utiliza la herramienta.
La herramienta 1.0 posee una facilidad alta para desempeñar las pruebas automatizadas de
una forma eficiente. Las tools como Java, TestNG, Selenium, Eclipse poseen mucha comunidad y
permiten una versatilidad y escalabilidad que los programadores de pruebas necesitan, tanto para
pruebas de sistemas web como de otro tipo.
En el aprendizaje: Si bien para un seniority junior no es tan fácil su aprendizaje ya que tiene
que poseer varios conceptos de programación, para un ssr o sr, con toda la comunidad que existe en
el internet, suele ser un aprendizaje rápido el que suele ocurrir. Para los juniors mientras estén
guiados por líderes de automation o líderes técnicos, será cada vez más fácil su aprendizaje.
En la coherencia de la IU: Sobre la cantidad de interfaces son varias, las categorizamos

como altas, pero una vez aprendido el uso de la herramienta 1.0, es sólo saber dónde están las
clases, cómo están ordenadas, como ver los casos de prueba, donde se guardan los archivos,
conocer los outputs de la herramienta y listo, cualquier rol puede ya saber cómo desarrollar pruebas
automatizadas.
Al no ser una herramienta altamente acoplada, las interfaces (o accesos) a los componentes
de la herramienta 1.0 para utilizar el framework son varios, pero esto no quiere decir que sean
complejos, basta con saber de programación e ir entendiendo el formato del Eclipse para poder
desarrollar pruebas automatizadas y ejecutarlas.
En la entrada manual de información: Si bien la herramienta 1.0 posee varias secciones

(que provee el Eclipse) para la ejecución de casos de prueba automatizados, la herramienta puede

2022
adecuarse a los shortcuts que el programador necesite para ejecutar casos de prueba, regresiones y
realizar otras funciones que le sean necesarias.
En el acceso a las funciones: La velocidad del acceso a las funciones de la herramienta 1.0
es rápida, no se requiere de mucho software o hardware para su uso. Al ser una herramienta hecha
desde cero se la puede customizar para que sea lo más eficiente posible.
En lo legal: El grado de legalidad de la herramienta 1.0 es alto ya que todas las tools son de
licencia libre y no hay componentes propietarios.
Efectividad del Help: La herramienta 1.0 posee mediante el Eclipse la sección de ayuda,
también la comunidad en internet de todas las tools que componen esta herramienta proveen la
ayuda necesaria para el desarrollo y mantenimiento de la misma.
Figura 16: Se muestra la sección del Eclipse “Help” que utiliza tanto la herramienta 1.0 como la 3.0.
Katalon

2022
Katalon60 (o Katalon Studio) es una herramienta para la automatización de pruebas tanto

para sitios Web, pruebas de API’s, pruebas Mobile o aplicaciones de escritorio.
Utilizaremos a partir de ahora el alias “herramienta 2.0” para referenciar a la misma.
Si bien es una herramienta propietaria posee su licencia gratuita para que pueda ser utilizada
por desarrolladores de pruebas.
La herramienta Katalon es una aplicación instalable o también ejecutable que posee una
buena interfaz para realizar las automatizaciones necesarias según el tipo de pruebas a realizar (API,
Web, entre otras).
Figura 17: Se muestra una captura de la herramienta 2.0 en la sección de Test Suite con 3 casos de
prueba de ejemplo.
Katalon Studio también utiliza el patrón Page Object Model (POM) pero a diferencia de Java
y Selenium ya viene este patrón integrado en la misma aplicación ejecutable que nos provee Katalon.
60
Sitio oficial de Katalon - Recuperado el 12 de mayo 2022 - https://www.katalon.com/

2022
Figura 18: Se muestra un objeto (utilizando de forma interna por Katalon el patrón POM) obteniendo
el mismo mediante XPath.61
Katalon utiliza los perfiles (que en Java y Selenium los llamamos ambientes) que nos
permiten encapsular variables o por ejemplo urls específicas de ese perfil (o ambiente). Con esto
podremos apuntar una Test Suite hacia un perfil de Test o uno de Producción sin tener que modificar
los casos de prueba o los Test Suites.
Al utilizar esta herramienta no necesitamos utilizar un entorno de desarrollo ya que Katalon
provee su propio ambiente de trabajo, o sea, es una aplicación ya compilada y que mediante un
ejecutable nos permite utilizar sus componentes para nuestras pruebas automatizadas sin tener que
realizar mucha interacción con código pero sí de forma manual y configurable por cada usuario.
Katalon Studio soporta tanto Selenium para la automatización Web como Appium62 para la
automatización de pruebas de Mobile. Para las pruebas de Apis posee un framework propio
incorporado en la misma aplicación de Katalon.
Lo que nos permite Katalon es introducir a los interesados, que pueden ser QA’s manuales,
analistas funcionales, entre otros, al mundo de las pruebas automatizadas. Permite que personas no
entrenadas en la programación puedan realizar pruebas automatizadas mediante su fácil interfaz
manual, que por detrás posee código en el lenguaje Groovy y Java que se puede modificar para
realizar pruebas automatizadas más robustas que las desarrolladas en Katalon Studio de forma
manual.
61
En este caso se obtiene un objeto en el DOM que contiene el texto “Servicios”
62
Sitio oficial de Appium - Recuperado el 12 de mayo de 2022 - https://appium.io/

2022
En las empresas, Katalon permite que los automation JR’s se introduzcan al mundo de
programación con un IDE que provee una interfaz sencilla y práctica para desarrollar los primeros
casos de prueba automatizados. Para los expertos en programación Katalon no provee del todo un
entorno cómodo de trabajo ya que un Qa automation SR preferirá desarrollar y modificar las pruebas
automatizadas como el mismo necesite sin usar la interfaz manual de Katalon que puede generar
algunas trabas cuando se necesita mayor robustez en los casos.
Groovy
La herramienta Katalon utiliza dos lenguajes para el desarrollo del código de los casos de
prueba. Por un lado tenemos a Groovy63 que es un lenguaje orientado a objetos que está basado en
Java. Groovy también tiene influencias de programación de los lenguajes Python, Smalltalk y Ruby,
lo que hace que un programador pueda utilizar ciertas sintaxis de los lenguajes mencionados y
programar lo que se necesite.
La primera versión de Groovy se desarrolló el 2 de enero de 2007 y luego fue creciendo su
comunidad. La documentación de este lenguaje se encuentra en el sitio oficial y cada vez tiene más
soporte. Lo bueno de este lenguaje, es que cuando se necesita utilizar la sintaxis de Java, que posee
mucha comunidad, se puede hacer y se puede aprovechar toda la comunidad de lo desarrollado en
Java.64
El código de Groovy se utiliza para mejorar los casos de prueba desarrollados de forma
manual en la herramienta 2.0. Esto es porque al desarrollar casos de prueba, Katalon permite dos
formas de hacerlo. Una de ellas es la forma manual y otra la forma automatizada, o sea a través de
código en Groovy en la solapa Script para aumentar la robustez de los casos desarrollados.
Katalon TestOps
Esta solución que provee Katalon, llamada Katalon TestOps,65 se utiliza para realizar la
integración continua o deploy continuo (CI/CD) ejecutando los casos de prueba automatizados
desarrollados en Katalon Studio.
63
Sitio oficial de Groovy - Recuperado el 12 de mayo 2022 - http://groovy-lang.org
64
Sitio de documentación oficial de Groovy - Recuperado el 12 de mayo 2022 -
https://groovy-lang.org/single-page-documentation.html
65
Sitio oficial de Katalon TestOps - Recuperado el 12 de mayo 2022 -
https://www.katalon.com/testops/

2022
La herramienta ofrece gráficos de calidad e informes sobre las ejecuciones realizadas de las
pruebas. Permite configurar alertas en base a la cantidad de casos de prueba que no fueron exitosos
para que se puedan tomar acciones frente a esto.
Esta herramienta permite también integrarse con otras tools de automation y de reportes.
Mencionamos esta herramienta sólo para mencionar los conceptos de integración continua o
deploy continuo, aunque no se desarrollaron pruebas sobre Katalon TestOps.
Katalon Recorder
Esta herramienta es una extensión que permite grabar y reproducir en los navegadores
Chrome, Firefox y Edge casos de prueba para luego importar en Katalon Studio.
Katalon Studio posee también una función de grabación de casos que es más potente que
Katalon Recorder66.
Figura 29: Se muestra el recording de Katalon obteniendo un texto de la página de pruebas utilizada.
66
Sitio oficial de Katalon Recorder - Recuperado el 12 de mayo 2022 -
https://www.katalon.com/katalon-recorder-ide/

2022
Katalium
Katalium67 es un framework que utiliza por detrás Selenium y TestNG, es la solución de

Katalon para el uso de las herramientas Selenium y TestNG.
Framework generado
Al utilizar Katalon, no hay un framework a desarrollar, esto es porque la herramienta en sí es

un IDE que posee su propio framework. Katalon está basado en Eclipse, y permite a los
desarrolladores de pruebas descargar la herramienta 2.0 y ya utilizarla sin necesidad de
configuraciones a realizar.
Adaptabilidad a diferentes entornos: La herramienta 2.0 permite, según el sitio oficial de

Katalon, utilizar e instalar la misma en Windows, macOS y Linux. Según mi experiencia trabajando en
empresas con esta tool las versiones más estables son con el sistema operativo Windows. Las
pruebas realizadas en macOS y Linux eran bastante inestables para versiones anteriores a la 8.0.0.
Al ser una herramienta relativamente nueva se va incorporando al mercado de la
multiplataforma pero en este punto aún tiene que realizar mejoras.68
En cuanto al tiempo de instalación en Windows es muy rápido y no genera más
inconvenientes que el tener una cuenta con un email válido en el sitio oficial de Katalon.
Adaptabilidad a diferentes idiomas: La interfaz para modificar el idioma en Katalon está

basada en Eclipse, por ende es muy similar el cambio de idioma.
El código desarrollado para esta tesina es en inglés como también lo son los casos de
prueba o los comentarios en los scripts.
El valor monetario que se necesita para la adaptación de la herramienta 2.0 también es bajo
67
Sitio oficial de Katalium - Recuperado el 12 de mayo 2022 -
https://www.katalon.com/resources-center/blog/katalium-introduction/
68
Estos párrafos anteriores son basados en mi experiencia trabajada con esta herramienta y como
QA - https://www.linkedin.com/in/yamil-currao/

2022
ya que se implementó el nivel inglés para esta tesina.
que se ofrecen mediante el producto Katalon Studio. La primera versión de Katalon fue liberada en el
año 2015, y por ende, no posee una comunidad en internet tan amplia como la herramienta 1.0. A
continuación se explican las subcaracterísticas de la calidad de los artefactos:
Cohesividad: Sobre este punto, al ser Katalon Studio una única herramienta, su cohesividad
es baja, por ende su acoplamiento es alto. Si bien la herramienta 2.0 posee por dentro Selenium,
Java y se basa en el IDE Eclipse, no se puede desarmar la misma para utilizar algunas de estas
opciones ya que viene todo integrado en lo que otorga el producto de Katalon Studio.
Acoplamiento: La herramienta 2.0 posee un alto acoplamiento de sus herramientas internas

(llamamos así a las tools que vienen integradas en el software de Katalon y que no se pueden
modificar). No se puede desarmar Katalon ya que su software es propietario.
Trazabilidad: Los componentes de la herramienta 2.0 se relacionan mediante la lógica que

posee Katalon, o sea, vincula los casos de prueba según las carpetas donde están alojados y lo
mismo hace con los scripts de código en Groovy que están relacionados con los casos de prueba. La
trazabilidad en Katalon se maneja de forma interna mediante la propia herramienta y el usuario de la
misma no tiene que preocuparse por el desarrollo de clases u otras funciones relacionadas a esta
trazabilidad.
Modularidad: La división de la herramienta 2.0 es baja. Katalon Studio no permite separar

los componentes y reemplazarlos por otros, por ejemplo, si queremos que el lenguaje de
programación a utilizar no sea Java tendríamos que cambiar toda la herramienta 2.0 por otra opción
ya que viene todo integrado en la solución que Katalon nos provee.
Reusabilidad: Katalon utiliza el patrón Page Object Model (POM) y por ende la reutilización
de código es alta. Katalon permite desarrollar y gestionar los casos de prueba heredando por cada
uno de ellos las librerías que nos permiten interactuar con los objetos de una Web de forma
automática y sin tener que copiar código ya que lo hace de forma interna el mismo IDE de Katalon.

2022
Existencia de documentación estándar: La documentación de Katalon se encuentra en su

sitio web y en internet pero no es tan amplia como la utilizada en Selenium y Java. Si bien Katalon
utiliza estas tecnologías lo hace mediante su propio código embebido en la herramienta Katalon
Studio y hay que adaptar lo que se necesita hacer de la forma que Katalon lo acepte.
Calidad de código fuente: La calidad del código de la herramienta 2.0 es media ya que, por
ejemplo utilizando el patrón POM, no se repite código pero hay que adaptar lo que uno necesita
desarrollar al IDE que provee Katalon y eso no permite tanta customización como si lo hacen otras
herramientas.
Figura 19: Se muestra el lenguaje que utiliza Katalon (Groovy) con sus librerías y cómo se las llama.
Para el desarrollo de la herramienta 2.0 no se requieren conocimientos previos en

automatización de pruebas. Si bien la comunidad de Katalon es cada vez mayor, no alcanza a la
cantidad de años que poseen otras herramientas que compiten con ella. Los recursos mínimos para
comenzar con las pruebas automatizadas utilizando esta herramienta son un una computadora con
cualquier sistema operativo (Linux, macOS69 o Windows), una persona que conozca sobre QA
(puede ser QA manual), algún conocimiento previo de cómo y qué buscar para comenzar a
desarrollar en la herramienta.
Eficiencia en la interfaz del usuario: para realizar las pruebas en la herramienta 2.0 basta
con un seniority junior. Para el desarrollo de casos de prueba manuales en esta herramienta, sólo se
necesita conocer de QA. Pero para el desarrollo de casos de prueba automatizados con Katalon sí
se necesita de un expertise ssr o mayor.
69
Experiencia propia en macOS utilizando Katalon: No rinde tanto como en Windows.

2022
La cantidad de horas-hombre utilizadas de un rol ssr para el desarrollo de casos de prueba

manuales en esta herramienta es de 2 horas para un junior. Pero para el desarrollo de casos de
prueba automatizados es de 10 horas aproximadamente para un ssr.

por defecto mayor al de las herramientas 1.0 y 3.0 ya que por dentro Katalon utiliza todas las tools
que las herramientas 1.0 y 3.0 utilizan. Por ejemplo, Katalon está desarrollado utilizando un Eclipse
por detrás, también utiliza Java y Groovy lo cual lo hace más pesado que el resto de herramientas.

herramienta 2.0 y para el desarrollo de las pruebas utilizadas utiliza más memoria ram que el resto
de las herramientas analizadas.
Memoria interna utilizada para ejecutar la herramienta: Mínimo 1000 mb (Casi 1 GB para
utilizar Katalon).
Eficiencia en la utilización de otro hardware: En esta herramienta 2.0 se utilizó una Asus
Rog Zephyrus G1470 y no hubo otro hardware utilizado. No se requiere de otro hardware externo a
utilizar.

mencionada (Asus Rog Zephyrus G14).
Primera instalación: En Katalon la primer instalación es muy simple, sólo basta con ingresar
en la siguiente url:
https://www.katalon.com/
Allí se tendrá que ingresar a la sección de Start for Free e, ingresando el email de uno, se
podrá descargar, para el sistema operativo necesario, la aplicación Katalon. A continuación se
muestra la ruta donde se posee el ejecutable en el sistema operativo Windows:
70
Sitio web oficial - Recuperado el 16 de mayo 2022 -

2022
Figura 20: Se muestran los archivos que contiene el .zip que se descarga para la instalación de
Katalon.
Al hacer click en el ejecutable de Windows, ya se procede a la siguiente sección donde uno

tiene que ingresar las credenciales que utilizó para el registro en el sitio web oficial de Katalon para
utilizar la versión de prueba:

2022
Figura 21: Se muestra el acceso que se requiere en Katalon (herramienta 2.0) y que no es necesario
en las herramientas 1.0 o 3.0.
Luego de esto ya se puede continuar con el uso de la aplicación y comenzar a desarrollar un

nuevo proyecto de automation desde cero.
Upgrades: El upgrade de la herramienta 2.0 permite al iniciar la aplicación descargar una

nueva versión de Katalon como se muestra a continuación:
Figura 22: Se muestra el asistente de instalación de actualizaciones de Katalon.

2022
Katalon también permite realizar actualizaciones a través de la sección Help mediante la

opción Check for updates, esto se utiliza cuando no se cierra la aplicación por parte del desarrollador
durante un tiempo y él mismo quiere descargar la versión más reciente de la herramienta Katalon.
Para el uso de la herramienta 2.0 con personal que tenga un expertise junior se puede
comenzar a realizar las pruebas manuales en la herramienta Katalon. Para el desarrollo de las
pruebas automatizadas si se necesitan ya perfiles ssr o más. La facilidad de uso para la herramienta
2.0 es de nivel alto para las pruebas manuales y medio para las automatizadas.
Confort físico: La herramienta Katalon posee una interfaz cómoda para las pruebas
manuales aunque no tanto para las automatizadas. Si bien utiliza Java y Groovy para el desarrollo de
las pruebas automatizadas, la organización del código depende mucho del IDE de Katalon y hay que
utilizar sus bibliotecas o crear por separado bibliotecas propias en Java que resuelvan lo que no
resuelve Katalon. En una de las empresas en la que trabajé el uso de Katalon no fue suficiente y
hubo que crear bibliotecas de ayuda en Java para el complemento de las pruebas de automation.
En el acceso a las funciones: El acceso a las funciones de Katalon es nivel medio. Se

puede acceder fácilmente a todo lo que provee como interfaz Katalon, pero no tanto a las funciones
en Java que soportan la herramienta o que están compiladas y que utiliza por detrás Katalon. Al ser
un software encapsulado no se puede analizar cada función en específico y desarmar y rearmar la
herramienta 2.0.
En la comprensión de las salidas del sistema: la herramienta 2.0 utiliza las secciones de
output Problems o Console que proveen los resultados, errores o información necesaria. Estas
secciones son las mismas que posee Eclipse ya que Katalon está basado en esta herramienta.
En la estética: Si bien Katalon utiliza Eclipse, la interfaz que utiliza y sus versiones son
propias de Katalon. Lo ideal es mantener el código actualizado según la última versión de Katalon ya
que es una herramienta llevando a un alto acoplamiento y una baja cohesión (recordemos que la
herramienta 2.0 es una opción con todo integrado por la empresa misma y no se la puede modificar a
gusto del desarrollador).

2022
En el conocimiento del sistema: Al ser la herramienta 2.0 desarrollada como un

componente único por la empresa Katalon, es más difícil conocer las funciones de toda la
herramienta. Lo que facilita Katalon es un IDE específico apuntado al desarrollo de pruebas
manuales, pero no en sí al conocimiento de todas las funciones del framework utilizado.
Satisfacción total: El grado de satisfacción de la herramienta 2.0 es alto para un automation

junior pero medio o bajo para un ssr o sr ya que para estos últimos roles el modificar la herramienta a
gusto del programador es fundamental para escalar la misma a las necesidades de los sistemas a
probar.
La herramienta 2.0 posee una facilidad alta para el desarrollo de pruebas manuales y otro
tanto menor para el desarrollo de pruebas automatizadas. Katalon es una herramienta que ha ido
creciendo en el último tiempo y así también su comunidad. Si bien no es tan versátil como un
desarrollador pueda requerir, permite realizar pruebas de sistemas web como también de servicios,
entre otras cosas.
En el aprendizaje: Para un seniority junior es fácil su aprendizaje ya que su interfaz es

simple de entender (Katalon está orientado a la gestión de casos de pruebas). Para el desarrollo de
pruebas automatizadas, si bien no es complejo su aprendizaje, hay que readaptar lo aprendido en
programación a como lo requiere Katalon, ya que al ser una herramienta propietaria, no todo se
puede hacer con Java y se requiere adaptarse a cómo la misma permite realizar las pruebas a
automatizadas.
En la coherencia de la IU: La cantidad de interfaces en Katalon se reducen cuando se

realizan casos de pruebas manuales. Cuando los casos de prueba son automatizados, ya empiezan
a complejizarse las interfaces. La herramienta 2.0 es altamente acoplada ya que sus interfaces (o
accesos) a los componentes están embebidos (la mayoría) en Katalon Studio.
En la entrada manual de información: La herramienta 2.0 posee una interfaz más sencilla
para la gestión de casos de prueba, por ende, para ejecutar un caso de prueba o un conjunto de
casos la entrada de información es más baja. Katalon Studio posee relaciones de datos para poder

2022
conectar las pruebas con bases de datos a través de consultas a las mismas y de esta forma
simplificar la entrada de información a las pruebas.
es media, al poseer por detrás un Eclipse y Java, se ralentiza el acceso a las funciones de Katalon.
En lo legal: El grado de legalidad de la herramienta 2.0 es alto siempre y cuando se utilice la

versión gratuita (que es más limitada, sin permitir integraciones de deploy continuo, entre otras
cosas) o la versión paga.
Efectividad del Help: La herramienta 2.0 posee la sección de ayuda aunque es más limitada
que la que provee Eclipse. La comunidad en internet está en crecimiento pero aún le falta camino por
recorrer para mejorar.
Figura 23: Se muestra la sección “Help” de la herramienta 2.0 (Se puede ver que es menos llamativa
que la de la sección “Help” de Eclipse)

2022
Cucumber
Cucumber es una herramienta de desarrollo de casos de prueba que utiliza el desarrollo

guiado por el comportamiento (o BDD por behavior-driven development).71 Este método de desarrollo
de pruebas, el BDD, permite definir comportamientos realistas para los usuarios.
Este desarrollo basado en el comportamiento introduce un nuevo concepto no hablado hasta
el momento en esta tesina. Nos permitirá traducir las descripciones funcionales qué podría crear un
analista funcional, un interesado de producto, un project manager, un analista de calidad, entre
otros.
Utilizaremos a partir de ahora el alias “herramienta 3.0” para referenciar a la misma.
Gherkin
El lenguaje que se utiliza para el desarrollo de estos casos de prueba es Gherkin72, el mismo
permite, mediante el lenguaje natural, realizar casos de pruebas para escribir escenarios de los
comportamientos de los usuarios.
La principal idea de Cucumber y Gherkin es que todos los interesados puedan escribir los
casos de prueba que luego serán traducidos al lenguaje de programación necesario, en nuestro
caso, fueron traducidos a Java y Junit.
El foco de la herramienta 3.0 es poder desarrollar los casos de prueba como el cliente o
usuario final necesita, y no sólo desde el punto de vista de desarrolladores de pruebas.
Gherkin utiliza principalmente un archivo llamado .feature73 en el cual se deben definir los
siguientes comandos:
● Feature: Es el nombre de la función a probar, sería el nombre del caso de prueba.

● Scenario: Es el escenario de la función a probar, se podría utilizar como una descripción de
lo que realiza el usuario.
● Given: Son las precondiciones de los casos de prueba
● When: Son las acciones a desarrollar cuando se cumpla la precondición de Given
71
Recuperado el 02 de enero de 2022 - https://www.tecnova.cl/2021/10/06/bdd
72
Sitio oficial de Gerkin - Recuperado el 02 de enero 2022 - https://cucumber.io/docs/gherkin/
73
Recuperado el 30 de enero de 2022 - https://docs.behat.org/en/v2.5/guides/1.gherkin.html

2022
● Then: Son los resultados que se validarán en las pruebas desarrolladas.
Figura 24: Se muestra la sintaxis utilizada en la herramienta 3.0 para un caso de prueba realizado.
Junit
La herramienta JUnit74 es una tool desarrollada para realizar las pruebas unitarias por parte
de los desarrolladores.
Como ya mencionamos anteriormente TestNG, que es el framework utilizado en la
herramienta 1.0, se basó en JUnit para su desarrollo.
En esta herramienta 3.0 se utilizó JUnit para el desarrollo de pruebas a desarrollar.
Maven
Como ya se mencionó en la herramienta 1.0, aquí también utilizaremos como orquestador

de dependencias la herramienta Maven.
Selenium
Esta herramienta 3.0 también utilizará Selenium para el desarrollo de sus pruebas.
74
Sitio oficial de JUnit - Recuperado el 12 de mayo 2022 - https://junit.org/junit5/

2022
BDD
Como ya fue mencionado, el desarrollo guiado por el comportamiento es el método que se

escogió para el desarrollo de los casos de prueba de la herramienta 3.0.
Lo que nos permite esta metodología es describir qué es lo que el usuario final desea de la
aplicación Web a desarrollar y testear.
Esta metodología es similar a la mencionada ATDD de la herramienta 1.0, pero la ATDD se
extiende más allá de lo que el usuario final desea, sino de lo que todo el equipo planificó y acordó
hacer.
Figura 30: Se muestra con un ejemplo que el TDD está orientado a un comportamiento de un
usuario final más específico que BDD.
Framework generado

2022
La herramienta 3.0 que se realizó en esta tesina también utilizará el lenguaje de

programación Java, la herramienta Maven y en vez de utilizar TestNG utilizaremos Junit.
Cucumber también tiene integración con otros lenguajes como Ruby, Scala y Groovy, pero
nosotros utilizamos en esta tesina el lenguaje Java. Para crear este framework el entorno de
desarrollo, o IDE utilizado, fue Eclipse.
El framework desarrollado tiene una similitud al que se desarrolló para Java y Selenium
(herramienta 1.0), por ende la dificultad para los usuarios estará también basada en el marco de
trabajo que se construya con las herramientas Cucumber, Java y Junit.
Adaptabilidad a diferentes entornos: La herramienta 3.0 posee todas sus tools multi
plataforma. El lenguaje Cucumber se puede instalar a través del Eclipse y puede ser implementado
en Windows, macOS y Linux.
Tanto Java, JUnit o Maven son de código abierto y son herramientas gratuitas que también
son multiplataforma.
El esfuerzo en horas hombre de la herramienta 3.0 para su instalación en diferentes entornos
es bajo ya que con el ide Eclipse y las dependencias de Maven, su instalación es muy similar y casi
la misma para todas las plataformas.
El valor monetario es nulo ya que son herramientas de uso gratuito.
Adaptabilidad a diferentes idiomas: En esta tesina se desarrolló la herramienta 3.0 en el

idioma inglés. Si es necesario modificar el IDE Eclipse también se puede hacer, pero todo el código
desarrollado, comentarios, casos de prueba, fueron realizados en inglés.
El tiempo necesario para la adaptación es nulo ya que la herramienta siempre se utilizará en
inglés en el sistema operativo que se necesite.
El valor monetario es nulo ya que se realizó con tools gratuitas.
liberadas de cada uno de sus componentes (Java, JUnit, Maven, Selenium y Cucumber). Esto es

2022
similar a lo ya mencionado en la herramienta 1.0 ya que es un framework muy similar pero que
dentro posee otras tools a utilizar. Se menciona a continuación el detalle de las subcaracterísticas:
Cohesividad: Cada tool utilizada en la herramienta 3.0 es independiente al resto. En esta

herramienta podríamos, por ejemplo, reemplazar JUnit por TestNG y seguir utilizando la misma.
También se podría modificar el gestor de dependencias (Maven) y utilizar otro. La cohesividad en
esta herramienta es alta y por ende su acoplamiento es bajo.
Acoplamiento: La herramienta 3.0 posee un bajo acoplamiento. Como ya fue mencionado

en la subcaracterística de Cohesividad, se pueden cambiar las tools que la componen sin afectar al
framework desarrollado.
Trazabilidad: Los componentes de la herramienta 3.0, como se mencionó en la herramienta

1.0, pueden ser vinculados de forma correcta al crear su framework. Por ejemplo, al utilizar Maven,
se puede trazar las herramientas o componentes que debe descargar el IDE Eclipse mediante el
archivo de trazabilidad POM.
Modularidad: La división de la herramienta 3.0 es alta. Cada tool utilizada en este framework
es independiente y se puede modificar por separado sin tener que realizar cambios en todos sus
componentes.
Reusabilidad: Esta herramienta 3.0 también reutiliza sus componentes utilizando el patrón
page object model.
Existencia de documentación estándar: Todos los componentes utilizados en la

herramienta 3.0 poseen mucha documentación en internet.
Calidad de código fuente: La calidad del código utilizado en esta herramienta es también
alta como en lo mencionado en la herramienta 1.0. Al no reutilizar código, ya que se utiliza el patrón
POM, se estarían aprovechando las funciones ya existentes para el desarrollo de las pruebas
automatizadas.

2022
Figura 25: Se muestra el código fuente en Java de la herramienta 3.0 para un caso de prueba.
Para el desarrollo de la herramienta 3.0 se requieren conocimientos previos en programación

y automatización de pruebas. Esta herramienta es muy similar a la herramienta 1.0 pero con otras
tools que la componen y por ende otras características. Para el desarrollo de la herramienta 3.0 hay
mucha comunidad ya que utiliza también Java y JUnit, pero al ser Cucumber una tool más nueva75 y
con su sintaxis específica, todo el framework se complejiza un poco más. Los recursos mínimos son
los mismos que en la herramienta 1.0, sistemas operativos (Linux, macOS o Windows) y con una
persona que conozca de desarrollo o de pruebas automatizadas para comenzar a desarrollar la
herramienta es suficiente.
Eficiencia en la interfaz del usuario: para el desarrollo de la herramienta 3.0 se necesitó de

un seniority ssr como mínimo. El desarrollo de esta herramienta, si bien no es complejo por la
comunidad de internet que existe, se necesita también de un expertise mayor o igual al de un ssr
(muy similar a lo mencionado para la herramienta 1.0).
La cantidad de horas-hombre utilizadas de un rol ssr para el desarrollo sólo de la herramienta
75
Sitio Github de releases de Cucumber - Recuperado el 02 de enero 2022 -
https://github.com/cucumber/cucumber-ruby/releases

2022
1.0 es de 12 horas.

bajo ya que al no utilizar una interfaz compleja, sólo lo programado en Java, la respuesta es rápida.

herramienta 3.0 y es similar al utilizado por la herramienta 1.0.
Memoria interna utilizada para ejecutar la herramienta: Mínimo 300 mb de ram.
Figura 26: Se muestra la memoria utilizada como mínimo de la herramienta 3.0
Eficiencia en la utilización de otro hardware: se utilizó también una Asus Rog Zephyrus
G1476 y no hubo otro hardware utilizado.

mencionada.
Primera instalación
76
Sitio web oficial - https://rog.asus.com/ar/laptops/rog-zephyrus/rog-zephyrus-g14-series/

2022
Para realizar la instalación de la herramienta 3.0 comenzaremos con la descarga del IDE
Eclipse. Utilizaremos el mismo entorno de desarrollo que el utilizado en la herramienta 1.0. Si el
proyecto de casos de prueba automatizados ya existe, descargamos el código (hacer un pull en git)
del repositorio y abrimos la carpeta del proyecto en el Eclipse.
Si el proyecto de casos de prueba no existe, lo crearemos a través de la creación de un
nuevo proyecto en el Eclipse mediante la ruta File->New->Other->Maven Project.
Instalaremos las dependencias a través de Maven, de las tools JUnit y los drivers del
Selenium.
Si bien la comunidad de Java, Selenium, JUnit, Cucumber y Maven es muy amplia, se
requiere de conocimientos como automation para la instalación de este framework.
Upgrades
Las actualizaciones o upgrades en la herramienta 3.0 se asemejan a las de la herramienta

1.0. A través del archivo pom.xml agregaremos las dependencias necesarias del proyecto y el
Eclipse actualizará las bibliotecas del proyecto.
En la sección Help tenemos el Eclipse Marketplace y el Check for Update para actualizar el
entorno de desarrollo.
Figura 31: Se muestra el archivo pom.xml con las dependencias de Cucumber, JUnit y Selenium.

2022
Para el desarrollo de la herramienta 3.0 se necesita de recursos que tengan un expertise ssr
o más. Esto es similar a lo mencionado en la herramienta 1.0 ya que este framework también
requiere de la conexión de todas las tools a utilizar.
Confort físico: Tanto Eclipse y Java son las herramientas de automation más utilizadas para
la automatización de sitios Web, pero también lo es y JUnit (aunque no sólo para pruebas
automatizadas). Si bien Cucumber está involucrándose cada vez más en las pruebas automatizadas,
no es de las más utilizadas por los programadores de pruebas.
En el acceso a las funciones: El acceso a las funciones mediante la herramienta 3.0 es

alto. Como se mencionó con la herramienta 1.0, al ser configurable y armada por los mismos
desarrolladores en su totalidad, se puede acceder, modificar y eliminar todo lo que uno desee,
también acceder a funciones desarrolladas en el framework como uno desee.
En la comprensión de las salidas del sistema: la herramienta 3.0 a través del Eclipse
también utiliza la sección de output Problems o Console que proveen los resultados necesarios para
el desarrollo de las pruebas.
En la estética: Al utilizar Eclipse, la herramienta 3.0 provee una interfaz que se actualiza con
nuevas versiones que hacen ameno al uso de la misma.
En el conocimiento del sistema: La herramienta 3.0 es desarrollada desde cero por los
desarrolladores de pruebas, por ende, el conocimiento del sistema es total o se puede obtener
analizando la herramienta.
Satisfacción total: El grado de satisfacción de la herramienta 3.0 es alto ya que se puede

customizar al gusto del equipo de automation que desarrolla y utiliza la herramienta.

2022
La herramienta 3.0 permite desempeñar las pruebas automatizadas de una forma eficiente.
Las tools como Java, JUnit, Selenium, Eclipse poseen mucha comunidad. Si bien Cucumber es una
tool más nueva se integra correctamente con las mencionadas y permite escalabilidad que los
programadores de pruebas necesitan.
En el aprendizaje: Para un seniority junior no es tan fácil su aprendizaje pero para un ssr o
sr si lo es. Las tools de la herramienta 3.0 poseen mucha comunidad y esto hace que su aprendizaje
sea rápido.
En la coherencia de la IU: La cantidad de interfaces para la herramienta 3.0 es alta, pero

una vez que los desarrolladores de pruebas aprenden las mismas se pueden utilizar con alta
comodidad.
En la entrada manual de información: La herramienta 3.0 permite como la 1.0 la

configuración de la entrada de información tanto como se desee ya que es una herramienta creada
desde cero. Por ejemplo, la información se puede obtener de bases de datos, de archivos o de donde
uno lo desee, evitando la entrada manual de datos.
es rápida, al ser una herramienta creada desde cero se puede realizar lo más eficiente que uno
desee.
En lo legal: El grado de legalidad de la herramienta 3.0 también es alto con el de la 1.0 ya

que todas las tools son de licencia libre.
Efectividad del Help: La herramienta 3.0 posee mucha comunidad en internet y también,
mediante el Eclipse, posee la sección de ayuda para instalación o gestión de tools deseadas.

2022
Realizar las Pruebas
Tabla comparativa de métricas de herramientas
Se muestran en esta sección las 3 (tres) evaluaciones realizadas a cada herramienta

analizada. Se utilizó Google Sheets que es como el Excel que permite compartir a los stackeholders
el documento y que puedan ingresar la valoración que ellos consideran con la ayuda del evaluador.
Se obtuvo el documento mencionado en el marco de trabajo MyFEPs llamado “Planilla de Cálculo de
G Software Evaluado” y por cada una de las herramientas se obtuvo los valores de cada uno de los
interesados y se concluyó la evaluación promediando los valores otorgados.
Herramienta 1.0
La primera herramienta es la 1.0. Mostramos a continuación la hoja del Resultado Total pero
también se podrán ver las hojas con los nombres de cada interesado que realizó la encuesta o
cuestionario evaluando la herramienta.
Figura 32: Se muestra la hoja “Resultado total“ con el promedio de la evaluación de la herramienta
1.0

2022
En la columna Grado de Calidad se muestra que la herramienta 1.0 tuvo un promedio de la

calidad obtenida (por la evaluación) de 92.27% que es un valor muy elevado. Esto nos indica que los
interesados (Federico, Agustín y Hernán) evaluaron con muy buena puntuación esta herramienta.
Figura 33: Se muestran a modo de ejemplo los datos proporcionados por el Developer Lead (SR)
Federico.
Todos los resultados se encuentran en el documento “Herramienta 1.0 - Planilla de Cálculo

de G Software Evaluado” del Google Sheets (Google Drive) otorgado junto a esta tesina.
Herramienta 2.0
Se muestra en esta sección la evaluación y resultados de la herramienta 2.0. Luego de la

evaluación realizada a los interesados (mediante preguntas, encuestas y entrevistas) se obtuvo un
porcentaje de satisfacción total de 79.21 %. Si bien es menor al resultado de la herramienta 1.0, es
un porcentaje aprobado según lo mencionado en la Tabla 1 en la sección “Analizar y Calcular los
resultados” (el porcentaje de aprobación para estas herramientas y que nos recomienda MyFEPs es
de 70%).

2022
Figura 34: Se muestra la hoja “Resultado Total” de la herramienta 2.0
Figura 35: Se muestra la hoja Valores de referencia para guiar a los interesados

Herramienta 3.0

2022
Por último se muestra la evaluación realizada de la herramienta 3.0 donde se obtuvo un

porcentaje de aprobación de 88.92 % que es un valor que es aprobado para la evaluación, que
supera el porcentaje de la herramienta 2.0 pero que no alcanza al compararlo con la herramienta 1.0.
Figura 36: Se muestra la hoja “Resultado total” de la herramienta 3.0
Figura 37: Se muestra evaluación realizada por el evaluador que es parte de los stakeholders

2022

Analizar las Evaluaciones
Para la realización de las evaluaciones se instalaron las herramientas 1.0, 2.0 y 3.0 en las
computadoras de los interesados. Se utilizó el Google Drive con cada una de las herramientas y las
referencias para que el stakeholder se oriente de cuáles eran las características, subcaracterísticas y
atributos a evaluar y qué es lo que abarcaban cada una de ellas.
Se realizó esta evaluación 3 veces a cada interesado por cada una de las herramientas. En
algunos casos fueron preguntas y en otros la explicación de las características (subcaracterísticas y
atributos) para que dieran una respuesta de satisfacción en base a los valores de referencia que se
le propusieron como respuesta.
Figura 38: Muestra los valores que puede el interesado optar. El evaluador guió al interesado frente
a dudas.
Se utilizaron los valores propuestos por MyFEPs, también la escala Likert y se realizaron
preguntas al interesado.

2022
Figura 39: Se muestran las preguntas realizadas a los interesados..
En todo momento de las encuestas realizadas a los interesados se hizo hincapié en la ayuda
al mismo tanto para la instalación de la herramienta a evaluar como para el entendimiento del
contexto de los puntos a evaluar.
Resultados
La herramienta que mayor puntuación logró según las evaluaciones realizadas es la que
incorpora las tecnologías o herramientas Java, Selenium, ATDD, TestNG y Maven (Herramienta 1.0).
Con esto no quiere decir que sea mejor que el resto, sino que los evaluados se sienten más cómodos
con el uso de este framework generado.
Todas las herramientas obtuvieron resultados de aprobación pero como ya fue mencionado
anteriormente (y en la evaluación) la herramienta 1.0 posee un alto puntaje en características como
Adaptabilidad, Calidad de los artefactos (incluyendo alta cohesividad y bajo acoplamiento), Eficiencia,
entre otras características que la destacan.
Cuando se elige una herramienta para automatizar sitios web hay que pensar en varios
factores:
● Alta cohesividad en sus componentes para que el armado del framework sea eficiente
● Soporte en las herramientas del framework a generar
● Que las herramientas sean multiplataforma (que puedan ser ejecutadas y mantenidas en

2022
macOS, Linux y Windows)

● Fácil comprensión del framework desarrollado para perfiles JR’s, SSR’s y SR’s.
● Comodidad en la ejecución y realización de casos de prueba
● Comunidad en internet para realizar consultas o búsquedas
La herramienta 1.0 posee todos los puntos mencionados anteriormente y en promedio para
todos los interesados posee un puntaje muy bueno 92.77%.
Conclusiones
Mencionamos en esta sección todas las conclusiones obtenidas en el desarrollo de esta

tesina. Por un lado la herramienta 1.0 ha obtenido un puntaje de 92.77 % que si bien es un resultado
aprobado y elevado, indica que los evaluados están conformes, cómodos y contentos trabajando con
esta herramienta.
Este puntaje obtenido nos habla que la herramienta 1.0 posee características de mucha
importancia y que tienen que tener todas las herramientas que se utilicen para el desarrollo de
pruebas automatizadas sean para pruebas de sitios Web como de Apis, servicios, bases de datos,
entre otras cosas.
Hay que destacar que la herramienta 1.0 posee un lenguaje de programación muy estable y
con mucha comunidad que es Java y que permite ser flexible para pruebas de múltiples sistemas (o
softwares) y no sólo de sitios Web. Hay que tener en cuenta esto al seleccionar una herramienta de
testing automatizado.
La comunidad de las tools elegidas para desarrollar un framework de automation tiene que
ser alto, por ejemplo Java, Selenium, TestNG, Maven son muy utilizadas y se pueden encontrar
soluciones a problemas fácilmente en internet.
Es importante tener en cuenta que las empresas de sistemas (o cualquier empresa con
procesos) tiene que ir eliminando los procesos manuales y transformarlos en software que los realice
de forma automática. Si bien esta tesina trata de automatizar sólo las pruebas manuales, hay que
tener siempre en mente que la mayoría de las tareas manuales que se realizan en las empresas se
pueden automatizar, y que realizando esto se gana tiempo y se evitan errores.
Al seleccionar o desarrollar una herramienta de automation de pruebas hay que tener en
cuenta la portabilidad de la misma (tener en cuenta en qué sistemas operativos funciona o funcionará
la misma, que navegadores utiliza el cliente, qué ambientes o computadoras utiliza el usuario).

2022
Ciertas herramientas son pagas, hay que tener en cuenta el presupuesto de la empresa y del
área de QA para ver si conviene utilizar una herramienta paga o si con herramientas gratuitas y con
comunidad en internet se puede resolver el problema de igual manera.
Al tomar la decisión de elegir una herramienta de automation se debe tener siempre el aval
de todo el equipo para que se avance con la herramienta de forma rápida, tranquila y conforme al
equipo. No hay que tomar decisiones sin la aprobación del equipo que va a utilizar la herramienta ya
que sino se puede caer en falta de motivación del equipo, falta de avance, frenos en el desarrollo de
pruebas, entre otras cosas.
Para finalizar la conclusión, y como mención personal, considero que a lo largo de toda esta
tesina, he involucrado y mencionado todos los conocimientos adquiridos a lo largo de la carrera
Licenciatura de Sistemas de la Universidad de Belgrano. Doy por finalizado este trabajo y también
mis estudios universitarios en la universidad mencionada logrando el título de Licenciado en
Sistemas de información.
Líneas futuras de investigación
Se propone como líneas futuras de investigación las mencionadas a continuación:

● Continuar a detalle las evaluaciones de las herramientas realizadas pero siguiendo todas las
características, subcaracterísticas, atributos y métricas restantes que indica el framework
MyFEPs.
● Realizar la evaluación de otras herramientas de automation involucrando otros lenguajes de
programación como Python, Javascript, PHP, C#, C++, C, Node.js.
● Continuar con el coverage de casos de prueba automatizados en las herramientas ya
realizadas del sitio Web propuesto y para otros sistemas. Por ejemplo utilizar las
herramientas utilizadas en esta tesina para pruebas de aplicaciones Android, iOS.
● Analizar las herramientas de testing que utilizan las empresas en Argentina para otorgar
calidad a los softwares (o sistemas) realizados.
● Analizar otras metodologías de Testing/QA que no fueron mencionadas en esta tesina.

2022
Bibliografía
● MyFEPS - Se obtuvo información para el desarrollo de esta tesina de los documentos:
“1.1 MyFEPS.Proceso de evaluación de productos de software v9 final.docx”

“1.2 MyFEPS.Proceso de evaluación AGIL de productos de software v2021-07-11 sin encuestas
obligatorias.docx”
“1.3 MyFEPS.Proceso de Comparación AGIL de productos software similares v2021-07-11 sin
encuestas.docx”
Sitio Web MyFEPs:

https://sites.google.com/a/comunidad.ub.edu.ar/myfeps/portada
● The Software Report - Recuperado el 19 de abril de 2021

https://www.thesoftwarereport.com/the-top-100
● CESSI - Cámara de la industria Argentina del Software - Recuperado el 19 de abril de 2021
https://www.cessi.org.ar/empresas_argentinas
● Telam - Recuperado el 24 de mayo de 2019 http://www.telam.com.ar/notas/201905
● Mercurial: The Definitive Guide - Recuperado el 26 de junio de 2019
http://hgbook.red-bean.com/read/how-did-we-get-here.html
● Diferencias entre Testing manual y testing automatizado
https://www.professionalqa.com/manual-testing-vs-automation-testing
● Cobertura de casos de prueba https://www.guru99.com/test-coverage-in-software-testing.html
● Testingbaires - Recuperado el 24 de mayo de 2019 https://testingbaires.com/2017
● Seleniumhq - Recuperado el 26 de junio de 2019- https://www.Seleniumhq.org/support/
● Sitio web que menciona varias tools de testing -
https://www.guru99.com/automated-testing-tools.html
● Sitio Web oficial de HP QTP - https://www.microfocus.com/
● Sitio Web oficial de Katalon https://www.katalon.com/
● Sitio Web oficial de Cucumber https://cucumber.io/
● Herramientas de testing automatizado: https://www.guru99.com/automated-testing-tools.html
● Sitio Web oficial de Cypress https://www.cypress.io/
● Computing - testing

2022
http://www.computing.es/analytics/informes/1111750046201/testing-continuo-gana-terreno-or
ganizaciones.1.html
● Sitio oficial ISO/IEC 25040 - https://iso25000.com/index.php/normas-iso-25000/iso-25040
● SDET - Recuperado el 25 de enero de 2022 - https://www.linkedin.com/pulse/que-es-un-sdet
● QSAT - MyFEPS - Sitio oficial: https://sites.google.com/a/comunidad.ub.edu.ar/myfeps/qsat-1
● Alta cohesión y el bajo acoplamiento -
https://blog.koalite.com/2015/02/cohesion-y-acoplamiento/
● Sitio oficial de Phoneblocks - Muestra la modularidad - Imagen recuperada el 11 de mayo de
2022 - https://www.onearmy.earth/project/phonebloks
● UX vs UI - https://openclassrooms.com/en/courses/4556206-design-the-visual-side
● Sitio web oficial de Royal Aeronautical Society https://www.aerosociety.com/
● Recuperado el 25 de enero de 2022 -
https://www.etq.com/blog/the-history-of-quality-management/
● Recuperado el 25 de enero de 2022 - https://hmong.es/wiki/Deming_Prize
● ¿Qué es Java? - Sitio oficial de Java https://www.java.com/es/about/whatis_java.jsp también
se adjunta la documentación de Oracle (dueño de Java)
https://www.oracle.com/java/technologies/javase-documentation.html
● ¿Qué es Selenese? - Recuperado el 26 de enero de 2022 -
https://www.tutorialspoint.com/what-is-selenese
● Glosario DOM - Recuperado el 26 de enero de 2022 -
https://developer.mozilla.org/es/docs/Glossary/DOM
● Sitio oficial de Maven - https://maven.apache.org/
● Recuperado el 25 de enero del 2022 -
https://developer.mozilla.org/es/docs/Web/XML/XML_introduction
● Sitio oficial de Apache - https://www.apache.org/
● Recuperado el 25 de enero del 2022 - https://www.guru99.com/page-object-model
● Sitio oficial de TestNG - https://testng.org/doc/
● Sitio oficial de Junit - https://junit.org/junit5/
● Sitio oficial de Eclipse (IDE de desarrollo) - https://www.eclipse.org/downloads/
● Recuperado el 30 de enero de 2022 - https://www.agilealliance.org/glossary/atdd/
● Recuperado el 05 de abril de 2022 -
https://josepablosarco.wordpress.com/2015/03/31/tdd-vs-bdd-vs-atdd/
● Recuperado el 11 de mayo de 2022 -
https://www.digite.com/es/agile/el-desarrollo-orientado-a-pruebas
● Sitio oficial de descarga de Java -

2022
https://www.oracle.com/java/technologies/downloads/#jdk17-linux
● Sitio oficial de descarga Selenium - https://www.selenium.dev/downloads/
● Recuperado el 06 de enero de 2022 -
https://techandsolve.com/alta-cohesion-y-bajo-acoplamiento
● Sitio web oficial - Recuperado el 12 de mayo 2022 -
● Git - Sitio oficial https://git-scm.com/
● Sitio oficial de Groovy - http://groovy-lang.org
● Recuperado el 02 de enero de 2022 - https://www.tecnova.cl/2021/10/06/bdd
● Recuperado el 30 de enero de 2022 - https://docs.behat.org/en/v2.5/guides/1.gherkin.html
● Sitio oficial de JUnit - https://junit.org/junit5/
● Sitio Github de releases de Cucumber - https://github.com/cucumber/cucumber-ruby/releases
● Sitio ISTQB - https://www.istqb.org/
● La evaluación de la herramienta 1.0 se adjunta en el documento “Herramienta 1.0 - Planilla
de Cálculo de G Software Evaluado.xlsx” adjunto con los archivos enviados de esta tesina
● El código de las pruebas de la herramienta 1.0 se encuentra en el siguiente repositorio:
https://bitbucket.org/curraoyamil1/javatestng/src/master/
https://bitbucket.org/curraoyamil1/katalon/src/master/
https://bitbucket.org/curraoyamil1/cucumberjava/src/master/
Glosario
● Acceptance testing: Son las pruebas que realiza el cliente para verificar lo pedido en la
aplicación desarrollada
● API: Es una interfaz que provee un servicio
● ATDD: Es una metodología de trabajo que consiste en desarrollar los criterios de aceptación
junto a todos los stakeholders para la mejora de la calidad de los productos a desarrollar

2022
● BDD: Es el desarrollo de las pruebas basadas en el comportamiento que el usuario necesita

● Breakpoint: Punto de parate para el debugger. El IDE frenará en este punto al ejecutar el
caso de prueba automatizado y esperará la acción del usuario del framework para continuar.
● Bug: Es un error que el sistema tiene. Este error se tenía que haber contemplado en los
requisitos desarrollados.
● Concurrencia: Es cuando dos o más tareas se pueden ir procesando en períodos de tiempo
similares pero no necesariamente en el mismo tiempo, que eso sería la definición de
paralelismo.
● CI/CD: Con estas siglas denotamos la integración continua y el despliegue continuo.
● Coverage: Es un porcentaje de casos que cubren un módulo o sistema.
● Debugging: Es analizar cada paso de una funcionalidad.
● End-to-end tests: Es el camino completo de una prueba (de inicio a fin) que el usuario
comienza a realizar hasta que ve los resultados de su acción ejecutada.
● Framework: Es un marco de trabajo que facilita herramientas al que lo use, de esta forma no
se tiene que crear algo nuevamente si ya está desarrollado por otro.
● Functional tests: Son las pruebas de las funcionalidades que el cliente especificó que la
aplicación tenía que desarrollar.
● Integración continua: Es la ejecución constante y automatizada de las pruebas (unitarias,
funcionales, entre otras), implementaciones de código en ambientes, ejecución de análisis de
código estático y la ejecución de reportes, que indican el funcionamiento de todo lo
desarrollado en ambientes de prueba o producción para un proyecto en particular.
● Integration tests: Son las pruebas que verifican el funcionamiento de dos o más
componentes de un sistema.
● JDK: Son herramientas que provee un sistema para que puedan ser utilizados por otras
aplicaciones.
● ISTQB: Es el Comité Internacional de Certificaciones de Pruebas de Software.
● MyFEPS: Es un marco de trabajo de calidad de software.
● QA: Es el responsable de brindar los procesos, herramientas o conocimientos necesarios
para darle la mayor calidad al sistema a probar.
● QC: Es el responsable de brindar procesos, herramientas o conocimientos necesarios para
darle la mayor calidad a un producto a probar.
● Page Object Model pattern: Es un patrón de diseño que permite no duplicar código al
utilizar o interactuar con un objeto de una Web.
● Paralelismo: Es la ejecución en el mismo tiempo de dos procesos.
● Performance testing: Son las pruebas de rendimiento que se realizan a un sistema para

2022
probar su robustez.
● Pruebas de Regresión: Son las pruebas que verifican que todo lo que se desarrolló
anteriormente sigue funcionando de forma correcta.
● Pruebas de Smoke: Son pruebas ágiles para verificar que todo lo crítico del sistema
funciona correctamente.
● Pruebas Unitarias: Son las pruebas de código que realiza el desarrollador del sistema.
● Regresión: Es la ejecución de todas las pruebas existentes.
● Release: Es una versión de código que puede ser implementada en un ambiente de test o
producción.
● SDET (Software Development Enginner in Test): Es un automation que puede trabajar tanto
como tester de pruebas automatizadas como desarrollador.
● Selenese: Son comandos que se utilizan dentro de Selenium.
● Smoke: Es la ejecución de las pruebas críticas del sistema.
● Stakeholders: Son las partes interesadas en que un proyecto se cumpla.
● Tester: Es un rol que realiza pruebas a un sistema.
● Test Suite: Es un conjunto de casos de prueba.
● Testing: Es la acción de probar un sistema.
● Testing de Seguridad: Son las pruebas de vulnerabilidades de un sistema.
● TDD: Es el desarrollo basado en las pruebas.
● UI: User interface es el diseño o imagen del software o herramienta a evaluar o desarrollar,
no debe confundirse con UX.
● Unit tests: Son las pruebas unitarias que realiza un desarrollador.
● UX: User experience es la experiencia que tiene el usuario con la herramienta o software
utilizado, no debe confundirse con UI
● Versión de código: Es un paquete de software que tiene un identificador específico que no
se repite.
● Workspace: Carpeta en la cual se guarda la información de los proyectos realizados
mediante el IDE Eclipse.
● XML: Es un lenguaje que permite comunicar a sistemas que lo entiendan.

2022
Anexos
Proceso de evaluación: MyFEPS
El framework MyFEPS tiene como objetivo principal definir un marco de trabajo para la
elaboración de productos de software. En esta tesina se utilizó éste marco de trabajo para evaluar las
tres herramientas ya mencionadas.
Este framework (MyFEPS) se realizó y está orientado para que sea lo más completo posible,
entendible, basado en normas consensuadas, adaptable, entre otras características.
El sitio oficial del marco de trabajo es el siguiente pero se menciona en la Bibliografía las
actualizaciones de los documentos de MyFEPS:
https://sites.google.com/a/comunidad.ub.edu.ar/MyFEPS/tarea
Se utilizó MyFEPS para analizar y evaluar las 3 herramientas de automation elegidas para
que las empresas puedan automatizar sus productos Web o sistemas de software Web.
Las herramientas Java y Selenium, que si bien cada una de ellas pueden ser utilizadas por
separado, se analizaron y evaluaron como una herramienta en conjunto. Los atributos y métricas de
MyFEPS se aplicaron a la unión de estas dos herramientas. También se utilizaron las características
de MyFEPS para analizar las herramientas Katalon y Cucumber.
Escala Likert
En esta tesina utilizamos la escala Likert, denominada de este modo por la publicación de su
creador Rensis Likert y que es ampliamente utilizada en muchos sistemas. Se utiliza mucho en
cuestionarios y también en sistemas de hoy en día. Por ejemplo el sitio SurveyMonkey77 lo utiliza
también para las encuestas vía email que se realizan mediante este sitio.
Se muestra a continuación un ejemplo gráfico78 que se utiliza mucho en internet basado en la
77
Extraído el Domingo 04-03-2022 https://es.surveymonkey.com/mp/likert-scale/
78
Extraido el Domingo 04-03-2022
https://www.beetrack.com/es/blog/escala-de-satisfaccion-de-clientes

2022
escala Likert:
Figura 27: Muestra la escala Likert que se utiliza en muchas encuestas.
Tipos de metodologías de Testing
En esta sección se mencionan los tipos de testing existentes en QA y que se utilizan en las
empresas:79
● Smoke: Son un conjunto de pruebas que testea lo crítico.
● Regresión: Este tipo de metodología es el utilizado a modo de ejemplo en los Test Suites en
las herramientas 1.0, 2.0 y 3.0. La regresión de un sistema es ejecutar todas las pruebas
desarrolladas existentes.
● Unit tests: Son los casos de prueba realizados por los desarrolladores.
● Integration tests: Son los casos de prueba que prueban que todos los módulos funcionan
interconectados.
● Functional tests: Son las pruebas funcionales (lo que tiene que realizar el software).
● End-to-end tests: Son las pruebas que simulan el comportamiento esperado de los
usuarios.
● Acceptance testing: Son las pruebas que verifican si lo pedido por el cliente se cumple.
● Performance testing: Son las pruebas de rendimiento que verifican si en condiciones
normales se ejecuta rápido el sistema. A modo de ejemplo se menciona la herramienta
JMeter80, la misma es una de las herramientas más utilizadas y que es open course. Está
desarrollada en Java y permite realizar tests de performance tanto a aplicaciones Web, Apis,
79
Recuperado el 16 de mayo de 2022 -
https://programacionymas.com/blog/tipos-de-testing-en-desarrollo-de-software
80
Sitio oficial Jmeter - Recuperado el 16 de mayo de 2022 - https://jmeter.apache.org/

2022
SOAP / REST Webservices, entre otros.

● Testing de Seguridad: Son las pruebas que verifican la calidad en la seguridad de los
sistemas.
● Testing de Apis: Permite realizar pruebas directamente a la interfaz que consumen los
clientes front (aplicaciones mobile o web) de las aplicaciones. La herramienta más utilizada
es Postman81 que permite probar apis de una forma muy sencilla y amigable.
Por último se menciona un tipo de testing que he ideado y que utilicé en varias empresas. Esta
metodología incluye varias formas de testeo, varias técnicas de procesos y un método específico de
organización del equipo de QA todo en uno. Esta técnica se llama:
Testing Relámpago
Esta metodología la creé frente a la necesidad de tener que probar y encontrar errores en
varios sistemas al mismo tiempo, llamémoslos varios frentes de testeo.
La metodología consta de organizar a todo el equipo de QA para que se focalicen con toda
su experiencia para tratar de encontrar el error 500 (internal server error) o el 404 (recurso no
encontrado), o cualquier tipo de error que nos permita frenar las pruebas de un software y saltar a
probar otro.
Lo que nos permitió esta metodología es poder ganar tiempo utilizando toda la experiencia
de todo el equipo de testeo, ejecutando todas las pruebas automatizadas existentes y ejecutando las
pruebas de estrés en paralelo.
Si encontramos los errores rápidamente ganamos tiempo para que el equipo de QA se
organice mejor mientras que el equipo de Desarrollo va solucionando los bugs encontrados y nos
envía otra versión a probar.
Lo ideal es enfocar a todo el equipo (utilizando todas las fuerzas posibles, conocimientos y
pruebas automatizadas) para romperlo (encontrar un bug crítico) y saltar a seguir probando otra
aplicación.
81
Sitio oficial Postman - Recuperado el 16 de mayo de 2022 - https://www.postman.com/

2022
CI/CD
En la actualidad cuando hablamos de pruebas automatizadas, es importante hablar de CI/CD

82
(Integración continua y Delivery continuo). Lo que nos otorgan estas metodologías es la habilidad
de ejecutar las pruebas automatizadas una vez el desarrollador realice una versión de código o
commit en el software que está desarrollando.
Page Object Model (Pattern)
El POM o Page Object Model83 es un patrón de diseño de software que se utiliza en

Selenium y que nos permite la reutilización de código y la creación de un repositorio de software para
utilizar los objetos necesarios sin duplicar código.
ISTQB
El ISTQB84 (International Software Testing Qualifications Board) es una certificación global de

calidad de sistemas (y softwares) que permite garantizar que la persona posee conocimientos
importantes en los procesos de QA y Testing. Posee varios niveles de exámenes que son
recomendados y buscados por las empresas.
82
CI/CD - Recuperado el 16 de Mayo de 2022 -
https://www.redhat.com/es/topics/devops/what-is-ci-cd
83
POM - Page Object Model - Recuperado el 16 de Mayo de 2022 -
https://www.browserstack.com/guide/page-object-model-in-selenium
84
Sitio oficial - Recuperado el 16 de Mayo de 2022 - https://www.istqb.org/

2022
Figura 40: Certificación ISTQB
Test Management Tools
Las herramientas de gestión de casos de prueba son una gran ayuda para todos los sectores
de Calidad (QA/Testing) en las empresas. Sin duda sin estas herramientas es muy difícil llevar a cabo
el trabajo de un analista de calidad. Estas herramientas permiten ingresar en las mismas todos los
casos de pruebas existentes dividiéndolos según módulos, secciones, sistemas, softwares o lo que
sea conveniente para organizar mejor los casos de pruebas.
Estas herramientas nos permiten organizar los casos según estén o no automatizados,
según sean críticos para ejecutar una regresión o smoke, según pertenezcan a una sección u otra,
entre otras cosas.
Al elegir una herramienta de gestión de casos de pruebas se tiene que tener en cuenta que
la misma debe soportar integraciones y customización necesaria para que el usuario se sienta
cómodo utilizando.

2022
Figura 41: Se muestra la herramienta TestRail que posee integración con Java y otras herramientas.
XPath
El XPath (sus siglas son XML Path Language) es un lenguaje que permite obtener un objeto
en un sitio web a través de construcciones de expresiones que detecten esos objetos en el mismo.
En esta tesina se utilizan estas expresiones al desarrollar los frameworks de automation para obtener
los objetos en el sitio web que se utiliza de ejemplo.
Se muestran a continuación algunos ejemplos del uso de XPath:
1. XPath Absoluto:
Si buscamos en el sitio Web de ejemplo que utilizamos en nuestra tesina el siguiente XPath absoluto,
encontraremos en la Web el texto “Testing Relámpago” a través de un camino absoluto (paso a paso)
desde la raíz de nuestro código Front End hasta encontrar la posición exacta de ese texto. (No es
muy recomendado su uso ya que no es eficiente)
/html/body/div/div/div/div[1]/div/div/section/div/div/div[1]/div/div[2]/div/nav/div[2]/div/div[1]/div/
a/div/h3

2022
Figura 42: XPath absoluto ejemplo
2. XPath Relativo:
Si en vez de utilizar el XPath absoluto de antes, utilizamos un XPath relativo (acceder directamente a
lo que buscamos sin utilizar todo el árbol del html del sitio) podríamos utilizar una expresión como la
siguiente (mucho más eficiente y fácil de modificar frente a cambios de textos o de header):
//h3[contains(text(),'Testing Relámpago')]

2022
Figura 43: XPath relativo ejemplo
Código de las herramientas
El código realizado para las 3 (tres) herramientas se encuentra en su respectivo repositorio.

Para visualizar el mismo se lo puede hacer mediante los 3 repositorios correspondientes a cada
herramienta. También se adjuntará con lo enviado de esta tesina.
Los repositorios son los siguientes (también mencionados en la bibliografía):
Figura 44: Repositorios de código de las herramientas

Tesina Currao Junio 2022

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesina Currao Junio 2022

Cargado por

Copyright:

Formatos disponibles

Licenciatura en Informática

Análisis de Automatización de Testing para sitios Web

Facultad de Tecnología Informática

Licenciatura en Informática - 501 2/93

Licenciatura en Informática - 501 3/93

Licenciatura en Informática - 501 4/93

Licenciatura en Informática - 501 5/93

Tabla 1: Marco de trabajo MyFEPS

Figura 1: Ventajas de automation 9

Licenciatura en Informática - 501 6/93

Figura 27: Escala Likert 76

Licenciatura en Informática - 501 7/93

Licenciatura en Informática - 501 8/93

Contexto del problema

En la actualidad hay muchas empresas2 de desarrollo de sistemas de software, tanto a nivel

Licenciatura en Informática - 501 9/93

Licenciatura en Informática - 501 10/93

Algunas otras opciones que existen en el mercado actual son:

● HP UFT/QTP10, que implementa el diseño de objetos para encapsular ciertas funcionalidades

Licenciatura en Informática - 501 11/93

Figura 2: Capturas del sitio oficial de HP sobre la herramienta HP UFT/QTP11

Licenciatura en Informática - 501 12/93

Figura 3: Capturas del sitio oficial de Cypress17

Licenciatura en Informática - 501 13/93

Se menciona a continuación las secciones que posee esta tesina:

1. Introducción: Se compone del contexto del problema, justificación de la tesina, alcance de

Licenciatura en Informática - 501 14/93

El alcance de esta tesina comprende los siguientes puntos:

● Investigación de herramientas de automation (se hace foco en herramientas de automation

Licenciatura en Informática - 501 15/93

● Para poder evaluar las características, subcaracterísticas y atributos anteriormente

● La tesina incluye los resultados y conclusiones obtenidos en la evaluación mencionada,

Las limitaciones de esta tesina se mencionan a continuación:

Licenciatura en Informática - 501 16/93

pruebas de la tesina y se subirán en un repositorio para el control de las versiones

El objetivo principal de esta tesina es determinar la importancia del uso de herramientas de

Los objetivos específicos que esta tesina desarrolla son:

Licenciatura en Informática - 501 17/93

Los objetivos personales que se incluyen en esta tesina son:

● Aplicar todos los conocimientos obtenidos en la carrera Licenciatura en Sistemas de la

Licenciatura en Informática - 501 18/93

ID21 Actividad o tarea de MyFEPS Descripción

2 Establecer el Propósito de la El propósito de esta tesina es comparar las herramientas

Licenciatura en Informática - 501 19/93

como la mejor opción

3 Identificar el Producto a Los productos a evaluar son las tres herramientas de

4 Identificar los Requerimientos Definiciones:

14 Definir Recursos para la Los recursos a utilizar por el evaluador son:

17 Establecer Ponderación de Las características que se utilizarán para ponderar las

Licenciatura en Informática - 501 20/93

● Calidad de los artefactos

Si bien se analizaron los resultados de las evaluaciones de

Los valores que completaron los stakeholders son los

1 - Primer ponderación que se les dió a los interesados

● Muy importante: Peso de 100%

2 - Segunda ponderación que se les dió (escala Likert

Licenciatura en Informática - 501 21/93

● Excelente: Peso de 100%

21 Preparar Recursos e Para este punto se realizaron reuniones con los

Se utilizó la herramienta de Google Sheets26 para la

Cada uno de los stakeholders utilizó su propia computadora

Los casos de prueba de la evaluación a realizar por cada

35 Medir los Atributos requeridos Se realizó junto a los stakeholders la ponderación de la