UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO

“CONTRIBUCIÓN DEL CONTROL DE CALIDAD

EN EL PROCESO DE INTEGRACIÓN
CONTINUA”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE

DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN I
.

POSTULANTE : Ines Eugenia Baina Veizaga

TUTOR : Msg. Richard Félix López Fulguera

Cochabamba – Bolivia

2018
 Dedico esta monografía a mi familia por el
apoyo en estos meses de estudio y por la paciencia
que tuvieron durante el tiempo de estudio.

2
Tabla de Contenido

Resúmen 6

Introducción 7

1. Generalidades 7

1.1 Antecedentes Generales 7

1.2 Antecedentes Específicos 8

2. Metodología 9

3. Marco Teórico 9

3.1 Fundamentos de Integración Continua 9

Figura 1. Integración continua 11

3.2 Entrega Continua 12

3.3 Despliegue continuo 13

3.4 Diferencia entre Integración Continua y Entrega Continua 14

3.5 Desarrollo y Operaciones 15

3.6 Tipos de pruebas 16

3.7 Automatización de casos de pruebas 17

4. Pruebas en el proceso de Integración Continua 18

4.1 Flujo de Integración Continua 18

4.2 Contribución de control de calidad al proceso de Integración Continua 19

4.3 Tipos de casos de pruebas ejecutados 20

4.4 Herramientas de Automatización de pruebas Continuas 22

4.5 Roles del ingeniero de calidad 25

4.6 Beneficios de las pruebas continuas 26

3
5. Resultados 27

5.1 Evaluación de resultados 27

6. Conclusiones 27

6.1 Interpretación de resultados en integración continua 27

6.2 Propuestas de mejoras a la ingeniería de calidad 28

7. Diccionario de términos 29

8. Bibliografía 29

4
Lista de Figuras

Figura 1 Integración continua 11

Figura 2 Entrega Continua 13
Figura 3 Flujo de despliegue continuo 14
Figura 4 Integración Continua vs Entrega Continua 15
Figura 5 Flujo de contribucion del control de calidad 20
Figura 6 Tipos de Pruebas 20
Figura 7 Casos de prueba ejecutados 21
Figura 8 Pruebas unitarias desarrolladas 22
Figura 9 Reporte de Cucumber. 23

5
 RESÚMEN

Integración Continua (CI) forma parte de las metodologías ágiles, su trabajo es facilitar a
los desarrolladores la integración del código entre el equipo, permite la creación del código en
tiempos muy frecuentes, para hacer que esto sea posible y fácil, debe existir un minucioso
control de calidad de software.

Llevar a producción un software o una nueva versión es una tarea delicada, para que
esto sea posible debemos usar un sistema de automatización que sea capaz de construir el
software y desplegarlo en servidores, pero que sólo permita esta puesta en producción cuando
las pruebas han sido ejecutadas exitosamente.

El proceso de Entrega Continua (CD) consiste en una compleja automatización de los

procesos de compilación, pruebas, actualización de servidores de producción y ajuste de
código.

Las Pruebas Continuas ayudan a mitigar el nivel de riesgo introducido por los cambios
creados con las modificaciones realizadas durante un sprint de desarrollo, es el ejecutar de
manera constante, selectiva o completa las pruebas de software automatizadas que se tengan
para las diferentes fases del ciclo de vida del Software. Se pretende identificar la contribución
de estas pruebas en el ciclo de Integración Continua y Entrega Continua.

Palabras clave : Integración Continua, Entrega Continua, Pruebas Continuas, DevOps,

Jenkins, Pruebas Unitarias, Software.

6
 INTRODUCCIÓN

Integración Continua (CI) es una práctica de desarrollo de software que requiere de la

integración del código en un repositorio compartido muchas veces durante el dia. Cada aporte
es verificado mediante un build automático, permitiendo a los desarrolladores detectar
problemas en tempranas etapas del desarrollo. Esto ayuda a detectar los errores rápidamente y
localizarlos de manera más fácil.

Según la definición de Martin Fowler (2006): “La integración continua es una práctica de
desarrollo de software en la cual los miembros de un equipo integran su trabajo frecuentemente,
como mínimo de forma diaria. Cada integración se verifica mediante una herramienta de
construcción automática para detectar los errores de integración tan pronto como sea posible.
Muchos equipos creen que este enfoque lleva a una reducción significativa de los problemas de
integración y permite a un equipo desarrollar software cohesivo de forma más rápida.”

Integración continua es usada en muchas empresas de software, es importante saber de

qué manera los ingenieros de calidad de software interactúan y contribuyen en este proceso.

Se pretende enfocar el estudio solo en el área de Control de Calidad de Software durante el

proceso de integración continua, así mismo en la entrega continua del software.

