BorreroNunezOswaldo20212099017 - SierraOrtegaNathaliaAndrea20212099025

Redes Computacionales

•

Agrárias

Jesus Jesus

4/2/2024

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Redes Computacionales

66.476 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

ESPECIALIZACIÓN EN INGENIERÍA DE SOFTWARE

LINEAMIENTO TÉCNICO Y OPERATIVO PARA LA IMPLEMENTACIÓN DE PRUEBAS
AUTOMATIZADAS EN LAS EMPRESAS DESARROLLADORAS DE SOFTWARE

Presentado por:
Oswaldo Borrero Nuñez 20212099017
Nathalia Andrea Sierra Ortega 20212099025

Revisor:
Beatriz Elisa Jaramillo Moreno
Director:
Alexandra Abuchar Porras

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
ESPECIALIZACIÓN EN INGENIERÍA DE SOFTWARE
BOGOTA D.C.
2022
2

TABLA DE CONTENIDO
INTRODUCCIÓN ....................................................................................................................................... 7
PARTE I. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN ........................................................ 8
LINEAMIENTOS TÉCNICOS Y OPERATIVOS PARA LA IMPLEMENTACIÓN DE PRUEBAS
AUTOMATIZADAS EN LA EMPRESA DESARROLLADORA DE SOFTWARE VALID ............. 8
CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN .................................................................. 8
1.1 PLANTEAMIENTO DEL PROBLEMA ........................................................................................ 8
1.2 OBJETIVOS .................................................................................................................................... 10
1.2.1 Objetivo general. ...................................................................................................................... 10
1.2.2 Objetivos específicos. ................................................................................................................ 10
1.3 JUSTIFICACIÓN ........................................................................................................................... 11
1.4 HIPÓTESIS ..................................................................................................................................... 13
1.5 MARCO REFERENCIAL ............................................................................................................. 14
1.5.1 MARCO TEÓRICO: ................................................................................................................... 14
1.5.1.1 Pruebas de software: ............................................................................................................. 15
1.5.1.2 Pruebas manuales: ................................................................................................................ 18
1.5.1.3 Pruebas automatizadas: ........................................................................................................ 19
1.5.1.3.1 Beneficios de las pruebas de automatización: .................................................................. 20
1.5.1.4 Pruebas api rest: .................................................................................................................... 22
1.5.1.5 Pruebas interfaz de usuario (UI): ........................................................................................ 23
1.5.2 MARCO CONCEPTUAL. .......................................................................................................... 30
1.5.2.2 Implementación: .................................................................................................................... 30
1.5.2.3 Empresa desarrolladora de software: ................................................................................. 30
1.5.2.4 Pruebas del software: ............................................................................................................ 31
1.5.2.5 Plan de pruebas de software: ................................................................................................ 31
1.5.2.6 Casos de pruebas: .................................................................................................................. 31
1.5.2.7 Ejecución de pruebas: ........................................................................................................... 32
1.5.2.8 La automatización: ................................................................................................................ 32
1.5.2.9 Pruebas de rendimiento: ....................................................................................................... 32
1.5.2.10 Interfaz de usuario (UI). ..................................................................................................... 33
1.5.2.11 API (interfaz de programación de aplicaciones). ............................................................. 33
1.5.2.12 framework. ........................................................................................................................... 33
1.5.2.13 El BDD (desarrollo guiado por el comportamiento) ........................................................ 34
3

1.6 METODOLOGÍA DE LA INVESTIGACIÓN ............................................................................. 35
1.6.1 Tipo de estudio. ......................................................................................................................... 35
1.6.2 Método de investigación. .......................................................................................................... 35
1.6.3 Fuentes y técnicas para la recolección de la información. .................................................... 35
1.6.4 Tratamiento de la información. ............................................................................................... 36
PARTE II. DESARROLLO DE LA INVESTIGACIÓN ...................................................................... 37
CAPÍTULO 2. PROCESO PARA EL AREA DE AUTOMATIZACIÓN ........................................... 37
2.1 FLUJO DE PROCESO DE QA AUTOMATIZACIÓN .............................................................. 37
2.2 PLAN DE AUTOMATIZACIÓN DE PRUEBAS ........................................................................ 39
2.3 ESTRATEGIA DE PRUEBAS AUTOMATIZADAS .................................................................. 45
2.4 AMBIENTE Y HERRAMIENTAS DE PRUEBA ....................................................................... 48
1. Herramientas de pruebas ............................................................................................................. 48
2. Ambientes de pruebas ................................................................................................................... 49
3. Criterios de entrada y salida ........................................................................................................ 49
2.5 PLANIFICACIÓN DE EJECUCIÓN DE LAS PRUEBAS ........................................................ 50
2.6 REPORTE DE PRUEBAS ............................................................................................................. 61
PARTE III. CIERRE DE LA INVESTIGACIÓN ................................................................................. 64
CAPÍTULO 3 RESULTADOS Y DISCUSIÓN. ..................................................................................... 64
3.1 RESULTADOS. ............................................................................................................................... 64
3.2 DISCUSIÓN. .................................................................................................................................... 65
CAPÍTULO 4. CONCLUSIONES ........................................................................................................... 66
4.1 VERIFICACIÓN, CONTRASTE Y EVALUACIÓN DE LOS OBJETIVOS........................... 66
4.2 APORTES ORIGINALES .............................................................................................................. 67
4.3 TRABAJOS O PUBLICACIONES DERIVADAS ....................................................................... 67
CAPÍTULO 5. PROSPECTIVA DEL TRABAJO DE GRADO ........................................................... 695.1 LÍNEAS DE INVESTIGACIÓN FUTURAS ................................................................................ 69
5.2 TRABAJOS DE INVESTIGACIÓN FUTUROS ......................................................................... 69
BIBLIOGRAFÍA ....................................................................................................................................... 70
ANEXOS .................................................................................................................................................... 77
1. MANUAL DE USUARIO: ................................................................................................................ 77
1.1 HERRAMIENTAS DE PRUEBAS .......................................................................................... 77
1.2 IMPLEMENTACIÓN LINEAMIENTO TÉCNICO Y OPERATIVO: .................................... 90

Tabla de Ilustraciones.

Figura 1. Beneficios de la automatización …………………………………………………. 11
Figura 2 Actividades de aseguramiento de calidad del software…………………………… 15
Figura 3 Modelo general V ……………………………………………………………….. 16
Figura 4 Características de pruebas de software …………………………………………… 17
Figura 5 Beneficios de las pruebas automatizadas ………………………………………… 20
Figura 6 Herramientas para la ejecución de pruebas Api Rest …………………………….. 23
Figura 7 Herramientas de automatización UI. ……………………………………………... 24
Figura 8 Código del lenguaje Gherkin …………………………………………………….. 25
Figura 9 Arquetipo patrón ScreenPlay …………………………………………………….. 27
Figura 10 Flujo de proceso de QA automatización ……………………………………….. 38
Figura 11. Patrón de diseño: Serenity BDD “ScreenPlay” ………………………………… 52
Figura 12. Fujo GitHub ……………………………………………………………………. 58
Figura 11. Resultados ……………………………………………………………………… 64
Figura 12. Propiedades del sistema. ………………………………………………………. 77
Figura 13. Configuraciones variables de entorno …………………………………………. 78
Figura 14. Configuración JAVA_HOME ………………………………………………… 78
Figura 15. Configuración de la variable. …………………………………………………… 78
Figura 16. Resultados de variables de entorno. …………………………………………….. 79
Figura 17. Consulta en consola …………………………………………………………….. 80
Figura 18. Consulta en consola mvn ……………………………………………………… 81
Figura 19. Appium ………………………………………………………………………… 82
Figura 20. Propiedades del sistema. ………………………………………………………. 82
5

Figura 21. Configuraciones variables de entorno …………………………………………... 83
Figura 22. Configuración JAVA_HOME ………………………………………………….. 83
Figura 23. Configuración de la variable. ………………………………………………….. 83
Figura 24. Resultados de variables de entorno. …………………………………………… 84
Figura 25. Consulta en consola……………………………………………………………. 85
Figura 26. Consulta en consola. …………………………………………………………… 86
Figura 27. Consulta en consola Appium…………………………………………………… 86
Figura 28. Appium Desktop………………………………………………………………… 87
Figura 29. Appium Desktop Server ………………………………………………………... 88
Figura 30. Appium Doctor………………………………………………………………….. 89
Figura 31. Visualización proyecto en IntelliJ IDEA Community Edition…………………. 92
Figura 32. Creación de archivo ……………………………………………………………. 92
Figura 33. Creación de feature……………………………………………………………… 93
Figura 34. Visualización código feature…………………………………………………… 93
Figura 35. Visualización código stepsdefinition…………………………………………. 97
Figura 36. Visualización código task……………………………………………………… 99
Figura 37. Visualización código pageobjet………………………………………………… 101
Figura 38. Visualización código stepsdefinition…………………………………………... 102
Figura 39. Visualización código runner…………………………………………………… 103
Figura 40. Visualización código serenity.properties……………………………………….. 105
Figura 41. Visualización código ejecución de pruebas…………………………………….. 106
Figura 42. Visualización reporte de ejecución……………………………………………… 107
Figura 43. Visualización reporte de escenarios ……………………………………………. 107
6

