aseguramiento de la calidad en los productos learning, new

Aseguramiento de la calidad en los productos Learning, New Learning, Coaching,

Community, Motivation y Channels de la suite de Playvox.

Diego Alexander Chavarria Posada

Informe de práctica para optar al título de Ingeniero de Sistemas

Asesora

Astrid Duque Ramos, Doctor (PhD) en Ingeniería Informática

Universidad de Antioquia

Facultad de Ingeniería

Ingeniería de Sistemas

Medellín, Antioquia, Colombia

2021

Cita Chavarria Posada [1]

Referencia

Estilo IEEE (2020)

[1] D. A. Chavarria Posada, “Aseguramiento de la calidad en los productos Learning,

New Learning, Coaching, Community, Motivation y Channels de la suite de Playvox.

”, Trabajo de grado profesional, Ingeniería de Sistemas, Universidad de Antioquia,

Medellín, Antioquia, Colombia, 2021.

Centro de Documentación Ingeniería (CENDOI)

Repositorio Institucional: http://bibliotecadigital.udea.edu.co

Universidad de Antioquia - www.udea.edu.co

Rector: John Jairo Arboleda Céspedes.

Decano/Director: Jesús Francisco Vargas Bonilla

Jefe departamento: Diego José Luis Botía Valderrama.

El contenido de esta obra corresponde al derecho de expresión de los autores y no compromete el pensamiento

institucional de la Universidad de Antioquia ni desata su responsabilidad frente a terceros. Los autores asumen la

responsabilidad por los derechos de autor y conexos.

https://co.creativecommons.org/?page_id=13

https://co.creativecommons.net/tipos-de-licencias/

Dedicatoria

Este logro es dedicado a las personas mas importantes de mi vida, quienes siempre me han dado

su amory su apoyo. Mis padres Patricia y Manuel. Este es el fruto de tantos sacrificios, por eso

este logro no es solo mío, si no principalmente de ellos.

Agradecimientos

A mis padres Patricia y Manuel por su amor, por tantos sacrificios, por guiarme con ejemplo en

cómo ser una buena persona y por ser mi soporte y apoyo para cumplir mis sueños.

A mis Abuelos y familiares por sus consejos, por la motivación y por siempre estar ahí.

A la Universidad de Antioquia, los docentes y compañeros por contribuir a mi formación como

persona y como profesional.

A la profesora Astrid Duque y a Ángelo Quintero quienes con su asesoría, profesionalismo y

consejo contribuyeron al éxito de este proyecto.

A Playvox por brindarme la oportunidad de desarrollar allí mi práctica y contribuir a mi

crecimiento profesional. Un especial agradecimiento a Andrés Navarrete y a mis compañeros del

equipo Mavericks por todas sus enseñanzas.

Al Taekwondo, mis maestros y compañeros de tantas batallas, por forjar mi carácter, por tantas

experiencias vividas, su contribución a tantos sueños cumplidos y por enseñarme siempre a

enfrentar la vida con espíritu indomable.

A mi novia Mayra por su apoyo y por acompañarme en los momentos felices y difíciles de la

vida.

A mis amigos por alegrarme la vida y compartir tantos momentos.

TABLA DE CONTENIDO

RESUMEN ....................................................................................................................................... 7

ABSTRACT ..................................................................................................................................... 8

I. INTRODUCCIÓN ........................................................................................................................ 9

II. PLANTEAMIENTO DEL PROBLEMA .................................................................................. 10

III. JUSTIFICACIÓN ..................................................................................................................... 11

IV. OBJETIVOS ............................................................................................................................ 12

A. Objetivo general .................................................................................................................... 12

B. Objetivos específicos ............................................................................................................. 12

V. MARCO TEÓRICO .................................................................................................................. 13

VI. METODOLOGÍA .................................................................................................................... 16

VII. RESULTADOS Y ANÁLISIS ............................................................................................... 18

VIII. CONCLUSIONES ................................................................................................................. 29

REFERENCIAS ............................................................................................................................. 31

LISTA DE FIGURAS

Fig. 1. Proceso de testing definido por la empresa……………………………………………… 16

Fig. 2. Diseño de prueba en mapa mental para probar una nueva funcionalidad……………….. 19

Fig. 3. Creación de cursos en el módulo de learning……………………………………………..20

Fig. 4. Nodos finales del mapa mental con las marcas de prueba………………………………..20

Fig. 5. Reporte de un bug en Jira…………………………………………………………………21

Fig. 6. Ejecución de una prueba automatizada………………………………………………….. 23

Fig. 7. grabación de un flujo para ser automatizado……………………………………………...24

Fig. 8. Issues creados en los releases 1 y 2……………………………………………………….25

Fig. 9. Issues creados en el tercer release………………………………………………………...26

Fig. 10. Severidad de los issues en el tercer release……………………………………………...26

Fig. 11. Ambientes y bugs en el cuarto release…………………………………………………..27