Entrega continua (CD) busca poner el software en producción lo mas antes posible y de manera
regular; ya sea diaria, semanal o hasta mensualmente y no esperar largos periodos para
entregar al cliente los cambios desarrollados por el equipo de desarrollo.

1. GENERALIDADES

1.1 Antecedentes Generales

La metodología Ágil surge a principios del año 2000, con la intención de corregir
algunas malas prácticas en la gestión de proyectos y al día de hoy, es un modelo estándar en
muchas empresas internacionales.

Nació en relación al sector informático y en la optimización de los proyectos

enfocados al desarrollo de aplicaciones. Los buenos resultados de este modo de trabajo han
supuesto que su aplicación se propague a diversos sectores y proyectos de innovación. El
sistema ágil se basa en cuatro pilares fundamentales:

7
1. Valorar a los individuos y las relaciones sociales por encima de los procesos y las
herramientas.

2. Priorizar llegar a ver el producto funcionando sobre la acumulación excesiva de

documentación sobre ello.

3. Colaborar con el cliente y mantener una relación muy cercana y colaborativa.

4. Responder ágilmente ante cualquier cambio o imprevisto y nunca aferrarse al plan

establecido.

Para conseguir esto, la ejecución del proyecto se basa en entregas rápidas y

continuas, acompañado de una planificación temporal exhaustiva y rigurosa. Estas dos cosas
permiten que la reacción ante posibles cambios o rectificaciones sea más dinámica, ágil y
efectiva.

Agile es una metodología que rompe con los tradicionales proyectos de planificación
lineal, que además de extenderse mucho en el tiempo y ser poco productivos, no tenían en
cuenta las posibles novedades y modificaciones, hasta que se entregaba el producto al cliente.
Este tipo de planificación permitía poca flexibilidad ante los cambios y la introducción de
arreglos y modificaciones poco efectivas.

La efectividad de Agile se complementa con equipos Scrum y la planificación del

trabajo, acorde a este sistema de trabajo en equipo.

1.2 Antecedentes Específicos

La integración continua es un modelo informático propuesto inicialmente por Martin

Fowler que consiste en hacer integraciones automáticas de un proyecto lo más frecuente
posible para así poder detectar fallos cuanto antes. Entendemos por integración la compilación
y ejecución de pruebas de todo un proyecto.

Martin Fowler publicó en el 2005 un artículo sobre Integración Continua. En este artículo
Fowler explicaba que la Integración Continua tenía un beneficio directo en los proyectos
software reduciendo el riesgo y tuvo el efecto añadido de ayudar a que se difundiera con más
fuerza.

La integración continua fue evolucionando a medida que aparecieron nuevas

tecnologías y herramientas. Si tenemos que pensar en cuál fue la primera herramienta

8
construida para este propósito, podemos pensar que fue Cruise Control que surgió en el 2001
como servidor de código extensible. Se trata de una herramienta gratuita y código abierto
pensada para realizar construcciones de código automáticos usando Ant o Maven. Funcionaba
a través de plugins que extendían su funcionalidad. Existe una herramienta para .NET similar
denominada Cruisecontrol.NET que aparecio el 2003 con su versión 0.3.1 pero no es hasta
2005 que aparece la primera versión 1.0 estable. Es decir, que la integración continua basada
en herramientas específicas, tampoco es tan lejano.

Hudson es otra herramienta de integración continua escrita en Java que se ejecuta en

un Apache Tomcat o en el servidor de aplicaciones GlassFish. Trabaja con CVS, Svn, Git y
Clearcase y puede ejecutar Apache Ant y Maven así como procesos Windows. Hudson surgió
en 2008 y se convirtió en una alternativa a Cruise control y otros servidores de construcción de
código abierto. El desarrollador principal de Hudson fue Kohsuke Kawaguchi que actualmente
es empleado de Sun Microsystems.

Cuando más adelante Oracle compró Sun, este declaró que quería registrar el nombre
de Hudson y desarrollar una versión comercial. Esto enfadó mucho a la comunidad de
desarrollo de Hudson, la cual decidió junto con Kawaguchi hacer una copia del código de
Hudson y llamarlo Jenkins en 2011. Al final Oracle se da por vencido y en 2012 dona Hudson a
la fundación Eclipse.

2. METODOLOGÍA

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

Método Bibliográfico, debido a que se realizará la lectura y compilación de documentos en la

web relacionados al tema de estudio.

Método Analítico, debido a que se procederá a revisar y analizar ordenadamente documentos

relacionados al tema de estudio.

3. MARCO TEÓRICO

3.1 Fundamentos de Integración Continua

La Integración Continua (CI) es una práctica de desarrollo que hace un llamado a los
equipos de desarrollo para garantizar que se realice una implementación y pruebas posteriores