Figura 44. Visualización reporte de ejecución de caso de prueba………………………….. 108
Figura 45. Visualización del reporte feature ………………………………………………. 108

INTRODUCCIÓN
Un mundo globalizado exige que las sociedades avancen en la forma y manera de relacionarse, en
la optimización de tareas, aprovechamiento del tiempo y de recursos, siendo relevante que los avances a
nivel tecnológico faciliten los trámites y gestiones que realizan las personas. En ese sentido, las empresas
públicas y privadas se ven en la necesidad de adecuar sus procesos y procedimientos a la era de la
tecnología, incorporando en sus esquemas de trabajo software que permitan el relacionamiento con sus
usuarios internos y externos de manera amigable y rápida. No obstante, dichas adecuaciones requieren de
gran inversión de tiempo y recursos para el desarrollo de software, aunado a la imperante necesidad de
realizar las pruebas que efectúa el analista QA para determinar que el producto está en óptimas
condiciones para ser aplicado y usado por los usuarios.
Así las cosas, las empresas desarrolladoras de software que aún no han incorporado la
automatización de pruebas en sus procesos, recurriendo en la actualidad a las denominadas pruebas
manuales, mismas que si bien son válidas no obedecen a la tendencia actual en cuanto a la automatización.
En consecuencia, el presente trabajo pretende construir un lineamiento técnico operativo para la
implementación de pruebas automatizadas en la empresa desarrolladora de software, aportando en la
creación y posterior consolidación de este tipo de pruebas impactando positivamente en la optimización y
aprovechamiento de los recursos técnicos, tecnológicos y humanos en pro de entregar un producto final
con calidad.
Dicho esto, el documento contendrá y especificará los aspectos relevantes que se deben tener en
cuenta al momento de realizar un proyecto de automatización de pruebas de software. Como primera
instancia se describe el proceso a tener en cuenta para la automatización partiendo de las pruebas
manuales, especificando las entradas y salidas del mismo; seguido se detalla la planificación de dicho
proceso de automatización en donde se plantea el alcance, fuera del alcance, riesgos, supuestos y criterios
de aceptación para las pruebas, así mismo se propone una fórmula de estimación de tiempos, herramientas
a utilizar, frameworks y patrón necesario para la automatización.
8

PARTE I. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN
LINEAMIENTOS TÉCNICOS Y OPERATIVOS PARA LA IMPLEMENTACIÓN DE PRUEBAS
AUTOMATIZADAS EN LAS EMPRESAS DESARROLLADORAS DE SOFTWARE
CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN
1.1 PLANTEAMIENTO DEL PROBLEMA
En la actualidad el mundo exige avances tecnológicos que aporten en la construcción y
consolidación de herramientas que posibiliten la solución de problemas de toda índole, constituyendo un
reto importante para los profesionales y las empresas desarrolladoras. En ese sentido, los nuevos
desarrollos deben ser probados antes de salir al mercado razón por la cual los analistas QA acuden a
pruebas manuales y automatizadas para ello. Ahora bien, a nivel mundial “…la automatización de las
pruebas funcionales reduce significativamente el esfuerzo dedicado a las pruebas de regresión en
productos que se encuentran en continuo mantenimiento. La automatización de las pruebas debe ser
considerada un proyecto en sí mismo con objetivos definidos” (Esteve, 2015, pag.7).
Así mismo, se evidencia en la tesis de automatización de procesos para mejorar las pruebas de
software en el área de calidad del banco de crédito en Lima – Perú, que “... al automatizar los procesos
para la generación de data para el área de calidad reducen el tiempo en un 56.78%, aumentando la
cantidad de data generada en un 7.71%, permitiendo mejorar de manera significativa las pruebas de
software” (Fernández, 2018, pag,12 ).
Además, las pruebas automatizadas se realizan con el propósito de disminuir el tiempo de
iteración del ciclo de pruebas,mejorar la cobertura de pruebas de regresión y a su vez ahorrar recursos y
costos, debido a la reducción de esfuerzos en las pruebas manuales (Toka System, 2013).
Puesto que las pruebas manuales son laboriosas y propensas a errores, y no soportan el mismo tipo
de controles de calidad que son posibles con las pruebas automatizadas.
9

Actualmente la empresa de desarrollo de software, es un proveedor global de tecnología, el cual
ofrece una amplia cartera de soluciones de pago, móviles, soluciones de identidad y datos, así como de
Marketing Digital y certificación digital. Dentro de la organización el área de Quality Assurance (QA) es
la encargada de garantizar la calidad de los productos de software por medio del análisis, diseño y
ejecución de casos de pruebas, detectando posibles errores en cualquier fase del proyecto con el fin de
ahorrar costos y tiempo durante su desarrollo. En la actualidad para la ejecución de dichas pruebas solo se
cuenta con herramientas que le permiten al analista realizar las actividades de forma manual, sin poder
aplicar otras técnicas con las que pueda optimizar los procesos.
Así las cosas, con el fin de agilizar las acciones mencionadas anteriormente, la empresa pretende
implementar prácticas que permitan al analista QA automatizar las pruebas de software, pero
lamentablemente la institución no cuenta con un lineamiento que permita incluirla en sus procesos de
desarrollo.
Las pruebas en el desarrollo de software ayudan a reducir el riesgo de fallo en el entorno de
operación, pero no significa que aporte a reducir tiempo y costo sobre la productividad de la institución,
ya que realizar las actividades de obtención de data y ejecución de pruebas manuales sería tediosa y/o
difícil, desgastando así al analista de QA y posiblemente incumpliendo en la entrega del producto en los
tiempos requeridos.
Por ello, la presente investigación pretende desarrollar un lineamiento técnico y práctico que
ayude al grupo de QA a fortalecer los procesos de calidad de software por medio de la implementación de
automatización de pruebas e incluso la extracción de la data para las mismas, reduciendo así los tiempos y
esfuerzos a invertir en los proyectos desarrollados.

1.2 OBJETIVOS
1.2.1 Objetivo general.
Diseñar lineamientos técnicos y operativos para la implementación de la automatización de
pruebas que permita fortalecer los procesos de calidad del software desarrollados por el grupo QA.
1.2.2 Objetivos específicos.
● Definir el proceso de automatización en el organigrama de actividades del grupo de QA para la
implementación de las pruebas automatizadas.
● Establecer las orientaciones técnicas y operativas para el desarrollo de las pruebas automatizadas
mediante el plan de pruebas.
● Determinar el set de pruebas para la ejecución de la automatización de acuerdo con la necesidad
del proyecto de software.

1.3 JUSTIFICACIÓN
Uno de los tantos retos a los que se enfrentan las empresas desarrolladoras de software es entregar
un producto con calidad y pertinencia, ajustado a las necesidades de la sociedad y funcionando
correctamente. En ese sentido, el profesional QA cumple un rol fundamental al efectuar las pruebas
necesarias para determinar si el desarrollo puede ser divulgado y aplicado, mismas que se encuentran en
dos líneas, las manuales y las automatizadas, siendo las segundas objeto de la presente investigación. En
consecuencia y con el objetivo de implementar la automatización de pruebas que permita fortalecer los
procesos de calidad de software desarrollados por el grupo de QA y teniendo en cuenta que en la
actualidad no se ha estructurado la forma del cómo se puede desarrollar e implementar el proceso de
pruebas automatizadas, la presente investigación busca definir un lineamiento técnico y práctico de trabajo
que detalle las herramientas y procedimientos básicos necesarios para incluir dicho proceso en el análisis,
diseño y ejecución de casos de pruebas.
Ahora bien, tal como se observa en la figura 1, se encuentran los beneficios que ofrece la
automatización.
Figura 1. Beneficios de la automatización

Fuente: Elaboración propia a partir de Restrepo, Navarro y Obando (2020).
12

De acuerdo con lo anterior, la automatización ayuda a las organizaciones a depurar tiempos en los
procesos manuales, además posibilita la reducción de los gastos de producción permitiendo identificar de
manera temprana fallos que se pueden cometer en los proyectos en desarrollo.
Valid tiene como uno de sus principales objetivos ofrecer a sus clientes, de acuerdo con sus
necesidades, proyectos de software con altos estándares de calidad, por tanto, en su plan de trabajo
implementa actividades relacionadas con la ingeniería del software (creación de software confiable y de
calidad) tal como el testing de software que posee dos tipos de pruebas, estas son las manuales y las
automatizadas; el cual se encarga de verificar y validar el funcionamiento de un programa o una
aplicación de software con el fin de minimizar el riesgo de entregar sistemas con fallas.
Sin embargo, en esta empresa solo se realizan pruebas manuales tal como se encontró en el
organigrama contenido en el documento llamado “Proceso área funcional y tester”, y de acuerdo con
Interware (2018), las pruebas manuales:
Éstas en algunas ocasiones son insuficientes para garantizar el aseguramiento de la calidad del
software, ya que no se logra abarcar con totalidad la cobertura del sistema que se requiere probar,
y además se suele invertir más tiempo cuando se necesita re ejecutar casos de pruebas.
A diferencia de las pruebas manuales, las automatizadas resultan ser más prácticas a la hora de
querer reducir el trabajo repetitivo, logrando que sea más efectivo y productivo, incluso en ocasiones
permiten cerrar la brecha de las limitaciones de tiempos.
En términos generales consiste en la utilización de un software para ejecutar o apoyar las
actividades de prueba, tales como la gestión, los casos de prueba, la ejecución y la evaluación de
resultados, ya que la automatización de las pruebas surgió como una alternativa para probar en
menos tiempo las funcionalidades del sistema. (Serna, Martínez y Tamayo, 2017, p.338).