Fig. 12. Ambientes y bugs en el quinto release…………………………………………………..27

Fig. 13. Issues totales creadas en Jira durante la ejecución de la práctica………………………..28

SIGLAS, ACRÓNIMOS Y ABREVIATURAS

QE Quality Assurance (En Playvox)

E2E End to End

SaaS Software as a Service

ISO International Organization for Standardization

IEC International Electrotechnical Commission

API Application Programming Interfaces

UX User Experience

ASEGURAMIENTO DE LA CALIDAD EN LOS PRODUCTOS LEARNING, NEW LEARNING… 7

RESUMEN

Playvox es una suite que se centra en la optimización de agentes de call centers, por medio

de un conjunto de herramientas y servicios que buscan mejorar el desempeño de los agentes, a

través de la gestión de la calidad con el módulo de quality, la creación de diferentes cursos según

la necesidad con los módulos de learning, entre otros. Playvox ha tenido un aumento considerable

en la demanda, incorporando importantes clientes y haciendo cada vez más necesario desarrollar

nuevas funcionalidades que le permitan seguir siendo vigente en su mercado. En el proceso de

desarrollo, surgen errores que en caso de llegar a producción impactan negativamente a los

usuarios, así como a la imagen del producto, es por esto que surge la necesidad de asegurar la

calidad del software, lo cual también ha sido identificado por estudios hechos en la empresa.

Detectar la mayor cantidad de errores en etapas tempranas del ciclo de pruebas, buscando que

lleguen menos errores a producción es una prioridad para Playvox. Este proyecto tiene como

objetivo asegurar la calidad en los productos Learning, New Learning, Coaching, Community y

Channels de la suite, para lo cual se realizan pruebas manuales, las cuales incluyen pruebas

funcionales de los features desarrollados, pruebas de regresión, E2E, pruebas de integración,

pruebas smoke y pruebas exploratorias. Adicionalmente, el apoyo al equipo de QE (calidad) en el

desarrollo de scripts de pruebas de regresión automatizadas y la detección e identificación de flujos

para ser facilitados a una empresa externa que trabaja en la automatización de pruebas para

Playvox.

Palabras clave — Calidad, Pruebas de software, Playvox, Releases


ABSTRACT

Playvox is a suite that focuses on the optimization of call center agents, through a set of

tools and services that seek to improve the performance of agents, through quality management

with the quality module, the creation of different courses according to the need with the learning

modules, among others. Playvox has had a considerable increase in demand, incorporating

important clients and making it more and more necessary to develop new functionalities that allow

it to remain in force in its market. In the development process, errors arise that in case of reaching

production negatively impact users, as well as the image of the product, which is why there is a

need to ensure the quality of the software, which has also been identified by studies made in the

company. Detecting as many bugs as possible in early stages of the testing cycle, so that fewer

bugs reach production is a priority for Playvox. This project aims to ensure the quality of the

Learning, New Learning, Coaching, Community and Channels products of the suite, for which

manual tests are performed, including functional tests of the developed features, regression tests,

E2E, integration tests, smoke tests and exploratory tests. Additionally, support to the QE team in

the development of automated regression test scripts and the detection and identification of flows

to be provided to an external company that works in test automation for Playvox.

Keywords — Quality, Software tests, Playvox, Releases.


I. INTRODUCCIÓN

Playvox es un SaaS (Software as a Service) constituido por un conjunto de soluciones para

optimizar el desempeño de los agentes de Call Center. En este software se puede hacer

aseguramiento de la calidad de las interacciones entre los clientes y las empresas, llevar una gestión

del rendimiento de los agentes, mejorar las habilidades de los mismos a través de sesiones

brindadas en el módulo de coaching y diferentes cursos los cuales se pueden dictar en los módulos

Learning de Playvox. También permite brindar reconocimiento y motivación a través de premios,

y favorecer las interacciones entre agentes, líderes y personal de los call center a través de los

módulos Community y Channels. En la actualidad la empresa viene en un crecimiento exponencial,

incorporando grandes clientes como Nike, Electronic Arts, Dropbox entre otros, lo cual lleva a una

necesidad de constante actualización e innovación con el fin de que Playvox continúe siendo el

software para gestión de calidad en los call centers mejor calificado.

Los errores en la suite de Playvox que llegan a producción afectan la experiencia de usuario y

pueden ser un factor determinante en el éxito o fracaso de la compañía, y ante el momento actual

expansión de la misma la calidad del software juega un gran papel. Reducir la cantidad de errores

que llegan a producción y que estos se detecten en etapas tempranas del ciclo de vida del software

mejora el rendimiento del equipo de desarrollo y permite que este se enfoque en innovar el producto

creando nuevas características que lo hagan ser competitivo y no en la corrección de errores en

etapas tardías del ciclo de vida del software. Una buena estrategia de pruebas es primordial para