9
para cada cambio de código realizado en un programa de software. Este concepto estaba
destinado a eliminar el problema de encontrar las incidencias tardías de problemas en el ciclo
de vida de la implementación. La integración continua es un proceso en el que todo el trabajo
de desarrollo se integra lo antes posible. Los módulos resultantes son creados y probados
automáticamente. Este proceso permite identificar errores lo antes posible.

La integración continua se ha convertido en una parte muy integral de cualquier proceso

de desarrollo de software. Ayuda a los desarrolladores y profesionales que prueban
aplicaciones a integrar los cambios al proyecto lo más rápido posible y obtener nuevas
versiones.

Llevar a producción una aplicación es tarea delicada, se debe usar un sistema de

automatización que sea capaz de construir la aplicación y desplegarlo en servidores, pero las
pruebas deberían ser ejecutadas exitosamente. Véase la Figura 1.

10
 Figura 1. Integración continua

Fuente: Elaboración propia

Entonces entra Jenkins que es una herramienta de integración continua, como sistema
de automatización que puede realizar las tareas necesarias para asegurar la calidad del
software y facilitar su despliegue y construcción. Las tareas que Jenkins puede desempeñar son
las siguientes:

● Realizar un control de calidad del software.

● Revisar las métricas de calidad del software establecidas por el equipo de trabajo.

● Enviar las modificaciones del software al repositorio principal.

● Automatizar la compilación del software o su despliegue, una vez se hayan integrado

nuevos cambios en el proyecto.

11
 ● Notificar debidamente a los desarrolladores o al equipo de control de la calidad
cuando se encuentra cualquier tipo de error.

● Generar o visualizar la documentación de un proyecto.

3.2 Entrega Continua

La entrega continua es un proceso en el cual la entrega de software al usuario final se

automatiza para permitir implementaciones fáciles y confiables en el ambiente de producción,
en cualquier momento.

Un proceso de Entrega Continua (CD) deberá lanzar los nuevos cambios de manera
frecuente y rutinaria. Los equipos continúan con las tareas diarias de desarrollo con la
confianza de que pueden mandar a producción un lanzamiento de calidad.

Se considera que la entrega continua es atractiva porque automatiza todos los pasos que van
desde la integración del código en el repositorio base, hasta la liberación de cambios totalmente
probados y funcionalmente adecuados.

El proceso consiste en una compleja automatización de los procesos de compilación,

pruebas, actualización de servidores de producción y ajuste de código. En todo momento, se
mantiene la autonomía del negocio de decidir qué modificaciones se publican, cuáles no y
cuándo se las debe hacer. Véase la figura 2.

12
 Figura 2. Entrega Continua

Naik Vishal (2016, Enero 11). Architecting for Continuous Delivery. Recuperado de
https://www.thoughtworks.com/insights/blog/architecting-continuous-delivery

Beneficios:

● Mayor velocidad y menor complejidad en el proceso de desarrollo.

● Lanzamientos mucho más seguidos, proporcionando retroalimentación

inmediata.

El objetivo de entrega continua es mantener la producción de software mediante la

disponibilidad del nuevo código, haciendo un control de la versión y los nuevos componentes.
Entrega continua minimiza el tiempo de implementación y el tiempo para mitigar o tiempo para
remediar errores de producción. Para entregar valor a los usuarios finales, la entrega debe ser
continua y sin errores.

3.3 Despliegue continuo

Es una práctica para impulsar continuamente a producción nuevas versiones de

software en desarrollo. La diferencia con Entrega Continua es que este proceso realiza de

13
forma automática la puesta en producción una vez que se cubren todos los criterios definidos
para la entrada en Producción para una aplicación.

Esta práctica de igual forma ofrece la máxima flexibilidad ya que permite desarrollar
cualquier necesidad de forma independiente para posteriormente integrar con otras
funcionalidades, validar el código, desplegar en los distintos entornos intermedios, realizar las
pruebas y finalmente implantar en Producción, poniendo en manos de los usuarios finales en el
menor tiempo posible y con la mayor calidad las nuevas funcionalidades implementadas y
garantizando las funcionalidades anteriores. Véase la figura 3.

Figura 3. Flujo de despliegue continuo

Martin,Rafael (2013)De despliegue continuo y de responsabilidad personal. Recuperado de

http://www.logicaalternativa.com/de-despliegue-continuo-y-de-responsabilidad-personal/

3.4 Diferencia entre Integración Continua y Entrega Continua

La integración continua básicamente es una construcción automática y ejecución de

las pruebas unitarias para probar la integración del nuevo código con el código existente y
preferiblemente pruebas de integración son las que se ejecutan.

14
 La entrega continua se describe como una publicación automatizada del lanzamiento
del sistema a producción en cualquier entorno, para esto se requiere testear cualquier cambio y
esto se ejecutara de manera automática. Véase Figura 4.