1.4 HIPÓTESIS
El lineamiento técnico y operativo permitirá al equipo de QA fortalecer los procesos de calidad de
software mejorando los tiempos dedicados a los proyectos designados.

1.5 MARCO REFERENCIAL
1.5.1 MARCO TEÓRICO:
Para las empresas establecer un lineamiento estratégico es fundamental al momento de iniciar un
nuevo proceso que se desee incorporar, en tanto que permite orientar a sus colaboradores en cada
actividad planteada para lograr el mayor beneficio en su implementación.
Entonces, es importante señalar que un lineamiento estratégico “…es el programa o plan de
acción que rige a cualquier institución. De acuerdo con esta aceptación, se trata de un conjunto de
medidas, normas y objetivos que deben respetarse dentro de una organización” (Montenegro, 2014).
Ahora bien, para diseñar dicho lineamiento se debe definir el objetivo y metas de los procesos, lo
cual contendrá elementos que permitirán crear las bases sólidas de la estrategia seleccionada.
Así las cosas, el objetivo se orienta hacia el aseguramiento de la calidad del software (ACS) y que
según Pressman (2010):
El proceso de aseguramiento de calidad comprende la mayor parte del proceso general de
desarrollo del sistema por lo que las actividades se definen para aplicarse a diferentes aspectos de
la visión general del sistema como producto final con la certificación que todos los procesos y
componentes construidos fueron evaluados y probados. (pp. 368-380).
Como se ve en la figura 2, las actividades que intervienen en el aseguramiento de calidad del
software se distribuyende la siguiente forma:

Figura 2 Actividades de aseguramiento de calidad del software.
Fuente: Elaboración propia (2022)
1.5.1.1 Pruebas de software:
Al adquirir un producto se asume y confía en su calidad. Ahora bien, cuando se habla de
productos de software, se espera que estos no tengan fallos que puedan afectar su funcionalidad, por lo
tanto, se deben realizar las respectivas pruebas de software consideradas como: una fase en el desarrollo
de software que se encarga de probar las aplicaciones construidas con el fin de identificar posibles fallos
de implementación, calidad o usabilidad. (Fossati,2016).
De acuerdo con esto se puede decir que las pruebas de software se utilizan con el fin de asegurar
un producto de calidad que cumpla con los estándares requerido por los clientes; así mismo Kaner (2008)
define las pruebas de software como: “Las pruebas de software son la investigación empírica y técnica
realizada para facilitar a los interesados información sobre la calidad del producto o servicio bajo
pruebas”.
16

Existen varios tipos de pruebas que de acuerdo con los diferentes modelos de desarrollo de software son
aplicables a cada uno de ellos, entre estos están, modelo cascada, modelo general en V, etc.
De acuerdo con la figura 3, para el modelo general V se tienen en cuenta las siguientes pruebas:
Figura 3
Modelo General V

Fuente: Pressman (2010).

Estos tipos de pruebas tienen sus principales características en el ciclo de vida del desarrollo del software
como se observa en la figura 4:
Figura 4
Características de pruebas de software

Fuente: Elaboración propia a partir de Zapata (2013).
De acuerdo con lo anterior, las pruebas tienen como objetivo principal evaluar y verificar el
comportamiento del sistema, que los componentes se hayan integrado correctamente y cumplan con las
funciones para la cual se diseñaron, comprobar las características críticas para el negocio, la funcionalidad
y la usabilidad.
Dentro de estos tipos de pruebas se incluyen las unitarias, de interfaz, de regresión, entre otras,
que pueden ser ejecutadas manualmente y/o automatizadas.
18

1.5.1.2 Pruebas manuales:
Son ejecutadas por los analistas de certificación QA con el fin de evaluar si el sistema cumple con
los criterios del usuario para el cual se generó el proyecto.
Soto (2020), afirma que:
Los analistas de certificación ejecutan manualmente los casos de prueba definidos sin usar
ninguna herramienta o script de automatización. Es la más primitiva de todos los tipos de pruebas
y ayuda a encontrar errores en el sistema de forma muy puntual.
Al mismo tiempo estas son indispensables para cada proyecto, ya que por medio de ellas se
detectan la mayor parte de los defectos, y de esta forma se logra estabilizar el sistema que se está
probando, además permiten un análisis profundo por parte de un humano, lo cual es un mayor beneficio
cuando se quiere mejorar la experiencia de usuario (Interware, 2018).
Para llevar a cabo estas pruebas, el analista QA desempeña una serie de actividades, dentro de las
cuales se encuentran las siguientes:
● Realizar la planificación de las pruebas, definiendo los objetivos y el alcance de éstas.
● Analizar y realizar el diseño de los casos de prueba.
● Priorizar los casos de prueba a ejecutar.
● Realizar extracción de la data de prueba a utilizar.
● Identificar los recursos necesarios para las pruebas, tales como cantidad de analistas, recursos
físicos, accesos, entre otros.
● Desarrollar la ejecución de los casos de prueba y generar manuales de ejecución.
● Identificar bugs en las ejecuciones, reportar a desarrollo y realizar la respectiva gestión para su
solución.
● Realizar re-test de los casos de prueba que presentaron errores.
19

● Ejecutar casos de regresión sobre los módulos alternos, para identificar que no se hayan visto
afectados por la solución de errores en otros módulos de prueba.
En definitiva, “Cuando se habla de probar software o testear, puede parecernos que es un trabajo
fácil, pero profundizando en sus actividades podemos observar que se requieren de conocimientos y
habilidades especiales para ello” (Euroinnnova, 2020).
Por esta razón cualquier proyecto de software debe ser probado manualmente, aunque estas
requieran más esfuerzo, puesto que con esto se puede verificar si es viable automatizar las pruebas de
software.
En relación con las pruebas de regresión se encuentra que tienen como finalidad detectar defectos,
así como los otros tipos de pruebas, pero este tiene una particularidad y es que se ejecuta cuando se
añaden nuevas versiones o funcionalidades sobre el sistema, con el fin de validar que lo que ha sido
probado anteriormente no presente fallos ocasionados por dichos ajustes.
En ese sentido Maida y Pacienzia (2015) dicen que “El propósito de estas pruebas es asegurar que
los defectos identificados en la ejecución anterior de la prueba se hayan corregido, que los cambios
realizados no introduzcan nuevos o viejos defectos” (p. 33).
1.5.1.3 Pruebas automatizadas:
Estas pruebas son realizadas por el equipo de QA por medio de herramientas de automatización
que permiten crear código fuente (scrips), donde estos serán ejecutados por medio de instrucciones de
comandos en el terminal o consola (hardware) con el fin que el robot de automatización realice las tareas
indicadas de acuerdo con los casos de pruebas diseñados en el respectivo plan de prueba.
Entonces, es importante señalar que la automatización:
20

Consiste en la construcción de un conjunto de scripts reutilizables, con los que podemos aumentar
drásticamente la capacidad de testear software en lo que respecta a pruebas de regresión antes y
después de la publicación de una nueva versión. (Blasco, 2012).
1.5.1.3.1 Beneficios de las pruebas de automatización:
Cuando se realizan pruebas automatizadas se pueden obtener una serie de beneficios, los cuales se
exponen en la figura 5.
Figura 5
Beneficios de las pruebas automatizadas.

Fuente: Elaboración propia a partir de Software Testing Berau (2019).
1. Es posible realizar un gran número de pruebas en un breve período de tiempo, permitiendo
mayor cubrimiento de código y de casos, por lo que se logran pruebas muy exhaustivas y precisas
de la funcionalidad y más condiciones probadas.
2. Devops es una importante tendencia en la construcción de software moderno. Tiene como
objetivo agilizar el proceso de liberación de software, buscando responder rápidamente a las
exigencias de los negocios. En ese escenario, que las pruebas estén automatizadas, resulta vital
para acelerar todo el proceso de entrega, ya que permite, en forma temprana, encontrar y corregir
fallas o realizar mejoras oportunamente antes de la salida a producción.
21

3. Las pruebas automatizadas multiplican la capacidad de los equipos de testing. Minimizan
bastante la ejecución de las pruebas manuales, necesitando estas últimas solo en escenarios
especiales.
4. Al optimizar el tiempo invertido en pruebas y liberar a los recursos humanos de tareas
repetitivas, se gana en productividad, ya que estos estarán con la disponibilidad para seguir
aportando estrategias y análisis para la calidad del negocio.
5. Para pruebas de regresión, la automatización es ideal, ya que se podrán ejecutar las pruebas una
y otra vez a medida que el software evolucione, asegurando consistencia y que todo lo que
funcionaba en la versión anterior, seguirá funcionando en la nueva.
6. Se logra ganar experiencia y resultados rápidamente, facilitando la inducción de nuevos
integrantes al equipo de testing y evitando la dificultad de tener que ejecutar pruebas sobre
diferentes aplicaciones.
7. Las pruebas automatizadas facilitan la precisión a la hora de diagnosticar la falla detectada.
Sin duda alguna, una vez identificados los beneficios de la automatizaciónse expone cuándo y en
qué casos se debe aplicar este tipo de pruebas.
Crespo (2018) dice que “Las pruebas están diseñadas para funcionalidades concretas - fueron
pensadas para agilizar una parte del proyecto, no para gestionar toda la calidad del código”
Estas pruebas se pueden implementar en los proyectos de software de acuerdo con la metodología,
los tiempos y costos; otro aspecto importante es que más allá de automatizar o no, se debe comprender el
contexto.
En ese sentido, el analista de automatización QA determina qué casos de prueba se beneficiarán
más con la automatización.
De acuerdo con Lowenthal (2020), los casos de pruebas para automatizar son:
22