esto y por ello en la empresa se vienen implementando pruebas manuales de los diferentes features

generados por el equipo de desarrollo, pero el principal inconveniente con estas es que son lentas,

además que se tiene un porcentaje muy bajo de pruebas automatizadas (alrededor del 10%). Con

esta propuesta se pretende apoyar los procesos de testing en tareas relacionadas con las pruebas

automatizadas (desarrollo de scripts de automatización con Cypress, diseño y documentación de

casos de pruebas con el fin de ser facilitados a los automatizadores contratados por la empresa),

diseñar y ejecutar pruebas manuales (feature, regresión, de integración, E2E) en cada uno de los

releases, contribuyendo con la disminución de errores en el producto detectados en etapas tardías

y el aumento de la cobertura de pruebas automatizadas, lo cual es una prioridad en el área de

ingeniería actualmente.


II. PLANTEAMIENTO DEL PROBLEMA

A medida que Playvox incorporaba nuevos clientes, crecía el número de usuarios y con

ellos el uso de la plataforma. Esto sumado a la necesidad de incorporar nuevos desarrollos y

mejoras que generen valor a los nueve módulos que componen la suite llevó a que la empresa

pasara de hacer un release cada tres meses, a uno por mes, y con ello a que los clientes encontraran

constantemente errores en producción, que en la empresa son conocidos como bugs escapados.

Esto causa insatisfacción y frustración en los clientes dados los posibles fallos que pueden causar

estos errores.

Adicionalmente la empresa no contaba con el suficiente personal en el equipo de calidad para

atender a los requerimientos de verificación y validación del software, ni con pruebas

automatizadas, lo cual hacía que el proceso de testing no fuera óptimo y que en ocasiones fuera el

mismo equipo de desarrollo el que tuviera que apoyar al equipo de QE en el testeo del software,

con lo cual el proceso de desarrollo perdía ritmo de entrega.


III. JUSTIFICACIÓN

Para Playvox es muy importante seguirle entregando valor al cliente, para ello se duplicó el

número de desarrolladores, se aumentó el número de releases. Y para poder reducir el número de

bugs encontrados en producción, buscando que estos sean detectados en etapas tempranas del

desarrollo era necesario implementar una estrategia de testing que responda a esta velocidad

requerida. Por ello en este proyecto se apoya a la empresa en todo el proceso de testing manual en

las diferentes etapas del release, aplicando diferentes pruebas tales como las Smoke, pruebas

funcionales, E2E, pruebas de regresión. Y se apoya al equipo en el proceso de automatización de

pruebas, tanto en el desarrollo de scripts, como en la documentación de procesos para la

codificación de las mismas. Todo esto con el fin de asegurar la calidad del producto.


IV. OBJETIVOS

A. Objetivo general

Asegurar la calidad en los productos Learning, New Learning, Coaching, Community y

Channels de la suite de Playvox.

B. Objetivos específicos

• Diseñar casos de prueba para feature y regression tests manuales.

• Implementar los feature y regression tests manuales.

• Implementar pruebas E2E manuales

• Desarrollar pruebas automatizadas para el módulo de New Learning.

• Documentar la ejecución de cada uno de los ciclos de pruebas.


V. MARCO TEÓRICO

La calidad en un sistema de software es el grado en el que este satisface las necesidades declaradas

e implícitas de sus diferentes interesados o stakeholders, proveyendo valor y satisfaciendo sus

necesidades en torno a este. La calidad se puede medir en torno a 8 características definidas en el

estándar ISO/IEC 25010, las cuales son: adecuación funcional, eficiencia de desempeño,

compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad.[1]. Las

necesidades son manifestadas a través de requerimientos o requisitos de software, los cuales se

definen como una o varias propiedades que deben ser exhibidas por un sistema de software, con el

fin de resolver un problema en el mundo real. Estas soluciones de software pueden tener variados

fines, tales como la automatización de tareas, el apoyo de procesos empresariales en una empresa,

el control de algún tipo de dispositivo (Desde que esto se pueda hacer con software) o corregir las

deficiencias y falencias de un software. Una propiedad esencial de los requisitos de software es que

estos deben ser verificables como una característica individual o “feature” (Conocidos como

requisitos funcionales) o a nivel del sistema (conocidos como requisitos no funcionales) [2]

En Playvox el cumplimiento de los requisitos es constatado y verificado por el equipo de QE

(calidad) a través de procesos de verificación y validación. La primera se define como el proceso

de evaluar un sistema o componente del mismo con el fin de determinar si los productos de una

fase o desarrollo satisfacen las condiciones impuestas y definidas al inicio de ésta fase. La

validación por su parte, se define como el proceso de evaluar un sistema o componente, durante o

al final del proceso de desarrollo con el fin de determinar si satisface o no los requisitos

especificados.[3] Para hacer verificación y validación, en Playvox se tienen definidas actualmente