Figura 4. Integración Continua vs Entrega Continua

Fergon, D. (2017, Septiembre 5). De la nada al "Todo Continuo" y del Scrum más canónico al Kanban
con #NoEstimates. Disponible en

http://davidfergon.github.io/2015-06-16-de-la-nada-al-todo-continuo-de-scrum-a-kanban-y-noestimates

3.5 Desarrollo y Operaciones

DevOps no es en sí una cultura, pero sí requiere de un fuerte cambio cultural y

organizativo para su implementación. Este cambio cultural requiere la colaboración, la
comunicación y en último término la completa integración entre las antiguas áreas de desarrollo
y sistemas.

Este cambio cultural resulta ser complicado de conseguir en algunas organizaciones,

pero recordemos que DevOps es un cambio de cultura y no es en sí una forma de desarrollar
software.

DevOps no es una profesión, no existen ni perfiles DevOps, sino “ingenieros de sistemas con
capacidades específicas para integrarse en equipos DevOps”.

15
3.6 Tipos de pruebas

Las pruebas de software suelen probar algunos aspectos de un sistema software, es

entonces que se describirán los tipos de acuerdo al International Software Testing Qualifications
Software (ISTQB).

Pruebas de Software Funcionales

El comportamiento del sistema, subsistema o componente de software normalmente se

encuentra descrito en especificaciones de requisitos, las funciones establecidas describen “lo
que el sistema hace”.

Las pruebas funcionales se definen a partir de las funciones o características, estas

deben ser bien descritas en documentos y bien interpretadas por las personas q van a probar el
producto.

Se consideran Pruebas de Caja Negra (“black-box testing”), puesto que prueba el

comportamiento externo del sistema. Cada funcionalidad del sistema es comprobado enviando
entradas de datos apropiados, verificando la salida y comparando este resultado actual con
resultados esperados. Este tipo de pruebas involucra también la verificación de la interfaz de
usuario, bases de datos, seguridad, Interfaz de Programación de Aplicaciones (API). Estas
pruebas funcionales pueden ser de dos maneras: manual o automatizada. Las Pruebas de
Seguridad o las Pruebas de Interoperabilidad entre sistemas o componentes son casos
especializados de las pruebas funcionales.

Pruebas de Software no Funcionales

Las pruebas de Software no Funcionales están diseñadas para decidir si el producto

proveerá al usuario buena experiencia. Algunos ejemplos, estas pruebas determinarán el
tiempo de respuesta del producto cuando realizan alguna acción.

Pruebas no funcionales:

- Pruebas de rendimiento y carga.

- Pruebas de compatibilidad.

- Pruebas de localización.

16
 - Pruebas de confiabilidad.

- Pruebas de estrés.

- Pruebas de usabilidad.

- Pruebas de conformidad.

Pruebas de Software Estructurales

Las pruebas de Software Estructurales son casos de prueba que derivan a partir del
conocimiento de la implementación del software, se denomina pruebas de «caja blanca».

En estas pruebas es habitual utilizar herramientas de para calcular la cobertura del

código en el caso de Pruebas de Componentes o en Pruebas de Integración de Componentes.

En estas pruebas se observa el código, esta noción de prueba total se formaliza en lo

que se llama "cobertura", hay diferentes posibilidades de definir la cobertura.

Pruebas de Software de Regresión.

Las pruebas de Software de Regresión, se encargan de probar el software para

asegurar que un cambio o la incorporación de una nueva funcionalidad no ha “roto” lo que ya
había antes, un pequeño cambio en el código puede “romper” partes del software que antes
funcionaba y que parecía que no tenían relación alguna con la modificación que se realizó.

Estas pruebas de regresión se pueden hacer de forma manual o automatizada, pero en

muchos casos se suelen automatizar para ejecutarse frecuentemente.

Estas pruebas también pueden ejecutarse en todos los niveles de pruebas e

incluyen casos de prueba de los tipos vistos anteriormente: Pruebas Funcionales, No
Funcionales y Estructurales.

3.7 Automatización de casos de pruebas

Automatización de casos de pruebas significa usar herramientas de automatización para

ejecutar estas pruebas de forma que introduzca datos al sistema sean procesados y retorne
resultados como reportes. Cabe mencionar que existen muchos casos de pruebas que no
pueden ser automatizados.

17
 Usando casos de prueba ya automatizados es posible ejecutarlos tantas veces como se
requiera y la intervención humana no es es requerida.

Es necesario automatizar las pruebas funcionales y de regresión, con la finalidad que

estas pruebas se puedan ejecutar de forma rápida y repetitiva.

Automatización es importante por las siguientes razones:

- Es complicado verificar software que sea multilenguaje manualmente.

- Se pueden correr los casos de prueba sin atención o intervención de una persona.
Puede correr durante la noche.