● Los repetitivos que se ejecutan para varias compilaciones.
● Aquellos que tienden a provocar errores humanos.
● Los que requieren múltiples conjuntos de datos.
● Funcionalidad de uso frecuente que presenta condiciones de alto riesgo.
● Casos de pruebas imposibles de realizar manualmente.
● Casos que se ejecutan en varias configuraciones y plataformas de hardware o software diferentes.
● Aquellos que requieren mucho esfuerzo y tiempo cuando se realizan pruebas manuales.
Para los casos mencionados se ejecutan en API REST e interfaz de usuario (UI).
1.5.1.4 Pruebas api rest:
Se realizan cuando se requiere probar el comportamiento de un sistema por medio instrucciones
de comando (solicitudes) con diferentes datos de entrada, con el fin de validar el resultado esperado de
acuerdo con la petición realizada, además para confirmar la comunicación que se tiene con otros módulos
o servicios.
Según Glenn (2020), “Las API rest permiten que dos o más aplicaciones se comuniquen entre sí,
además de permitir a los usuarios ordenar programas para obtener los resultados deseados”.
Al realizar las pruebas Api Rest hay multiplex herramientas para su creación y ejecución tales
como se observa en la figura 6.

Figura 6
Herramientas para la ejecución de pruebas Api Rest

Fuente: Elaboración propia (2022)
1.5.1.5 Pruebas interfaz de usuario (UI):
Se realizan en un sistema que cuenta con una interfaz gráfica donde ya se han integrado los
diferentes componentes que componen al sistema, por lo tanto, se valida los posibles flujos diseñados de
acuerdo con los requisitos funcionales solicitados por el usuario.
Además, “Para asegurar el correcto funcionamiento del sistema y su interfaz es necesario realizar
pruebas de interfaz, que ejecutan acciones sobre la GUI tal y como lo haría un usuario final y evalúan sus
resultados” (Catón et al., 2019).
Al momento de realizar las pruebas de interfaz de usuario las empresas ofrecen al analista de QA
diversas herramientas que facilitan y agilizan la implementación de estas, tales como se muestra en la
figura 7.

Figura 7
Herramientas de automatización UI.
Fuente: Elaboración propia (2022).
Por otro lado, con el fin de facilitar el proceso de automatización hay una variedad de frameworks
(entorno de trabajo) que ayudan a que el código de automatización de pruebas sea reutilizable, mantenible
y estable; entre estos encontramos el frameworks de Serenity. En ese sentido, Parada (2019) afirma que:
Se trata de un framework basado en Java que se integra a la perfección con herramientas de
desarrollo como Cucumber y JBehave. Está diseñado para facilitar la escritura de pruebas
automáticas de aceptación y regresión pues también le permite abstraer gran parte del código
repetitivo que a veces necesita escribir para comenzar a usar herramientas como Selenium
WebDriver.
De acuerdo con lo anterior, Cucumber permite elaborar casos de pruebas basados en
comportamiento del usuario, ya que se trabaja por medio de la metodología Behaviour Driven
Development (BDD), la cual es escrita en lenguaje Gherkin siendo legible por el área de negocio.
Una característica de Cucumber, es que los casos de pruebas elaborados por el analista QA son
orientados al negocio, permitiendo que personas que no tengan conocimientos técnicos o de programación
puedan comprender su estructura (Talaigua, 2019).
25

A continuación, se muestra en la figura 8 la traducción al lenguaje Gherkin.
Figura 8
Código del lenguaje Gherkin

Fuente: Talaigua (2019) https://www.pragma.com.co/blog/junit-vs.-cucumber-herramientas-de-
automatizacion-de-pruebas
Estos elementos ayudan a que los comportamientos vayan poco a poco bajando de nivel, hasta llegar a un
lenguaje que entiendan fácilmente los usuarios.
Sarco (2015) da un detalle de la sintaxis Gherkin:
● Feature (Característica)
El elemento feature proporciona el encabezado o el marco para el archivo feature. Tiene un título y un
texto con una descripción de alto nivel de la función de la aplicación que se detalla en el archivo. Contiene
el listado de scenarios que componen el feature.
● Scenario (Escenario)
Un Scenario es una lista de pasos que comienza con algunas de estas palabras claves:
• Given (|Dado|Dada|Dados|Dadas)
26

• When (Cuando)
• Then (Entonces)
• But (Pero) o And (Y)
• Background (Antecedentes)
Utilizamos el background para definir precondiciones para cada uno de los scenarios a correr y así no ser
repetitivos y focalizar los scenarios en la prueba especifica.
● Scenario Outline (Esquema del escenario)
Los Scenario outline permiten introducir variables en los scenarios y así simplificar pruebas que requieren
los mismos pasos pero que pueden tener datos variados. El Scenario outline va junto a la tabla Examples
(Ejemplos) donde se definen los valores de la variable en cada corrida.
Como se ha mencionado a lo largo del documento, la automatización de pruebas se realiza por
medio de herramientas y frameworks que al momento de escribir el código fuente para la ejecución de
casos de pruebas se le aplica un patrón de diseño, mismo que de acuerdo con Morales (2021) es:
Un patrón de diseño es una solución para un problema dentro de un contexto. En otras palabras,
los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el
desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Dicho esto, para la automatización implementar un patrón de diseño ayuda a crear proyectos de
calidad ya que se encarga de estructurar las clases creadas, para que el código sea legible por otros
analistas y así identificar como fue solucionado un problema.
Un patrón de diseño aplicable para la automatización de pruebas es ScreenPlay, puesto que al
igual que Cucumber está enfocado al desarrollo de software por comportamiento BDD y tiene un
arquetipo que ayuda a identificar las clases creadas por los casos de pruebas diseñados.
Se puede observar el arquetipo base con el patrón ScreenPlay en la figura 8.
27

Figura 9
Arquetipo patrón ScreenPlay

Fuente: Soto (2019) https://medium.com/@marcela.soto/automatizaci%C3%B3n-de-pruebas-funcionales-
serenity-bdd-screen-play-java-942be8217fca
Lo anterior permite elaborar un proyecto con las mejores prácticas de programación ya que
proporciona una estructura que todos los analistas del grupo logran entender, además permite tener una
estructura de código común a todos los proyectos que implemente una funcionalidad genérica.
Por último, al desarrollar este tipo de proyecto se debe implementar una metodología de trabajo
que permita cumplir con los objetivos planeados inicialmente; Scrum es una buena opción al momento de
https://medium.com/@marcela.soto/automatizaci%C3%B3n-de-pruebas-funcionales-serenity-bdd-screen-play-java-942be8217fca
https://medium.com/@marcela.soto/automatizaci%C3%B3n-de-pruebas-funcionales-serenity-bdd-screen-play-java-942be8217fca
28

trabajar de forma ágil al ser ideal para el desarrollo de software por su adaptabilidad en los diferentes
contextos de trabajo.
Borja (2020) indicó que:
Scrum es una metodología ágil que permite realizar proyectosmás orientados a las necesidades de
la empresa y de los clientes, de una forma más eficiente y en un menor plazo de tiempo, a través
de un marco de trabajo colaborativo que permite generar equipos de alta productividad.
Por lo expuesto, se considera una metodología que puede ser utilizada al momento de trabajar con
pruebas de automatización.
Otros autores como Schwaber y Sutherland (2017) afirman que Scrum es “un marco de trabajo
por el cual las personas pueden abordar problemas complejos adaptativos, a la vez que entregar productos
del máximo valor posible productiva y creativamente”.
Dentro de la metodología Scrum se encuentra diferentes perfiles o roles, estos cumplen una serie
de actividades, tales como:
Product Owner: es la voz del cliente dentro del proyecto. Trabaja en definir los objetivos y
asegurarse de que se lleven a cabo. También debe estar disponible para responder a todas las
preguntas del equipo.
Scrum Master: es la persona encargada de resolver los problemas que puedan surgir dentro del
equipo para que el trabajo sea productivo. Ayuda al equipo y aconseja al Product Owner para
maximizar el retorno de la inversión (ROI) en el proyecto.
Scrum Team: esta figura es clave, ya que la conforma el equipo que desarrolla y entrega los
proyectos al cliente, por lo que se requiere de una buena coordinación para trabajar con la máxima
eficacia posible. (Euroforum, 2019).
29