estrategias de pruebas, así mismo, en el equipo Mavericks (en el cual se trabajan los módulos de

learning, new learning, coaching, community, channels, motivation) se ejecutan los siguientes tipos

de pruebas:

• Pruebas unitarias: Son un proceso en el cual se mide una unidad de prueba, frente a sus

requisitos. Esta unidad de prueba puede ser una pequeña función o un conjunto de unidades


cohesivas. En el proceso de pruebas unitarias se incluye la planificación de la prueba, la

adquisición de un conjunto de datos, la ejecución y la medición de la misma.[4]

• Pruebas de humo (smoke tests) son un tipo de pruebas que son ejecutadas en Playvox una

vez el ambiente es recreado. En estas se verifica todo el sistema de extremo a extremo, sin

ser exhaustivo. La finalidad de este tipo de pruebas es verificar si la plataforma es estable

para proceder a probarla más a fondo. [5]

• Pruebas de integración: Se definen como un tipo de prueba en el cual se verifica que las

interacciones entre los módulos y las interfaces sean correctas. Son aplicadas cuando todos

los módulos o componentes son combinados para formar un programa funcional. [6]

• Pruebas de regresión: Son un tipo de prueba que se aplica después que un programa es

modificado, con el fin de restablecer nuestra confianza en que el software sigue

funcionando bien después de los cambios y acorde a las especificaciones modificadas del

mismo. [7]

• Pruebas End to End (E2E): Son un tipo de pruebas en el que también se verifica sobre un

sistema, desde el punto de vista del usuario que el objeto de prueba (sistema) esté

funcionando bien, a diferencia de las pruebas de integración que son similares, pero las

cuales se enfocan en las interacciones entre componentes.[8]

• Pruebas exploratorias: Se definen como un aprendizaje, diseño de prueba y ejecución de

prueba de manera simultánea. Los tests no se tienen definidos en un plan establecido, y son

dinámicamente diseñados, ejecutados y modificados. El conocimiento del sistema por parte

del ingeniero de software puede derivar en el éxito de este tipo de estrategia de pruebas. [9]

Las principales herramientas de apoyo para llevar a cabo estas estrategias de pruebas son:

• Jira: Es una familia de productos los cuales son diseñados específicamente para el software,

las TI, entre otro tipo de empresas. Ayuda a todo tipo de equipos con la gestión de la

planificación, asignación de tareas, supervisión, elaboración de informes y gestión de

trabajo. En el equipo de desarrollo y calidad de Playvox usamos Jira Software, el cual ayuda

a los equipos ágiles a lanzar software de primer nivel. [10]

• Cypress: Es un framework basado en Javascript con el cual se pueden configurar, escribir,

ejecutar y hacer debug de pruebas, principalmente E2E. [11]


• K6 Software: Es un framework de pruebas open source, en el cual se pueden automatizar

pruebas de carga y rendimiento. Estas pruebas están escritas en lenguaje Javascript. [12]

• Mindmeister: Es una herramienta de mapas mentales, basada completamente en la web y

que permite capturar, desarrollar y compartir ideas visualmente. [13] En el equipo de

calidad de Playvox se usa esta herramienta para la creación de mapas mentales que apoyan

el proceso de testing en el diseño de las pruebas.

• Gitlab: Es una plataforma de DevOps open source que permite crear un flujo de trabajo de

software optimizado, ya que se entrega como una sola aplicación. [14]

• Postman: Según el sitio oficial “Es una plataforma API para construir y usar APIs

simplificando cada paso del ciclo de vida de las APIs” [15]


VI. METODOLOGÍA

Para el desarrollo del proyecto, inicialmente se hizo un onboarding o entrenamiento en el

área de QE (calidad) en el cual se dió un repaso general a la teoría de las pruebas de software, se

dieron a conocer los diferentes tipos de pruebas que se llevan a cabo en la empresa (funcionales,

de integración, regresión, E2E, además de las unitarias, las cuales son llevadas a cabo por los

desarrolladores) (Ver figura 1) a la vez que se conocía la suite completa de Playvox. Todo esto de

la mano del líder del equipo de QE y los diferentes analistas de calidad de la empresa. En esta etapa

inicial también se dieron a conocer las diferentes herramientas en las cuales se apoya el equipo de

QE para su funcionamiento, junto con la estrategia de Branching en Git.

Fig. 1. Proceso de testing definido por la empresa.

Luego de tres semanas de entrenamiento general en calidad, se hizo la asignación a uno de los

cuatro equipos que componen el área de ingeniería, y en el cual se desarrollaría la práctica, para el

caso de este proyecto el equipo Mavericks, el cual se encarga de los productos Coaching, learning,

channels y community. Allí, de la mano de un Analista de QE se hizo un entrenamiento específico

en el cual se conocieron más en detalle los mencionados productos, a su vez que se conoció a

profundidad el proceso que se lleva a cabo en el equipo para testear las diferentes funcionalidades

