Chavarriaga Lozano, Jaime AlbertoBurbano Castillo, Andrés Felipe2026-07-082026-07-082026http://hdl.handle.net/11522/5626En la actualidad, muchas organizaciones dependen de pruebas automatizadas y procesos de integración continua para asegurar la calidad de sus productos de software. Sin embargo, en estos entornos, suele ocurrir que la ejecución completa de todas las pruebas requiere tiempos prolongados, incluso cuando se hacen cambios pequeños o triviales en el código. Esto genera desmotivación en los desarrolladores, quienes tienden a evitar la ejecución frecuente del pipeline o incluso la creación de nuevas pruebas, por temor a incrementar aún más los tiempos de integración. Esta situación afecta directamente la oportunidad de la retroalimentación, un factor determinante para mantener la calidad y velocidad en ciclos ágiles de desarrollo. Este proyecto plantea una alternativa a esta problemática mediante un modelo de ejecución segmentada de pruebas automatizadas, en el cual no es necesario ejecutar la totalidad de las pruebas en cada evento del flujo de desarrollo. La propuesta parte de un análisis de los diferentes “momentos” del proceso, por ejemplo, la creación de Pull Requests hacia ramas de características (feature), la integración hacia ramas de liberación (release) y la construcción nocturna (nightly build), y define las necesidades de retroalimentación asociadas a cada uno de ellos. A partir de este análisis se clasifican las pruebas automatizadas y se diseñan distintos flujos de integración continua que ejecutan únicamente las pruebas más relevantes para cada etapa, reduciendo así la redundancia y el consumo innecesario de tiempo y recursos. Como resultado de este proceso se construyó una matriz que relaciona fases del desarrollo, tipos de prueba y tiempos esperados de respuesta, lo cual permitió formalizar un criterio consistente de selección de pruebas. Esta matriz sirvió como base para implementar un conjunto de pipelines YAML parametrizado en Azure DevOps, capaces de seleccionar dinámicamente las pruebas según la rama, el tipo de cambio o el módulo afectado. La propuesta se evalúo en una empresa de desarrollo que construye aplicaciones que se comercializan a nivel mundial y cuyas pruebas pueden tomar varias horas. En esta empresa, en los escenarios donde solo se modificaba un módulo específico, la ejecución focalizada de pruebas mostró una reducción significativa en los tiempos de retroalimentación durante la validación de Pull Requests, sin afectar la calidad de los entregables ni la cobertura esperada de validación. La evaluación cualitativa, realizada con el jefe del área de DevOps, permitió validar los beneficios percibidos y, a la vez, identificar nuevas oportunidades de mejora. Aunque el filtrado por módulo reduce el tiempo de ejecución de pruebas, se observó que, cuando varios módulos con pipelines independientes se modifican simultáneamente, cada pipeline replica el proceso completo de infraestructura, generando ejecuciones en cascada que incrementan el tiempo total de integración. Este hallazgo destaca la necesidad de evolucionar hacia enfoques basados en orquestadores o infraestructuras compartidas que permitan mantener la segmentación sin incrementar los costos de construcción. Entre las lecciones aprendidas se destaca la importancia de definir métricas claras de retroalimentación desde el inicio, mantener consistencia en las ramas y disparadores, y minimizar configuraciones manuales para evitar errores humanos. Finalmente, se concluye que la percepción del equipo respecto a la utilidad y fluidez del pipeline es tan relevante como las métricas técnicas al evaluar la efectividad de un proceso de integración continua, especialmente en entornos colaborativos y de alta frecuencia de entrega.81 p.application/pdfspaIntegración continuaPruebas de softwareDiseño de procesos de integración continuaRetroalimentación continuaPipelines de CI/CDContinuous integrationSoftware testingCI process designContinuous feedbackCI/CD pipelinesmaster thesishttps://creativecommons.org/licenses/by-nc-sa/4.0/http://purl.org/coar/access_right/c_abf2