Para el desarrollo de scrum se realiza una serie de eventos con el fin de minimizar reuniones
extensas y no organizadas, que permitan al equipo fomentar la comunicación y colaboración en un tiempo
determinado, eventos denominados Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint
Retrospective.
Por otro lado, en el marco de trabajo Scrum se encuentran tres artefactos principales que son: el
Product Backlog, Sprint Backlog e incremento. Según Bara (2017) en los artefactos “Se conocen todos
aquellos elementos que garantizan la transparencia y el registro de la información clave del proceso de
Scrum. Es decir, son los recursos que sientan las bases para la calidad y la productividad de cualquier
proyecto”.
Para finalizar, Scrum ofrece un gran resultado para las empresas que deseen implementarlo ya que
beneficiará tanto a los clientes como al equipo de trabajo. De acuerdo con Viewnext (2019) Scrum es
“Una metodología de trabajo con innumerables beneficios para cumplir tus objetivos con mayor eficacia y
con mejor retorno de la inversión”.
30

1.5.2 MARCO CONCEPTUAL.
Los presentes conceptos son importantes para el desarrollo del proyecto al ser fundamentales en la
construcción del lineamiento de la automatización:
1.5.2.1 Lineamiento técnico y operativo:
Es el programa o plan de acción que rige a cualquier institución. De acuerdo a esta aceptación, se
trata de un conjunto de medidas, normas y objetivos que deben respetarse dentro de una organización
(Pérez y Gardey, 2021).
Así mismo, Son los elementos del más alto nivel de la Estrategia Organizacional, cuyo propósito
es alinear el comportamiento de todos los miembros de la Organización hacia un horizonte y Visión
compartida (Torres, 2016).
1.5.2.2 Implementación:
Consiste en hacer funcionar a los responsables de las diferentes actividades para que realicen las
operaciones que se fijaron en el plan, por lo que, la implementación es una etapa clave de la gestión de
proyectos, ya que se ponen a funcionar las políticas, disposiciones y esquemas que quedaron
contemplados en la planificación (Flórez, 2019).
También, es un proceso continuo que comienza con un esquema de participación auténtica que
transforma la cultura, estructuras y sistemas de trabajo de toda la organización (PAD 2021).
1.5.2.3 Empresa desarrolladora de software:
Se caracteriza por ser una empresa de programación, cuya misión es el desarrollo de software para
el cliente final o para un tercero, a través de servicios profesionales tecnológicos, utilizando las buenas
prácticas de trabajo colaborativo para entornos simples a complejos, con requisitos específicos o
cambiantes y poco definidos (QuestionPro 2017).
Es un equipo especializado en últimas tecnologías y desarrollo de software, compuesto por
múltiples perfiles que conjugan múltiples experiencias (diseñadores gráficos, ingenieros, analistas de
calidad, etc…), con la capacidad de comprender en detalle los procesos internos y externos de un cliente o
servicio, interpretarlos y transformarlos en funcionalidades, en software o un sistema (Esquerra, 2014).
31

1.5.2.4 Pruebas del software:
Son un conjunto de procesos con los que se pretende probar un sistema o aplicación en diferentes
momentos para comprobar su correcto funcionamiento. Este tipo de pruebas abarca cualquier estadio del
desarrollo del sistema, desde su creación hasta su puesta en producción (Turrado, 2020).
Se trata básicamente del conjunto de actividades dentro del desarrollo de un software permitiendo
así tener procesos, métodos de trabajo y herramientas para identificar oportunamente los defectos en el
software, logrando la estabilidad del mismo. Siendo el único instrumento capaz de precisar la calidad de
un producto de software, es decir, es el único procedimiento con el que se puede garantizar que un
software cumple con los requerimientos solicitados por los usuarios (Fycgrouo 2020).
1.5.2.5 Plan de pruebas de software:
Un plan de pruebas es la herramienta general de los profesionales dedicados a QA y a Testing y
define el marco de trabajo en el que deben de apoyarse para que su trabajo sea efectivo y adecuado a lo
largo de toda la vida del proyecto y del ciclo de vida del software (QALovers, 2019).
Describe el ámbito del esfuerzo de prueba general y proporciona un registro del proceso de
planificación de prueba. Puede configurarse el plan de pruebas para que se ajuste a las necesidades del
equipo. Normalmente, un plan de pruebas identifica los requisitos, riesgos, casos de prueba y entornos de
prueba que hay que probar, los objetivos de negocio y calidad, las planificaciones de prueba y otros
elementos (IBM, 2015).
1.5.2.6 Casos de pruebas:
Conjunto de entradas de prueba, condiciones de ejecución, y resultados esperados desarrollados
con un objetivo particular, tal como el de ejercitar un camino en particular de un programa o el verificar
que cumple con un requerimiento específico (IEE610).
Es la condición establecida sobre una funcionalidad a bajo nivel del aplicativo para determinar su
corrección; es decir, el cumplimiento del resultado esperado en base a las directrices que nos marque el
funcional. Para cada caso de prueba se debe definir el campo en el que se realiza (el contexto de la
prueba), descripción de la acción, y finalmente su resultado deseado (Prats, 2019).
32

1.5.2.7 Ejecución de pruebas:
Es la actividad en la que se especifican los procedimientos o guiones de prueba mediante la
comunicación de los casos de prueba en un orden determinado y la inclusión de cualquier otra
información necesaria para la ejecución de las pruebas, se configura el entorno y se ejecutan las pruebas
(ISTQB, 2010).
Puede realizarse de manera manual o automatizada; en cualquiera de los casos, cuando se detecte
un fallo en el sistema, este debe ser documentado y registrado en una herramienta que permita gestionar
los defectos (Bug Tracker). Una vez el defecto ha sido corregido por la firma desarrolladora en su
respectivo proceso de depuración, es necesario realizar un re-test que permita confirmar que el defecto fue
solucionado de manera exitosa (Zapata, 2013).
1.5.2.8 La automatización:
Se puede definir como un sistema donde se trasfieren tareas de producción, realizadas
habitualmente por operadores humanos a un conjunto de elementos tecnológicos, es decir, se reemplazan
las actividades o tareas realizadas por seres humanos por máquinas o robots que las desarrollan conmayor
precisión, frecuencia y/o calidad, normalmente (Londoño, 2018).
Consiste en el uso de sistemas de software para crear instrucciones y procesos repetibles a fin de
reemplazar o reducir la interacción humana con los sistemas de TI. El software de automatización
funciona dentro de los límites de esas instrucciones, herramientas y marcos para realizar las tareas con
muy poca intervención humana (RedHat, 2021).
1.5.2.9 Pruebas de rendimiento:
Las pruebas de rendimiento son pruebas de carga y estrés que se realizan bajo
una serie de peticiones sobre el sistema que está siendo evaluado, lo cual genera un volumen denominado
anormal de recursos, de esta manera el evaluador establecerá hasta qué punto el sistema deja de responder
(Ruiz, 2016).
Un conjunto de pruebas que se realizan para determinar si un servicio IT atiende a sus usuarios
dentro de unos parámetros de calidad de servicio (tiempo de respuesta, disponibilidad), ante unas
33

condiciones determinadas del sistema de información número de usuarios, tipo de peticiones, tiempo
(Medina, 2014).
1.5.2.10 Interfaz de usuario (UI).
Una interfaz de usuario es el medio por el cual una persona controla una aplicación de software o
dispositivo de hardware. Esto significa que el programa incluye controles gráficos que optimizan la
experiencia de usuario usando un mouse o teclado (Lenis, 2021).
La interfaz de usuario o UI (User Interface) es un concepto que abarca arquitectura de
información, patrones y diferentes elementos visuales que nos permiten interactuar de forma eficaz con
sistemas operativos y softwares de diversos dispositivos (Corrales, 2019).
1.5.2.11 API (interfaz de programación de aplicaciones).
Es el conjunto de protocolos y definiciones que se usan para integrar y desarrollar el software de
las apps. La finalidad de las API es unir sus productos y sus servicios con otros sin saber cómo se
implementan, lo que ayuda al desarrollo de las apps además de ahorrar tiempo y dinero (Rojas, 2021).
El término API es una abreviatura de Application Programming Interfaces, que en español
significa interfaz de programación de aplicaciones. Se trata de un conjunto de definiciones y protocolos
que se utiliza para desarrollar e integrar el software de las aplicaciones, permitiendo la comunicación entre
dos aplicaciones de software a través de un conjunto de reglas (Fernandez, 2019).
1.5.2.12 framework.
Es un entorno de trabajo que tiene como objetivo facilitar la labor de programación ofreciendo
una serie de características y funciones que aceleran el proceso, reducen los errores, favorecen el trabajo
colaborativo y consiguen obtener un producto de mayor calidad (Rodríguez, 2020).
Se trata de una plantilla o esquema conceptual que sirve para organizar y desarrollar un software
determinado. El objetivo de los frameworks es hacer más sencilla la programación ofreciendo grandes
ventajas para los programadores ya que permite automatizar multitud de procesos (Viewnext, 2021).
34

1.5.2.13 El BDD (desarrollo guiado por el comportamiento)
Es una metodología ágil propuesta por Dan North que va un paso más allá del TDD (desarrollo
guiado por pruebas de software). El propósito de esta metodología es que se comprenda más a los Product
Owner, desarrolladores, testers y cualquier otra parte involucrada, colaborando entre ellos mientras los
reúnes en torno a un lenguaje común (Corrales, 2020).
Es un enfoque muy potente para implementar proyectos de software, ya que permite cruzar el
puente existente entre los perfiles de negocio (sin conocimientos técnicos pero con amplio conocimiento
del producto que se está desarrollando así como de aspectos más económicos del mismo, como puede ser
el retorno de la inversión) y los perfiles técnicos, que somos todos aquellos encargados del desarrollo del
proyecto pero que tenemos poco conocimiento del área de negocio del proyecto que estamos
desarrollando (Gordillo, 2021).