y soluciones a errores.


Junto con el analista, para los cinco releases planeados durante la ejecución de este proyecto, se

llevaron a cabo feature test, en los cuales se probaban las diferentes funcionalidades entregadas por

los desarrolladores, para ello previamente se hacía un diseño de la prueba a modo de mapa mental

en la herramienta Mindmeister, luego de considerar todos los posibles casos de prueba, se recreaba

un ambiente exclusivo para el equipo con todos los features añadidos a la rama de desarrollo del

Gitlab y se ejecutaba la prueba manual del mismo, recorriendo los diferentes flujos planteados en

el mapa mental y tomando evidencia de ello en un documento de evidencias, por lo general una

hoja de Google Docs. En caso de encontrar algún bug, se clasificaba según una escala interna de

Prioridad y severidad que indican qué tan rápido se debe atender el bug y se registraba el mismo

en Jira. Una vez se tenía el ticket creado, se notificaba al desarrollador sobre el mismo.

Una vez todos features estaban testeados, se procedía a hacer una regresión en la misma rama, y

en la cual se verifica que los cambios introducidos no hayan alterado alguna de las otras

funcionalidades, y si todo estaba bien, se daba paso al ambiente de release, donde se hacía mezcla

con las funcionalidades y cambios introducidos por los otros equipos. Allí se llevaba a cabo un Full

testing compuesto por pruebas funcionales y de regresión (similares a las ejecutadas en la etapa

anterior), pruebas smoke, que verificaban que la aplicación cargaba bien después de la mezcla,

pruebas E2E que son “Caminos felices” de las funcionalidades y de los diferentes módulos y

pruebas de integración. Una vez todo estaba testeado en esta rama y solucionados los errores de

mayor prioridad, se daba paso al ambiente de producción, para lo cual al momento del despliegue

se hacían pruebas smoke en las que se verifica que todo cargue bien.

A la par que se apoyaba al equipo en las pruebas manuales, también se llevaba a cabo el proceso

de automatización de las pruebas, lo cual es una prioridad para la compañía. Para ello se

desarrollaron algunos scripts de regresión usando la herramienta Cypress, orientados al módulo de

Learning. Además, se apoyó este proceso con la creación de vídeos de los diferentes flujos que se

prueban tanto en pruebas de regresión como para pruebas E2E. Esto se hacía con una herramienta

de desarrollo propio de la empresa que detecta los diferentes llamados a APIS en cada una de las

interacciones con la página y que permite tener un detalle de estos para una fácil automatización,

llevada a cabo por una empresa tercera.


VII. RESULTADOS Y ANÁLISIS

Como resultado de estas prácticas se logró apoyar al equipo Mavericks en 5 releases. En

cada uno de estos se llevó a cabo una estrategia de pruebas manuales, la cual era abordada de la

siguiente manera:

Diseño de caso de prueba: Este comenzaba con la lectura de la historia de usuario en Jira, en la

cual el equipo de producto incluía una descripción de la misma y se tenían registrados los criterios

de aceptación. En ocasiones también se adjuntaban diseños de las funcionalidades definidas en

conjunto entre el equipo de producto y el equipo de UX. Todo esto se tomaba como insumo para

elaborar un mapa mental en la herramienta Mindmeister, en el que se ubicaba como nodo central

el número del ticket de la issue en Jira junto con un nombre descriptivo corto, de allí se desprendían

diferentes nodos, los cuales trazan el camino a seguir en la plataforma para probar los diferentes

criterios de aceptación definidos en la historia de usuario. El diseño de mapas mentales se abordó

desde el primer release el cual se hacía acompañado por el analista de calidad del equipo y luego

de manera autónoma, pero contando con la revisión posterior por algún otro QE del equipo.

Se diseñaron mapas mentales para todas las nuevas funcionalidades entregadas por el equipo de

producto al equipo de desarrollo. En la figura 2 se muestra una de ellas, la cual consistía en añadir

imágenes a las respuestas de los comprehension check (pequeñas preguntas que aparecen durante

una lección), con el fin de tener más elementos visuales para entrenar personal.


Fig. 2. Diseño de prueba en mapa mental para probar una nueva funcionalidad.

Una vez se contaba con el diseño de la prueba, se creaba un tag en gitlab, a partir de la rama de

desarrollo (develop) y con el cual se recreaba un ambiente en el cual se ejecuta el feature test.

La prueba comenzaba con la creación de la data, en módulo de learning se creaban cursos con

contenido variado acorde al feature que se probaría, para el caso del feature test mencionado en la

etapa de diseño de pruebas, se creaban cursos que incluyeran actividades de texto enriquecido,

actividades de video y quices, y en cada uno de estos tipos de actividades se creaban comprehension

checks que contuviera imágenes en sus respuestas, en la figura 3 se muestra la vista en el módulo