- Ayuda a completar los casos de prueba de manera rápida.

- Ayuda a tener mayor cobertura de pruebas.

- Ejecución manual puede volverse aburrida y conlleva a errores humanos.

4. PRUEBAS EN EL PROCESO DE INTEGRACIÓN CONTINUA

4.1 Flujo de Integración Continua

Las tareas de construcción son orquestadas y mantenidas por el servidor de Integración

Continua (Jenkins).

Mejores prácticas:

● Mantener un solo repositorio, con ramas.

● Automatizar la construcción.

● Hacerla automática a las pruebas.

● Notificaciones instantáneas.

● Está permitido cometer errores.

● Las pruebas se realizan en una copia de producción.

● Automatizar el despliegue de la aplicación.

18
 Las pruebas continuas son el proceso de ejecutar pruebas automatizadas como parte
del proceso de entrega de la aplicación con el objetivo de obtener retroalimentación de la nueva
versión de la aplicación lo más antes posible.

Las pruebas continuas van más allá de la automatización y abarcan todas las prácticas,
incluidas las herramientas y el cambio cultural, que ayudan a mitigar los riesgos antes de pasar
a las siguientes etapas del ciclo de vida de desarrollo de software.

Las prácticas de prueba que son manuales tienen que perfeccionarse para que sean
continuas. Es por esto que existe la necesidad de ejecutar pruebas continuas, de esta forma,
cada vez que llegue una compilación nueva con correcciones de errores o nuevas
características para la aplicación, se ejecutarán los conjuntos de pruebas de regresión, lo que
conducirá a pruebas continuas y en función de los errores informados, se puede decidir si se
publicará o no.

El tiempo de lanzamiento de la aplicación puede reducirse aún más con la capacidad de

automatizar la implementación de la construcción en producción, lo que significa tener un
proceso automatizado de toma de decisiones para lanzar o no en función de la gravedad de los
errores reportados después de las pruebas continuas.

4.2 Contribución de control de calidad al proceso de Integración Continua

Las pruebas unitarias durante la fase de Integración continua no pueden detectar todos
los errores. La lógica empresarial, los problemas de diseño son errores que dichas pruebas no
van a detectar, por eso necesitamos un control de calidad o un entorno intermedio para las
pruebas.

El control de calidad en Integración Continua y Entrega Continua se enfoca en:

● Tratar de reducir los errores en la aplicación.

● Encontrar los errores de la aplicación lo más antes posible.

● Tratar de desplegar la aplicación en el ambiente de producción lo más antes posible o

bien lo más frecuente.

● Adicionar soporte a las nuevas funcionalidades que se añaden a la aplicación.

El flujo de contribucion del control de calidad se muestra en la figura 5.

19
 Figura 5. Flujo de contribucion del control de calidad

Lee, James (2018, July 5). The Saga of CI/CD and DevOps. Disponible en https://www.level-up.one/saga-
ci-cd-devops/

4.3 Tipos de casos de pruebas ejecutados

Para el presente documento se explican las pruebas que se han ejecutado en el

proyecto desarrollado. Véase la figura 6:

Figura 6. Tipos de Pruebas

Fuente: Elaboración propia

20
 Una prueba unitaria es la forma de comprobar el correcto funcionamiento de un módulo
de código. Nos permite comprobar que cada módulo de nuestro sistema funciona correctamente
por separado.

- Para el sistema desarrollado se han ejecutado pruebas unitarias simples usando Junit
que es un entorno que permite ejecutar tests de clases Java.

Una prueba de integración nos permite comprobar la integración entre varios

componentes o módulos de nuestro software.

Módulos del sistema:

● Módulo de Estructura Organizacional de la empresa constructora.

● Módulo de Asignación de Equipos de Seguridad.

● Módulo del Registro de Incidentes/Accidentes.

● Módulo de Reportes.

- Permitió comprobar la integración entre distintos módulos de la solución.

● Módulo de estructura organizacional con el módulo de asignación de equipo de

seguridad.

● Módulo de asignación de equipos de seguridad con el módulo de registro de

incidentes/accidentes.

● Módulo de Reportes con todos los anteriores módulos.

- Base de datos

No se ejecutó casos de prueba automatizados en esta área para el proyecto

mencionado sin embargo se podría ejecutar la siguiente prueba automatizada:

● La velocidad de inserción de todos los registros generados

Una prueba funcional es una prueba basada en la ejecución, revisión y

retroalimentación de las funcionalidades previamente diseñadas para la aplicación. Se genero
un informe con el resultado de la ejecución de las pruebas

- Se ejecutó test cases automatizados para cada módulo, a continuación se muestran los
test cases ejecutados, véase en la Figura 7.

21
 Figura 7. Casos de prueba ejecutados

Fuente: Elaboración propia

4.4 Herramientas de Automatización de pruebas Continuas