1.6 METODOLOGÍA DE LA INVESTIGACIÓN
1.6.1 Tipo de estudio.
El presente estudio tiene como fundamento la investigación aplicada, misma que de acuerdo con
Lozada (2014) tiene como objetivo:
La generación de conocimiento con aplicación directa y a mediano plazo en la sociedad o en el
sector productivo. Este tipo de estudios presenta un gran valor agregado por la utilización del
conocimiento que proviene de la investigación básica (P.35).
En ese sentido, este tipo de investigación permite que el investigador se nutra de datos sustraídos
de fuentes secundarias para su posterior organización y análisis, generando conocimiento al orientar a las
empresas desarrolladoras de software respecto a la incorporación de la automatización de pruebas en sus
procesos.
1.6.2 Método de investigación.
El método de investigación será de tipo inductivo, Abreu (2014), indica que, “mediante este
método se observa, estudia y conoce las características genéricas o comunes que se reflejan en un conjunto
de realidades para elaborar una propuesta o ley científica de índole general”.
Así las cosas, una problemática particular como lo es la automatización de pruebas se convierte en
algo general al ser un insumo de uso cotidiano por parte de la empresa desarrolladora de software, motivo
por el cual la propuesta que se genera tiene dicho alcance al poder replicarse no solamente en una empresa
especifica si no en diferentes empresas con similar misionalidad.
1.6.3 Fuentes y técnicas para la recolección de la información.
Teniendo en cuenta que el presente estudio no requiere fuentes de información primaria al
construir desde la revisión y análisis documental se recurre a las fuentes secundarias mediante la
búsqueda, organización, clasificación y análisis de textos académicos, artículos, revistas informáticas,
cursos online, tesis y en general una revisión bibliográfica en relación con el tema que atañe al estudio.
36

1.6.4 Tratamiento de la información.
Para el análisis y tratamiento de la información se debe recurrir a la búsqueda de esta para
seleccionar aquellas que es relevante y útil para el proyecto y extraer la que ayude en la consolidación del
objetivo. En ese sentido, la revisión de la literatura es el aspecto central para categorizar, organizar y
analizar la información.

PARTE II. DESARROLLO DE LA INVESTIGACIÓN
CAPÍTULO 2. PROCESO PARA EL AREA DE AUTOMATIZACIÓN
2.1 FLUJO DE PROCESO DE QA AUTOMATIZACIÓN
Para dar inicio al proceso de automatización se recomienda que el analista encargado de realizar las
pruebas funcionales manuales haya finalizado sus respectivas pruebas y que estas no cuenten con bugs por
solucionar, ya que así el analista de automatización puede dar inicio al siguiente plan de trabajo:
Entradas Proceso Salidas
Requerimientos o
Historias de Usuarios
Planear: se plantea una manera
óptima de cómo realizar las pruebas
y que pruebas son válidas para el
proyecto
Plan de estrategia de pruebas
Casos de prueba
Hacer: Se diseñan los casos de
prueba basados en los
requerimientos o las Historias de
Usuario.
Script de pruebas
Ejecución de pruebas
Informe de bugs a desarrollo (Si se
evidencia)
Cierre de bugs (Reportados)
Verificar: Se valida que los casos
de pruebas diseñados obtuvieron el
resultado esperado de acuerdo con
los requerimientos o las historias de
usuario.
Reporte del resultado de la ejecución de
pruebas Automatizadas
Actuar: Se entrega los reportes de
las pruebas con su respectivo
análisis.
Entregable de la automatización.
Tabla 1. Procesos QA automatización.
38

Figura 10
Flujo de proceso de QA automatización

Fuente: Elaboración propi (2022)
39

2.2 PLAN DE AUTOMATIZACIÓN DE PRUEBAS
Portada
<Nombre del proyecto>

Tabla 2. Visualización portada.
1. Objetivo general
El propósito de realizar la automatización de las pruebas funcionales de <Nombre dela Aplicación o
Proyecto> se realiza con el fin de disminuir el esfuerzo y el tiempo que se emplea para realizar las
validaciones correspondientes cuando se realizan actualizaciones en la aplicación, así como la corrección
de bugs generados por la implementación de nuevas funcionalidades.

VERSIÓN AUTOR JUSTIFICACIÓN DE LA MODIFICACIÓN
1.0
Nombre del Autor
Cargo
Creación del documento
ELABORÓ REVISÓ APROBÓ
Nombre:
_______________________
Nombre:
________________________
Nombre:
_______________________
Cargo:

Cargo:

Fecha:

2. Alcance
Se detallarán cuáles serán las funcionalidades que se automatizarán y cuales no están incluidas dentro del
plan de pruebas.
2.1 Alcance de las pruebas
2.1.1 Funcionalidades por probar
Se planea realizar la automatización de las siguientes funcionalidades de <Nombre de la aplicación o
Proyecto>
• Listado de funcionalidades que se contemplarán.
• Ejemplo: Login
• Registro de usuarios nuevos
• Ingreso al home
• Pasar Plata
2.2.2 Funcionalidades fuera del alcance
las siguientes funcionalidades de <Nombre del proyecto o Aplicación> no serán incluidas dentro de la
automatización de pruebas:
• Listar funcionalidades que no serán contempladas
• Contenido Menú Hamburguesa
• Sacar Plata
• Captura de QR
Indicar los motivos por los que no es posible automatizar estas funcionalidades.
3. Criterios de aceptación o rechazo
El criterio de aceptación para dar por completado el plan de pruebas será:
Completar el 100% de la automatización de los casos de prueba correspondientes a las funcionalidades que
están dentro de la cobertura.

4. Criterios de suspensión
Las pruebas serán suspendidas en el caso en que existan fallos que impidan la correcta automatización de
las funcionalidades.
5. Entregables
Se entregará como parte de la ejecución del plan los siguientes entregables:
• Casos de prueba – Test Link y Features
• Evidencias de pruebas (Reporte de Serenity)
• Proyecto de automatización en Bitbucket documentado
6. Planificación y organización
Cronograma (revisar para proyectos en desarrollo)
La siguiente tabla contiene la estimación en tiempo (horas) que tendrán las actividades relacionadas con la
automatización de las funcionalidades:
Actividad Tiempo estimado por actividad Tiempo total
Actualización login # horas # horas
Creación de categoría # horas # horas
Cargue del proyecto en bitbucket # horas
# horas
Otras actividades (Errores no esperados) # horas
Tabla 3. Estimación.
El estimado en días para la realización de las actividades descritas anteriormente es de <# de días>

7. Dependencias y Riesgos
A continuación, se listan los riesgos asociados con el proceso de automatización:
• Dependencias con otros proyectos.
• Disponibilidad de recursos.
• Restricciones de tiempo.
• Premisas que resulten no ser ciertas.
• Cualquier otra dependencia o riesgo identificado antes de la ejecución del proyecto.

8. Formula tiempo estimado:
Assumptions:
* Time by service consideres a service with around 10 fields and not too complex
objects. A service with 20 elements will cost double time
* Each scenario represents a single Test Case.
* Preparation time must be considered, it's added in the total hours and days
* Services must be documented

Micro Name
# of
flows
# of
Services
Total
SMT
Total
SCT
Total Aut.
Time Risk
Total
hours
Total
Days
registro 5 2 2 5 7 2.1 9.1 1.1375
2 13 1 1 6.5 7.5 2.25 9.75 1.21875
3 7 1 0.5 3.5 4 1.2 5.2 0.65
4 7 1 1 3.5 4.5 1.35 5.85 0.73125
5 8 1 0.5 4 4.5 1.35 5.85 0.73125
6 5 1 0.5 2.5 3 0.9 3.9 0.4875
7 13 1 0.5 6.5 7 2.1 9.1 1.1375
Total 54.75 6.84375

Tabla 4. Visualización formulación de estimación parte 1.

Assumptions:
* Time by screen consideres a screen with 5 elements inside. A screen with 10 elements
will cost double time
* Each scenario represents a single Test Case.
* Preparation time must be considered, it's added in the total hours and days

Functionality
# of
flows
# of
Screens
Total
SMT
Total
SCT
Total Aut.
Time Risk
Total
hours
Total
Days
Login 3 8 4 12 16 4.8 20.8 2.6
Recarga paquete 3 26 13 39 52 15.6 67.6 8.45
Biotacora 2 12 6 12 18 5.4 23.4 2.925
Total 117.8 14.725
Tabla 4. Visualización formulación de estimación parte 2.
App/Web Tasks Hours
Screens mapping time (SMT) 0.50
Scenarios creation time (SCT) 0.50
Preparation task 6

Service Tasks Hours
Service modeling time (SMT) 1.00
Scenarios creation time (SCT) 0.50
Preparation task 6
Tabla 4. Visualización formulación de estimación parte 3.