de learning en el cual se permiten crear cursos. Este proceso de creación de data se hizo de manera

repetitiva durante cada uno de los releases y para cada una de las funcionalidades a testear este era

un proceso que consumía gran parte del tiempo destinado para la prueba, ya que debía considerar

la mayor cantidad de escenarios posibles.


Fig. 3. Creación de cursos en el módulo de learning.

Durante la ejecución de la prueba, en los nodos finales del mapa mental (que son los casos de

prueba) se añadían diferentes iconos de colores según el estado del componente. El verde

constataba el funcionamiento correcto del criterio de aceptación, el rojo indicaba que se encontró

un error que debía ser reportado y el amarillo indicaba que hay dudas en este criterio que debían

ser validadas con el equipo. Todo esto se hacía con el fin de tener una trazabilidad de la prueba de

las funcionalidades. En la figura 4 se pueden apreciar los nodos finales de uno de los mapas

mentales, con los respectivos colores marcados al momento de ejecutar la prueba.

Fig. 4. Nodos finales del mapa mental con las marcas de prueba.


Se da por aprobado el feature test de la funcionalidad cuando se cumplen todos los criterios, en

caso contrario se crea un ticket para el bug en Jira en cual el nombre de la issue debía ser descriptivo

y conciso, indicando brevemente entre llaves el lugar donde fué encontrado, se añadía una

descripción detallada, el comportamiento actual y el comportamiento esperado de la funcionalidad.

También se añadía evidencia del error, lo cual podían ser pantallazos del error en la plataforma o

un video donde se explicaba el comportamiento a detalle. Se le añadía la prioridad, severidad y el

tipo de bug. Una vez era creado el ticket, era reportado al equipo para la gestión y atención del

mismo. En la figura 5 se puede ver a detalle la vista final de un ticket creado para un bug detectado.

Fig. 5. Reporte de un bug en Jira.

Durante el primer release se tuvo la experiencia de mezclar las ramas de los cuatro equipos una vez

testeados y solucionados los bugs y pasar directamente al ambiente de “Release”. Sin embargo, al

comenzar con las pruebas de regresión se detectaron errores, por lo que en los siguientes releases

se incluía una prueba de regresión en el ambiente donde se hacía el feature test, con el fin de

detectar la mayor cantidad de errores antes de pasar a la siguiente rama; Una vez en esta, se procedía

a hacer un full testing, este se hizo para los 5 releases e incluía la ejecución de pruebas smoke para

verificar que los módulos de los cuales se encarga el equipo cargaran bien; Luego se hacía una

prueba de regresión siguiendo mapas mentales previamente creados en Mindmeister los cuales

incluían la totalidad de flujos de cada uno de los módulos, estos mapas ya existían y no se hicieron


modificaciones en estos mientras se desarrolló la práctica. Este proceso era repetitivo y se hacía

evidente la necesidad de tener pruebas automatizadas, ya que la ejecución de uno de estos ciclos

de regresión podría tardar entre dos y tres días involucrando en ocasiones a los tres miembros del

equipo de QE (solo para Mavericks), además si se detectaban errores con una prioridad P2, se hacía

necesaria la corrección de los mismos por parte del equipo de desarrollo y la ejecución de un nuevo

ciclo de pruebas, lo cual se evidenció en los tres primeros releases. En el cuarto release no se

detectaron errores P2 por parte del equipo, ya que se detectaron en la etapa previa.

Una vez ejecutada la prueba de regresión, se llevaba a cabo una prueba de integración en la cual se

probaban las APIS correspondientes a los módulos del equipo. Al momento de comenzar la

práctica, el equipo ya contaba con el diseño de los mapas mentales y se procedía a ejecutar pruebas

a las APIS en Postman. Todo el proceso se documentaba en hojas de google Docs.

De manera similar a la regresión se procedía con las pruebas E2E. Estas se hicieron para los 5

releases y se recorrían los flujos principales de Playvox. Cabe destacar que la mayoría de errores

se encontraban en la prueba de regresión, dada la exhaustividad de la misma.

Cuando se finaliza la etapa de full testing y se tienen los errores de prioridad P1 Y P2 solucionados,

la release manager programaba la fecha para la salida a producción, en la cual se mezclaban los

cambios a la rama master. Para este día se apoyaba al equipo con pruebas smoke de los ambientes

para validar que todo funcionara correctamente. Este proceso se hizo para los 5 releases.

También se abordaron las pruebas automatizadas de manera transversal a los releases con el

desarrollo de scripts de automatización usando Cypress que es una herramienta basada en

Javascript, para automatizar las pruebas de frontend (Regresión o E2E). Al comienzo de este

proceso se apoyó al equipo en la detección de flujos y casos de pruebas basados en los mapas

mentales existentes para la regresión, con esto se completó un listado a partir del cual el equipo

podía proceder con el desarrollo de la prueba automatizada.