La lista descrita contiene las herramientas que se pueden usar en distintos tipos de pruebas:

4.4.1 Pruebas Unitarias

JUnit: es un entorno que permite ejecutar pruebas en el funcionamiento de clases Java

y los métodos que componen la aplicación y asegurar el correcto funcionamiento de la misma
ante distintas situaciones de entrada .

Algunas pruebas que se implementaron para la aplicación de la Constructora son las siguientes.
Véase la Figura 8:

22
 Figura 8. Pruebas unitarias desarrolladas

Fuente: Elaboración propia

4.4.2 Pruebas de integración

JUnit: esta misma herramienta puede ser usada para las pruebas de integración.

Database Benchmark: es una herramienta de pruebas de estrés. Los principales

parámetros que mide son:

- La velocidad de inserción de todos los registros generados con valores secuenciales o

aleatorios.

- La velocidad de lectura de todos los registros insertados ordenados por su clave.

- El tamaño de la base de datos después de insertar y leer.

- Cada base de datos probada debe ser capaz de realizar esta prueba simple, insertar los
registros generados y leerlos, ordenados por sus claves.

4.4.3 Pruebas funcionales

Selenium:

Un conjunto de herramientas para llevar a cabo pruebas automatizadas de nuestras

aplicaciones web. Las tareas de administración basadas en la web pueden ser automatizadas.

Cucumber:

Cucumber es una herramienta utilizada para implementar metodologías como el

desarrollo guiado por el comportamiento, las cuales permiten ejecutar descripciones funcionales
escritas en texto plano como pruebas de software automatizadas.

23
Estas descripciones funcionales de los casos de prueba se escriben en un lenguaje específico y
legible llamado "Gherkin”, el cual sirve como documentación al desarrollo y para las pruebas
automatizadas.

Las características Cucumber en Gherkin deben escribirse antes que el código de la

aplicación. Las características de Cucumber nacen con los requisitos de software. Cucumber es
una herramienta de colaboración que busca un entendimiento común de las necesidades,
basado en la colaboración de tres roles: negocio, desarrollo y pruebas.

Cucumber provee un reporte de pruebas ejecutadas véase la figura 9.

Figura 9. Reporte de Cucumber.

Fuente: Elaboración propia

24
4.5 Roles del ingeniero de calidad

Intentemos listar las actividades que puede llegar a estar bajo el cargo de un Ingeniero
de Calidad. Seguro que esta lista se puede ampliar según el producto que se esté
desarrollando, el tamaño de empresa, contexto de la aplicación, etc.:

● Definir plan y estrategia de calidad: Qué hacer y qué no de acuerdo a los objetivos
y riesgos asociados al contexto. Cómo hacerlo, con qué herramientas, de acuerdo a
las restricciones de presupuesto, etc.

● Revisiones de código: Entender, sugerir mejoras, utilizar SonarQube y entender las

mejoras propuestas, poder hacer un plan de acción en base a un reporte de análisis
de código.

● Pruebas funcionales: Deberá poder probar un sistema con un ojo crítico, en busca
de errores. Existen muchas técnicas de diseño de casos de prueba, y para poder
organizar y planificar adecuadamente deberá manejar la prueba exploratoria con
confianza.

● Reportar incidentes: El objetivo de las pruebas no es solo encontrar errores en la

aplicación, más que eso es lograr que se resuelvan. Para esto, es fundamental tener
habilidades para reportar adecuadamente los incidentes.

● Automatización de pruebas funcionales en distintos niveles: No incluiría las

pruebas unitarias ya que esas son para el desarrollador, pero sí podría realizar
revisiones periódicas de las pruebas unitarias y sugerir nuevos casos a probar,
analizar la cobertura, definir si las pruebas tienen el nivel adecuado. Automatizar a
nivel de Interfaz de Programación de Aplicaciones (API), a nivel de Interfaz de
Usuario con herramientas ya descritas como Selenium. Preparar las pruebas con un
enfoque de desarrollo guiado por el comportamiento con Cucumber o alguna
herramienta similar. Deberá poder definir una estrategia de pruebas automatizadas.

● Probar el rendimiento: Esto implica poder automatizar para analizar datos de la

monitorización de distintos componentes de la aplicación, buscando cuellos de
botella y oportunidades de mejora.

● Probar la seguridad: Utilizar distintas herramientas y técnicas para control de

acceso, hacking ético, etc. Al igual que las pruebas de rendimiento, se requiere
conocimiento bien específico de las tecnologías y plataformas utilizadas.

25
 ● Entender y manejar el gestionador de versiones: Es fundamental que las pruebas
esten alineadas con el desarrollo y un punto de contacto muy relevante es la forma
en la que se manejan las versiones del código, las distintas ramas y asociado a esto,
los distintos ambientes. El código de pruebas deberá ser tratado como parte del
código del sistema y para eso se deberán utilizar las mismas herramientas que un
desarrollador y la misma metodología de gestión de versiones.