2.3 ESTRATEGIA DE PRUEBAS AUTOMATIZADAS
Portada
Tabla 5. Visualización portada de estrategia de pruebas automatizadas
1. Tabla De Contenido
✓ Introducción
✓ Alcance
✓ Objetivo
✓ Responsabilidades
✓ Ambientes y herramientas de prueba
✓ Riesgos y Planes de contingencia
✓ Ambiente y herramientas de pruebas
a. Herramientas de prueba
VERSIÓN
AUTOR JUSTIFICACIÓN DE LA
MODIFICACIÓN
1.0 Nombre Creación del documento
ELABORÓ REVISÓ APROBÓ
Nombre:

Nombre:

Cargo:

Fecha:

b. Arquitectura de automatización
c. Ambiente de pruebas
✓ Criterios de entrada y salida
a. Criterios de entrada
b. Criterios de salida
✓ Planificación de ejecución de las pruebas
✓ Reportes de pruebas
2. Introducción
En esta estrategia de automatización se describe principalmente el alcance de las pruebas, el ambiente, las
herramientas, los riesgos, el plan de contingencia, metodología, lenguaje de programación, framerworks;
los cuales van a ser abordados de acuerdo con el tipo de proyecto en el que se esté desarrollando el proceso
de automatización.
3. Alcance
Principalmente, se realizarán pruebas de caja negra (automatizadas), a las funcionalidades establecidas en
la ceremonia de planeación de cada proyecto y que serán abordadas en cada uno de los sprint sugeridos para
el inicio de la automatización.
Las funcionalidades para automatizar se escogerán utilizando los criterios de lista de chequeo que se
acuerden con los analistas funcionales y de acuerdo con la guía de estimación para automatización.
4. Objetivos
• Establecer las características y aspectos necesarios descritos por el analista para iniciar el proceso
de pruebas automatizadas.
• Identificar las necesidades del proyecto del por qué es necesario la automatización de las pruebas.
47

• Describir desde el inicio del proyecto las herramientas y criterios de entrada para la creación de
los casos automatizados en las diferentes funcionalidades.
5. Responsabilidades
• Planeación y monitoreo de las pruebas automatizadas.
• Diseño e implementación de las pruebas.
• Ejecución de los casos de prueba automatizados.
• Reporte de defectos con anticipación.
• Reporte e informe del progreso de las pruebas.

2.4 AMBIENTE Y HERRAMIENTAS DE PRUEBA
1. Herramientas de pruebas
Herramientas necesarias para iniciar el proceso de automatización para cada uno de los proyectos ya se
móvil o Web.
Herramientas Función
Selenium WebDriver API para automatización de los dispositivos
móviles y sistemas web.
JUnit Framework para la ejecución de los casos
de prueba.
Generación de reporte de pruebas.
NodeJS Entorno de ejecución multiplataforma del
servidor
Appium Herramienta de automatización para
plataformas móviles.
Gradle / Maven Creación de la estructura del proyecto y uso
de importación de librerías por medio de
dependencias.
Serenity BDD Herramienta para la generación de tests
automatizados y reportesJDK java Compilador de aplicaciones java
Eclipse/IntellijIDE IDE de plataforma de software para los
proyectos a automatizar.
RestAssured/Serenity-Rest Herramienta para automatización de APIS
Cucumber Herramienta para la creación tests basados
en lenguaje Gherkin.
49

Appium Desktop
Tabla 6. Herramientas para la automatización.
2. Ambientes de pruebas
Ambiente Descripción
Sistemas operativos WINDOWS
MAC
Dispositivos Móviles IOS
ANDROID
Navegadores Firefox
Chrome
Edge
Safari
Tabla 7. Ambientes De Pruebas
3. Criterios de entrada y salida
a) Criterios de entrada:
• Las funcionalidades deben estar desplegadas en el ambiente de QA y haber sido probadas
manualmente.
• El framework de pruebas está instalado y listo para la ejecución.
• El ambiente de QA está disponible.
• Los defectos críticos encontrados durante las pruebas manuales han sido resueltos y cerrados.
b) Criterios de salida
• Ejecución de todos los casos de pruebas automatizados.
• Se ha logrado la suficiente cobertura de los requerimientos y funcionalidades bajo pruebas.
• Ningún defecto de severidad alta se encuentra abierto.
50

2.5 PLANIFICACIÓN DE EJECUCIÓN DE LAS PRUEBAS
1. Inicio
Las pruebas de automatización normalmente comenzarán en la segunda semana del Sprint y de ahí en
delante de acuerdo con la duración del sprint se irán adicionando nuevas funcionalidades.
Es necesario que las funcionalidades a automatizar se desarrollen, implementen y prueben manualmente
para que tengan un nivel determinado de estabilidad cuando comienzan las tareas de automatización.
Las suites de regresión se ejecutarán al final de cada Sprint (antes de la Revisión del Sprint), al realizarse
un cambio o por solicitud de los Clientes, Product Owner y Project Manager.
2. Reporte de errores
Si se encuentra un error asociado a la ejecución de las pruebas automatizadas, se deberá reportar en la
herramienta de gestión de prueba con el que cuente la organización, como por ejemplo (Jira, ADS, Mantis,
entre otras). El automatizador será el responsable del reporte y la gestión del incidente.
Una vez el incidente sea solucionado se debe realizar el retest y dar cierre al caso.
3. Creación y diseño de casos de prueba
Para la creación de los casos de prueba se deben tener en cuenta algunos criterios:
1. Casos o escenarios contemplados en las pruebas de aceptación de usuario.
2. Casos o escenarios repetitivos.
3. Casos o escenarios particulares complejos que toman mucho tiempo durante el testing manual.
Los casos de prueba automatizados deben tener como objetivo final realizar una verificación de
información, esto quiere decir que siempre se debe contemplar realizar aserciones para verificar los datos
de entrada y salida, así como también validar la integridad de los datos.

Ejemplo:
Scenario: Create a note on Notes app.
Given User is on the app
When User creates a new note
Then User sees the note created (Aserción)

La aserción valida no solo será la creación de una nota, sino que verifica que la información que
ingresamos en los pasos anteriores sea la correcta.
4. Arquitectura
Este apartado define la estructura, el flujo de trabajo y los principios básicos que se deben seguir al momento
de desarrollar pruebas automatizadas:
• Patrón de diseño: Serenity BDD “ScreenPlay”: nos ayuda a seguir un protocolo de organización de
paquetes y clases diferenciándonos 5 elementos principales: actores, habilidades, interacciones,
preguntas y tareas.

Figura 11.
Patrón de diseño: Serenity BDD “ScreenPlay”

Fuente: Ferguson (s,f) http://thucydides.info/docs/serenity-staging/
• Buenas prácticas de programación: Uso y claridad de los principios SOLID, definición de actores
y escenarios.
• Especificación de Historias de usuario: Cucumber (lenguaje Gherkin).
5. Nombramiento y redacción de artefactos.
El insumo principal para la codificación de artefactos son las historias de usuario y escenarios redactados
en leguaje Gherkin, por lo anterior se tienen las siguientes consideraciones en cuanto a nombramiento:
5.1 Idioma.
• Las historias de usuario y escenarios deben ser redactados en inglés o español (esto deberá definirse
desde el principio del proyecto). El idioma principal debe ser inglés. No se deben mezclar, si el
proyecto inicia en español debe continuar así.
53

• El nombramiento de clases, variables y métodos se deben redactar en inglés o español según como
se defina al inicio del proyecto. No se deben mezclar, si el nombramiento se inició en español se
debe continuar así.
5.2 Buenas prácticas para la redacción de los features.
• Se deben redactar en tercera persona
• Deben ser concisos, no deben ser muy extensos
• No deben tener muchos detalles técnicos, el lenguaje debe estar orientado más a negocio.
• Separar los features por funcionalidades
• Reutilizar los escenarios para evitar duplicidad de código
• Se deben crear tablas o utilizar un listado de usuarios para replicar tests con distintos usuarios.
• Documentar los features con descripción, reglas de negocio, escenarios, precondiciones y demás
elementos que correspondan.
5.3 Nombramiento de clases, métodos y variables.
Se debe garantizar que la lectura del código sea clara y legible haciendo uso del parafraseo, siendo este
consecuente con el nombramiento de clases y métodos.
No se recomienda utilizar caracteres ortográficos cómo tildes, diéresis, coma y demás caracteres especiales
en la redacción de las características
El nombramiento de todos los artefactos debe ser escrito con el estándar camelcase, es decir primera letra
en mayúscula o minúscula según sea el caso como se describe a continuación:

5.4 Nombramiento de clases.
Se debe hacer uso del estándar:
• UpperCamelCase: Primera letra de cada una de las palabras es mayúscula y en singular.
Ejemplo:
• Public class Producto {} //Se aplica la forma “UpperCamelCase”
• Public class ProductoCasa {} //Se aplica la forma “UpperCamelCase”
5.5 Nombramiento de métodos
Se debe hacer uso del estándar:
• lowerCamelCase: Primera letra es minúscula. Ejemplo: ejemploDeLowerCamelCase.
Ejemplo: Public consultarProducto () { } //Se aplica la forma “lowerCamelCase”
5.6 Nombramiento de constantes
Se debe declarar el nombre en mayúscula sostenida, si el nombre es compuesto, se debe separar con el
carácter de guion al piso “_”.
Nota: Todas las variables declaradas en el paquete “ui” son constantes, para la declaración de estas se debe
poner como prefijo el tipo de elemento que se está declarando, seguido del nombre del campo.
Estructura y ejemplo:
Public Static final <Tipo de variable><NOMBRE DE VARIABLE>
• Public Static final Target LBL_USUARIO = Target.the("lbl_usuario");