Para el desarrollo de la prueba automatizada primero era necesario hacer un análisis del caso de

prueba, detectar las precondiciones y las validaciones necesarias, como también tener claro cuál


era el objetivo de la prueba, después a partir de la rama develop se creaba una nueva rama, en la

cual se codificaban los casos de prueba. En esta práctica se crearon dos scripts de automatización

que verifican el orden de las preguntas en una actividad de video, tanto en la vista del manager

(quien crea y administra los cursos) como en la vista de learner. En la figura 6 se puede apreciar la

ejecución de uno de los casos de prueba. En la parte derecha de la pantalla se ve la ejecución de la

prueba en el frontend, y en la parte izquierda se listan las peticiones, aserciones, creación de la data

y demás elementos que componen la prueba.

Fig. 6. Ejecución de una prueba automatizada.

También se apoyaba al equipo con la grabación de flujos de pruebas usando una herramienta de

desarrollo propio de la empresa, con la cual se listan todos los llamados a las APIS y se obtiene un

paso a paso detallado de los elementos a probar. Todo esto con el fin de que una empresa

automatizadora procediera más fácil, teniendo en cuenta los flujos detectados. En la figura 7 se

muestra uno de los flujos grabados, en el cual se crea un curso con todo tipo de actividades, y se

listan los llamados a las APIS al momento de guardar los cambios:


Fig. 7. grabación de un flujo para ser automatizado.

A continuación, se presentan los resultados obtenidos durante los cinco releases.

En el primer mes con el equipo se tuvieron dos releases o despliegues, uno de ellos inducía unos

cambios pequeños en algunas funcionalidades del módulo de learning, y un segundo que fue un

poco más crítico, dado que a nivel de desarrollo se alteraban componentes comunes a los 4 equipos

de ingeniería, tales como la unificación de componentes para carga de archivos, de manera

simultánea a la modificación de la forma como se cargaban los mismos a la aplicación. La ejecución

de feature tests en el ambiente de testing, y de regresiones y pruebas de feature exhaustivas en el

ambiente de release permitieron la detección de un alto número de bugs (15), tal como se puede

apreciar en la figura 8. Estos bugs fueron atendidos oportunamente por el equipo de desarrollo.


Fig. 8. Issues creados en los releases 1 y 2.

En el tercer release se detectaron 2 bugs escapados (detectados en producción) y 2 bugs durante el

feature test. En este, el equipo de desarrollo también estaba corrigiendo errores detectados en el

segundo release, por lo que se crearon varias subtareas en Jira para el testing de la solución a los

mismos, tal cual como se puede apreciar en la figura 9. La severidad de los bugs creados se puede

apreciar en la figura 10.


Fig. 9. Issues creados en el tercer release.

Fig. 10. Severidad de los issues en el tercer release.


En las figuras 11 y 12 se muestran los ambientes en los cuales fueron encontrados los bugs

(producción, release y feature test) junto con el tipo de bugs reportados para el cuarto y quinto

release respectivamente. En los gráficos se puede apreciar que la mayoría de los bugs fueron

encontrados en la etapa de feature test y para ello era fundamental un buen diseño de los casos de

pruebas, ya que al recorrer los flujos considerando todos los escenarios posibles se encuentran los

errores con facilidad. En particular para el quinto release se hicieron varios ciclos de pruebas en la

etapa de feature test, por lo cual, en release solo se reportó un escapado pero de muy baja prioridad

y severidad (P4, S4) y no involucraba funcionalidades asociadas a los features entregados.

Fig. 11. Ambientes y bugs en el cuarto release.

Fig. 12. Ambientes y bugs en el quinto release.

En la figura 13 se muestra el total de issues creadas en Jira relacionadas con esta práctica. En ella

se relacionan los bugs, los bugs escapados, tareas de manual testing, sub tareas, subtest, issues de

tipo automated testing; estas últimas creadas al inicio de cada sprint desde el tercer release

permitían llevar un registro del tiempo utilizado para tareas de automatización (creación de scripts

o registro de flujos). La figura también relaciona las issues de tipo task creadas para llevar un

registro del tiempo invertido en probar soluciones a bugs o escapados, además para adjuntar una

evidencia del testing de los mismos.


Fig. 13. Issues totales creadas en Jira durante la ejecución de la práctica.


VIII. CONCLUSIONES

Con la ejecución de este proyecto se logró reducir la cantidad de bugs detectados en etapas

tardías del release, a través de la detección oportuna de los mismos en la etapa del feature test, esto

apoyados con diseños de pruebas que trataban de abarcar todos los escenarios posibles y unas

pruebas exhaustivas de las funcionalidades entregadas.

La implementación de pruebas de regresión en la etapa de feature test (antes de pasar al ambiente

de release) fue beneficioso ya que en la ejecución de estas normalmente se encontraban fallos, dada

su rigurosidad y que abarcan muchos más escenarios de prueba. Esto facilitó una pronta respuesta