● Utilizar entornos de Integración Continua: Todas las pruebas que se automaticen

deben estar en un entorno de pruebas continuas como Jenkins o similar, para que se
ejecuten frecuentemente. El responsable de dichas pruebas deberá manejar todos
los artefactos de prueba.

4.6 Beneficios de las pruebas continuas

El objetivo principal de la prueba continua es evaluar el riesgo de un cambio en el

código. Estas pruebas continuas brindan información instantánea sobre el riesgo de entrega de
un candidato de código al usuario final.

Se espera mediante las pruebas continuas la integración en el proceso de desarrollo, a

continuación una lista de los beneficios que se puede obtener de este proceso:

● Las pruebas continuas se integran a la perfección en el flujo de entrega de la aplicación.

● Las pruebas continuas esperan un entorno de prueba estable con datos de prueba
válidos. Este debería estar disponible para cada ejecución de prueba.

● Las pruebas continuas implican ejecutar el conjunto de pruebas en la etapa correcta de

la secuencia de entrega, sin crear un cuello de botella.

● Las pruebas continuas brindan retroalimentación procesable apropiada para cada etapa
del flujo de entrega.

● Las pruebas continuas incluyen pruebas de extremo a extremo que evalúan de forma
realista la experiencia del usuario final en todas las tecnologías asociadas.

● Las pruebas continuas deben ser lo suficientemente amplias como para detectar
cuándo una aplicación cambia inadvertidamente la funcionalidad en la que los usuarios
han llegado a confiar.

● Las pruebas continuas reducen los falsos positivos al priorizar los casos de prueba.

26
 5. RESULTADOS

A continuación los resultados del análisis descrito de las pruebas continuas y su

contribución en la Integración Continua

5.1 Evaluación de resultados

Se pudo verificar que mediante una automatización de los casos de prueba la

Integración continua los tiempos de entrega al ambiente de producción se disminuye de manera
considerable, además de este beneficio se puede identificar de manera más rápida los errores
en la aplicación y poder proveer una solución sin alterar otros módulos relacionados. Sin
embargo las tecnologías avanzan y estas pruebas deben estar acordes a los nuevos
requerimientos de actualización tanto técnicas como el modelo de negocio.

La Integración Continua necesita incorporar requisitos funcionales, de rendimiento y

seguridad. A medida que el mundo del desarrollo de software se ha ido moviendo hacia el uso
de diversas metodologías sofisticadas, se ha convertido en una parte importante del desarrollo.
Las pruebas continuas se agregan para garantizar que el software entregado sea
estable y esté libre de errores en un 99%. Los reportes de problemas generados cuando se
corren las pruebas es clave. La razón principal para adherirse al enfoque de Integración
Continua es ahorrar tiempo y automatizar todo el proceso de implementación. La mayoría de los
procesos de Integración Continua tienden a ser ejecutados por la noche y necesitamos tener
informes completos sobre cómo se han ejecutado estas pruebas, qué pruebas fallaron y por qué
fallaron.
Las pruebas continuas definitivamente deben incluir pruebas de rendimiento y
seguridad, aunque dichas pruebas no necesariamente se ejecutan con la misma frecuencia que
las pruebas funcionales. Sin embargo, las pruebas de rendimiento y seguridad deberían formar
parte de la regresión aproximadamente una vez cada dos sprints o iteraciones.

6. CONCLUSIONES

6.1 Interpretación de resultados en integración continua

En conclusión, los casos de pruebas deben ser automatizados para identificar de

manera rápida los riesgos asociados a errores o conflictos de funcionalidad y contribuir en la
puesta rápida de la aplicación al ambiente de producción. Para las pruebas de unidad /
integración, proveen una retroalimentación mucho más rápida, por lo que no deberían tomar

27
más de 5 minutos: si no pasan, es posible que no se inicien otras pruebas. Tal configuración es
la más eficiente para el desarrollo, así como para la entrega, sin embargo, puede requerir
muchos recursos dependiendo del tamaño del proyecto. Si esto es un problema, es posible
planear pruebas, como ejecutar un grupo nocturno de las pruebas de aceptación más comunes.

Usar múltiples servidores de Integración Continua para diferentes propósitos también es

una buena opción.

La automatización de casos de pruebas es una parte esencial de Integración Continua

desafortunadamente estas necesitan ser mantenibles en el tiempo y además necesitan ser lo
suficientemente robustas para adaptarse a cualquier cambio de requerimientos o tecnologías
nuevas. Los ingenieros de calidad son las personas responsables de tener la documentación de
las pruebas ya automatizadas y todo ello contribuye en un rápido despliegue de la aplicación al
ambiente de producción.