5.7 Nombramiento de variables globales o de clase
Se debe hacer uso del estándar:
• lowerCamelCase: Primera letra es minúscula.
Ejemplo: ejemploDeLowerCamelCase.
• <Tipo de variable> <nombre de la variable>
• String nombre;
• Int saldoCalculado; //forma compuesta
5.8 Elementos Web/Mobile
• Para el nombramiento de elementos se sugiere la siguiente lista:
Elemento Prefijo
Botón btn
Calendar cal
Check Box chk
Combo Box cmb
Dialog dlg
Label lbl
Link lnk
List box lst
Menu mnu
Progress bar prg
Radio Button rbt
Spinner spn
56

Tabla tbl
Texto txt
Tabla 8. Elementos Web/Mobile
5.9 Estructura de proyectos
Cada uno de los proyectos de automatización debe contar con las especificaciones descritas en este apartado,
de esta manera se es consecuente con los lineamientos definidos a lo largo de este proceso y garantizamos
unicidad en todos los proyectos de automatización.
Estructura proyecto Web/Mobile
src main
assembly zip.xml
Configuración de empaquetamiento para AWS
Device Farm
Java
ui
Almacena las clases en las cuales semapean los
elementos de la interfaz de usuario, inputs o
botones
interactions
Se encargan de las interacciones con la interfaz
de usuario. Ej, Open, Click, Enter...
tasks
Clases que son acciones de alto nivel que definen
un conjunto de interacciones en el lenguaje de
negocio
questions
Gestionan los Asserts o verificaciones de las
pruebas las cuales son el fin último de las mismas
exceptions
Mapeo de respuestas para los questions con
información más diciente y controlada
utils Clases de utilidad general
dao Clases para conexiones a bases de datos
57

abilities
Clases para añadir habilidades a un actor, ej:
navegar, invocar un servicio
test
Java
runners Clase para la ejecución de los features y steps
steps
Gestiona los fragmentos de código definidos en
el Given, Then, When de los escenarios de los
archivos .feature.
resources features
Contiene los escenarios o casos de prueba
basados en las HU
Tabla 9. Estructura proyecto Web/Mobile
5.10 Gestión de código fuente.
Se utilizará como cliente de versionamiento ‘Git’, por tal motivo cada analista de automatización debe
tenerlo instalado y configurado.
5.11 Políticas de versionamiento y ramificación para Automatización.
El versionamiento de los diferentes aplicativos de automatización, se gestionará por medio de Git y para
cada repositorio se ha definido una ramificación específica que debe cumplir con la siguiente estructura:
5.12 Branchs principales
Cada repositorio creado de acuerdo al que se encuentre habilitado en la organización, debe contener por lo
menos estas ramas creadas para automatización:
5.13 Master: Esta rama contiene las funcionalidades que se encuentran en producción, para realizar
cambios sobre esta rama será necesario tener en cuenta lo siguiente:
• Se deberá realizar un Pull Requests partiendo desde la rama development hasta la rama master,
dicha petición será revisada y aprobada por el líder de automatización del proyecto.
58

5.13 Development: Esta rama contiene las nuevas funcionalidades desarrolladas y es en esta donde se
integran todos los desarrollos que se estén realizando para esa solución, para realizar cambios sobre esta
rama será necesario tener en cuenta lo siguiente:
• Se deberá realizar un Pull Requests, partiendo desde la rama Feature hasta la rama development,
dicha petición será aprobada por el equipo de desarrollo.
5.14 Branchs secundarias
5.14.1 Feature: Esta rama es única para cada equipo de trabajo, es decir, esta rama se creará por
demanda, pueden existir varias al mismo tiempo, tantas como funcionalidades o iniciativas se están
desarrollando y cada equipo será el responsable de su correcta actualización. Esta contiene todas las nuevas
funcionalidades desarrolladas por un equipo de trabajo en particular, cabe aclarar que las ramas feature son
creadas desde la rama development.
Figura 12. Fujo GitHub

Elaboración propia (2022)

5.15 Descripción y estándar de los commits
Se debe realizar una descripción breve y concisa del cambio o funcionalidad que se está subiendo al
repositorio, por ejemplo:
• Cambios de HU del Sprint: "Se actualiza funcionalidad <funcionalidad>, se anexa <feature,
StepDefinitions, Runner, otros>".
5.16 Caracterización de los repositorios de trabajo
El proyecto base de cada aplicativo, debe ser cargado a la rama principal “Master” y debe contener los
siguientes elementos:
• ‘Readme’, archivo que detalla el proyecto que se está trabajando y demás información que se
considere necesaria especificar, este archivo debe ser actualizado cada que se añadan nuevas
funcionalidades, esto con el fin de que el analista que haga uso del proyecto pueda identificar los
flujos que hay actualmente automatizados y de esta manera evitar duplicidad de código.
• ‘Git ignore’, archivo en el que se define que extensiones de archivo o directorios se consideran no
deben ser cargados al repositorio, por ejemplo, la carpeta de evidencias.
Nota: no debe ser cargados en el repositorio los siguientes archivos:
• Evidencias de ejecución de pruebas (Directorio target generado por SerenityBdd) o Drivers de
navegadores u otros archivos ejecutables. Hace referencia al Index.html
• Archivos resultantes de procesos de compilación (archivos con extensión .class) o Metadatos de las
configuraciones propias del entorno de trabajo local, como lo son: .idea - .iml - .settings entre otros.
• Librerías externas descargas por cada entorno de trabajo.

5.17 Riesgos y planes de contingencia
A continuación, se describen algunos planes de contingencia para tener en cuenta cuando ocurra algo
inesperado a la hora de realizar el proceso de automatización:
No Riesgos Plan de Contingencia
1 Funcionalidades no terminadas en el
tiempo estimado no pueden formar
parte de los escenarios contemplados
para automatizar en el sprint.
Re-planificar funcionalidades para ser
automatizadas.
2 Solicitud de cambios en aquellas
funcionalidades que ya tienen casos de
pruebas automatizadas. Esto ocasiona
retrabajo debido a que se deben
actualizar estos scripts.
Estimar el tiempo del cambio y volver a
priorizar la lista de funcionalidades a ser
automatizadas en el sprint.
3 Solución y dedicación a errores que se
encuentren en el proceso de
automatización
Implementar el siguiente protocolo:
• Investigación autónoma.
• Consultar con el equipo de QA.
• Consultar con los desarrolladores a
cargo del proyecto.
En promedio se sugiere que se dedique un
máximo de 3 horas, si en este tiempo, no se
encuentra una solución, dejarlo pendiente,
comunicar a líder de QA y avanzar con otro
flujo.
Tabla 10. Riesgos y planes de contingencia
61

2.6 REPORTE DE PRUEBAS
El Reporte automático de pruebas se obtendrá a través del documento generado por Serenity BDD. Este, se
encuentra en la siguiente ruta:
“Nombre del proyecto”\target\site\serenity\Index.html
Para revisar el entregable, ver archivo (Entrega pruebas automatizadas).

Entrega de pruebas automatizadas

<<Nombre del Proyecto>>
1. Objetivo
El propósito de este documento es describir el conjunto de pruebas que se automatizaron sobre el ambiente
<<Ambiente de pruebas >>, las cuales se realizaron de acuerdo con el dev de pruebas entregado por el
analista funcional teniendo en cuenta las funcionalidades definidas para el proyecto <<Nombre del
proyecto>>
2. Alcance de las pruebas
Se detalla las funcionalidades que se automatizaron con su respectivo resultado y cuales quedaron fuera del
alcance de acuerdo con el dev de pruebas.

3. Dev de pruebas
3.1 Casos de pruebas dentro del alcance:
FEATURE CASOS DE
PRUEBAS
PORCENTAJE DE
EJECUCIÓN
TIEMPO DE EJECUCIÓN
(MIN/SEG)
Login 8 100% 4Min 30Seg
Crear
usuario
4 80% 1Min 20Seg
Tabla 11. Casos de pruebas dentro del alcance
Feature : Login
ESCENARIO RESULTADO ESPERADO RESULTADO
Ingresar con credenciales
validas
Ingreso exitoso EXITOSO
Ingresar con credenciales
invalidas
Ingreso fallido EXITOSO
Ingresar con usuario bloqueado Ingreso fallido FALLIDO
Tabla 12. Casos de pruebas detallados dentro del alcance
2.2 Casos de pruebas fuera del alcance:
• Feature : Login
ESCENARIO NOMBRE RESULTADO
ESPERADO
RESULTADO DESCRIPCIÓN
Ingresar a la
plataforma
Ingresar con usuario
Administrador
Ingreso exitoso FUERA DEL
ALCANCE
No se logra realizar
la ejecución ya que
63

no se cuenta con los
datos de usuario
administrativo
Tabla 13. Casos de pruebas fuera del alcance
• Feature: Crear usuario
Escenario Resultado esperado Resultado Descripción
Crear usuario contable Usuario creado
correctamente
FUERA DEL
ALCANCE
No se logra crear el
usuario contable, el
código no cuenta con id
para la creación.
Tabla 14. Casos de pruebas detallados fuera del alcance

PARTE III. CIERRE DE LA INVESTIGACIÓN