por parte del equipo de desarrollo en la atención a la corrección de los errores.

El uso de diferentes estrategias teóricas del diseño de pruebas, como por ejemplo las particiones de

equivalencia, o análisis de valores límite; sumado a escenarios de prueba donde se tengan en cuenta

todos los escenarios posibles hace que las pruebas sean efectivas, esto estuvo presente en muchas

ocasiones al momento de diseñar las mismas. De esta manera se pueden detectar bugs en etapas

tempranas de los releases, evitando la corrección de estos en etapas tardías, ya que esto es costoso

tanto en tiempo, como en recursos humanos.

Un stack de pruebas completo, que contemple pruebas funcionales, de regresión, E2E, de

integración, de smoke, entre otros, permite que un software sea confiable, inclusive puede aumentar

la efectividad del equipo de desarrollo, ya que la detección de errores a tiempo permite que el

equipo se pueda dedicar más tiempo a desarrollar nuevas funcionalidades que hagan la suite más

innovadora y no a corregir errores, lo que hace que el software se quede en una especie de

estancamiento. Esto se pudo apreciar sobre todo en los releases finales, en los cuales el equipo de

desarrollo estuvo generando muchas nuevas funcionalidades para la aplicación.

Aunque la ejecución de pruebas manuales puede ser efectiva, es un proceso lento y que requiere

llevar a cabo constantemente tareas repetitivas, por lo cual es más adecuado cambiar este tipo de

enfoque hacia uno automatizado, ya que esto incrementa considerablemente la productividad,

reduciendo los tiempos de testing.


Aunque en este proyecto no se vieron involucradas las pruebas unitarias, ya que de ellas se

encargaban los desarrolladores, se pudo apreciar la aplicación del concepto de la pirámide de Kohn,

en el cual se dice que las pruebas unitarias son menos costosas que las pruebas que verifican la UI,

y que una estrategia de pruebas debe tener una buena base de pruebas unitarias. En este caso en

Playvox, antes de comenzar con las pruebas de UI automatizadas (Regresión, E2E), ya se contaba

con una parte importante de pruebas unitarias lo cual evitaba que llegaran muchos más errores a la

etapa inicial de testing, gracias a la detección temprana de los mismos por parte de los

desarrolladores.


REFERENCIAS

[1] ISO, “ISO 25010.” https://iso25000.com/index.php/normas-iso-25000/iso-25010

(accessed Jun. 03, 2021).

[2] I. C. Society, Guide to the Software Engineering Body of Knowledge Version 3.0 (SWEBOK

Guide V3.0). .

[3] S. Engineering, S. Committee, C. S. Committee, and C. Society, IEEE Standard for System

and Software Verification and Validation, vol. 2012, no. May. 2012.

[4] IEEE, IEEE Standard for Software Unit Testing. IEEE Std 1008-1987, vol. 1987. 2009.

[5] S. Mcconnell, “Daily Build and Smoke Test,” IEEE Softw., vol. 13, pp. 143, 144, 1996,

[Online]. Available: https://doi.ieeecomputersociety.org/10.1109/MS.1996.10017.

[6] H. K. N. Leung and L. White, "A study of integration testing and software regression at the

integration level," Proceedings. Conference on Software Maintenance 1990, 1990, pp. 290-

301, doi: 10.1109/ICSM.1990.131377.

[7] H. K. N. Leung and L. White, "Insights into regression testing (software testing),"

Proceedings. Conference on Software Maintenance - 1989, 1989, pp. 60-69, doi:

10.1109/ICSM.1989.65194.

[8] W. T. Tsai, Xiaoying Bai, R. Paul, Weiguang Shao and V. Agarwal, "End-to-end integration

testing design," 25th Annual International Computer Software and Applications Conference.

COMPSAC 2001, 2001, pp. 166-171, doi: 10.1109/CMPSAC.2001.960613

[10] Jira, “Resumen de Jira | Productos, proyectos y alojamiento.”

https://www.atlassian.com/es/software/jira/guides/getting-started/overview (accessed Jun.

03, 2021).

[11] Cypress.io, “Open Source JavaScript Test Runner | cypress.io.”

https://www.cypress.io/features (accessed Jun. 03, 2021).

[12] K6, “k6 Documentation.” https://k6.io/docs/ (accessed Jun. 03, 2021).

[13] MindMeister ,"MindMeister: Online Mind Mapping and Brainstorming", 2021. [Online].

Available: https://www.mindmeister.com/. (Accessed Sep 14, 2021)

[14] GitLab, "What is GitLab?", 2021. [Online]. Available: https://about.gitlab.com/what-is-

gitlab/. (Accessed: Sep 14, 2021)


[15] Postman.com, "Postman", 2021. [Online]. Available: https://www.postman.com/.

(Accessed: Oct 01, 2021)

aseguramiento de la calidad en los productos learning, new

Documents