6.2 Propuestas de mejoras a la ingeniería de calidad

Entre las propuestas de mejoras para las pruebas continuas:

- Se debe tener documentación de los casos de pruebas automatizados.

- Los casos de prueba automatizados deben ser mantenibles.

- Se debe ejecutar pruebas automatizadas para probar el rendimiento de la aplicación lo

más antes posible.

- Se debería implementar pruebas unitarias así mismo a las pruebas automatizadas.

- Integración continua permite tener un reporte de las pruebas que fallan, es el rol del
ingeniero de calidad de interpretar los resultados

- Se debe tener un conjunto de pruebas de regresión automatizadas

- Es buena práctica para las pruebas continuas ejecutar un control de calidad sobre ellas.

- Es importante ejecutar todo tipo de casos de prueba para asegurar la calidad del
software.

- La elección de herramientas para implementar pruebas continuas están en función al

tipo de aplicación, la tecnología con la que se desarrolla la aplicación y otros factores.

28
 7. DICCIONARIO DE TÉRMINOS

1. Aplicación: producto de software, programa desarrollado en algún lenguaje de computadora.

2. Automatización: Aplicación de máquinas o de procedimientos automáticos en la realización

de un proceso o en una industria.

3. Casos de prueba: un conjunto de condiciones o variables bajo las cuales un analista

determinará si una aplicación, un sistema software (software system), o una característica de
éstos es parcial o completamente satisfactoria.

4. Desarrollo y operaciones: es un acrónimo inglés de development (desarrollo) y operations

(operaciones), que se refiere a una metodología de desarrollo de software que se centra en la
comunicación, colaboración e integración entre desarrolladores de software y los profesionales
de sistemas en las tecnologías de la información (IT).

5. Despliegue continuo: es que el paso final en desarrollo de software, de pasar a producción,

de manera automática.

6. Entrega continua: implica que todo cambio subido al repositorio y cuyos tests sean exitosos,
pasarán a un servidor donde el conjunto de todos los cambios serán compilados, probados y
verificados.

7. Integración continua: un desarrollador puede integrar sus cambios, de manera continua.

8. BIBLIOGRAFÍA

Date, Devendra (2016, Noviembre 14). CI/CD automation (Part I). Fecha de consulta: 20-08-13.
Recuperado de https://devopstech.com/learn/blogs/cicd-automation/

Fowler, M. (2006, Septiembre 10). Continuous Integration. Fecha de consulta: 20-08-10.

Disponible en: https://www.martinfowler.com/articles/continuousIntegration.html

Fowler, M. (2018). Continuous Integration.. Recuperado de

https://www.thoughtworks.com/continuous-integration

Gollamudi, Raja (2015, Mayo 14). Quality Assurance in Continuous Integration. Fecha de
consulta: 20-08-13. Recuperado de https://magenic.com/thinking/quality-assurance-in-
continuous-integration

29
Heck, Joe. (2016, Mayo 26) Six rules for setting up continuous integration systems. Fecha de
consulta: 20-08-25. Recuperado de https://rhonabwy.com/2016/01/31/six-rules-for-setting-up-
continuous-integration-systems/

Kofman, Bar (2017, Deciembre 19). Test Quality in CI/CD – Expert Roundup Fecha de consulta:
20-08-25. Recuperado de https://www.sealights.io/blog/test-quality-in-ci-cd-expert-roundup/

Lee, James (2018, July 5). The Saga of CI/CD and DevOps. Fecha de consulta: 20-09-3.
Recuperado de https://www.level-up.one/saga-ci-cd-devops/

Root, Bryon (2013, Junio 26). Three Golden Rules for Continuous Delivery. Fecha de consulta:
20-08-25. Recuperado de https://www.nwcadence.com/blog/three-golden-rules-for-continuous-
delivery

Selenium Project (2018, Mayo 19). Selenium Documentation. Fecha de consulta: 20-09-1.
Recuperado de https://www.seleniumhq.org/docs/

Spring (2018, Mayo 15)Testing. Fecha de consulta: 20-09-1. Recuperado de

https://docs.spring.io/spring/docs/current/spring-framework-reference/testing.html

Toledo, Federico (2017, Julio 28). ¿Qué es un QE o Ingeniero en Calidad?. Fecha de consulta:
20-08-13. Recuperado de https://www.federico-toledo.com/que-es-un-qe-o-ingeniero-en-calidad/

Vishal, Naik (2016, Enero 11). Architecting for Continuous Delivery. Fecha de consulta: 20-08-
16. Recuperado de https://www.thoughtworks.com/insights/blog/architecting-continuous-delivery

Wynne, Matt (2018, Mayo 1). New documentation for Cucumber. Fecha de consulta: 20-09-1.
Recuperado de https://cucumber.io/

30