Jenkins para QA

Por qué Jenkins importa para QA #

Jenkins es el servidor CI/CD más ampliamente desplegado en el mundo. Con más de 1,800 plugins y una comunidad masiva, sigue siendo la columna vertebral de los pipelines de automatización de tests en miles de empresas — desde startups hasta empresas como Netflix y Airbnb.

Como ingeniero QA, es casi seguro que encontrarás Jenkins en tu carrera. Incluso si tu equipo actual usa otra herramienta, entender Jenkins te da conocimiento transferible sobre diseño de pipelines CI/CD que aplica en todas partes.

Arquitectura de Jenkins #

Jenkins opera con una arquitectura controller-agent:

• Controller (Master): Gestiona la interfaz web, programa builds, despacha jobs a los agentes y almacena resultados
• Agents (Nodes): Ejecutan el trabajo real de build y test. Los agentes pueden ser máquinas físicas, máquinas virtuales, contenedores Docker o pods de Kubernetes

Esta separación es crítica para QA porque la ejecución de tests puede ser intensiva en recursos. Ejecutar tests de Selenium en el controller ralentizaría todo. Agentes dedicados aseguran que tus tests tengan los recursos que necesitan sin afectar otros jobs.

Conceptos Clave #

Jenkinsfile Declarativo #

Jenkins moderno usa Jenkinsfiles declarativos — definiciones de pipeline almacenadas en el repositorio del proyecto. Este es el enfoque pipeline-as-code.

Estructura Básica #

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh 'npm ci'
            }
        }
        stage('Unit Tests') {
            steps {
                sh 'npm test'
            }
        }
        stage('E2E Tests') {
            steps {
                sh 'npx playwright test'
            }
        }
    }

    post {
        always {
            junit '**/test-results/*.xml'
            archiveArtifacts artifacts: '**/test-reports/**', allowEmptyArchive: true
        }
        failure {
            echo 'Pipeline falló. Revisa los reportes de tests para detalles.'
        }
    }
}

Configuración de Agentes #

La directiva agent le dice a Jenkins dónde ejecutar el pipeline:

// Ejecutar en cualquier agente disponible
agent any

// Ejecutar en un agente con una etiqueta específica
agent { label 'linux && chrome' }

// Ejecutar dentro de un contenedor Docker
agent {
    docker {
        image 'mcr.microsoft.com/playwright:v1.40.0-focal'
    }
}

Para QA, los agentes Docker son particularmente útiles porque proporcionan un entorno consistente con navegadores y herramientas de test pre-instaladas.

Variables de Entorno #

pipeline {
    agent any

    environment {
        BASE_URL = 'https://staging.example.com'
        TEST_ENV = 'ci'
        BROWSER = 'chromium'
    }

    stages {
        stage('E2E Tests') {
            steps {
                sh 'npx playwright test --project=${BROWSER}'
            }
        }
    }
}

Usa credentials() para valores sensibles:

environment {
    DB_CREDS = credentials('test-database-credentials')
    API_KEY = credentials('api-key-staging')
}

Ejecución Paralela de Tests #

Ejecutar tests en paralelo es una de las optimizaciones más impactantes para pipelines QA. Jenkins soporta paralelización a nivel de stage:

stage('Tests') {
    parallel {
        stage('Tests Chrome') {
            agent { label 'chrome' }
            steps {
                sh 'npx playwright test --project=chromium'
            }
        }
        stage('Tests Firefox') {
            agent { label 'firefox' }
            steps {
                sh 'npx playwright test --project=firefox'
            }
        }
        stage('Tests API') {
            agent any
            steps {
                sh 'npm run test:api'
            }
        }
    }
}

Esto ejecuta tests de Chrome, Firefox y API simultáneamente en diferentes agentes. Si cada suite toma 15 minutos, la etapa paralela completa en 15 minutos en total en lugar de 45 minutos secuencialmente.

Reportes de Tests #

Jenkins proporciona varias formas de mostrar resultados de tests.

Plugin JUnit Report #

La mayoría de frameworks de test pueden generar formato JUnit XML. Jenkins puede parsear estos reportes y mostrar resultados en el dashboard del build:

post {
    always {
        junit testResults: '**/junit-results.xml', allowEmptyResults: true
    }
}

HTML Publisher #

Para reportes de tests enriquecidos (Allure, Playwright HTML reporter):

post {
    always {
        publishHTML([
            reportDir: 'playwright-report',
            reportFiles: 'index.html',
            reportName: 'Reporte Playwright'
        ])
    }
}

Archivando Artefactos #

Guarda capturas de pantalla, videos y logs de tests fallidos:

post {
    always {
        archiveArtifacts artifacts: 'test-results/**', allowEmptyArchive: true
    }
    failure {
        archiveArtifacts artifacts: 'screenshots/**', allowEmptyArchive: true
    }
}

Quality Gates en Jenkins #

Las quality gates definen criterios que deben cumplirse para que el pipeline continúe. Para QA, las gates comunes incluyen:

Tasa de Éxito de Tests #

stage('Quality Gate') {
    steps {
        script {
            def testResults = currentBuild.rawBuild.getAction(hudson.tasks.junit.TestResultAction.class)
            if (testResults) {
                def failCount = testResults.result.failCount
                if (failCount > 0) {
                    error("${failCount} tests fallaron. Build bloqueado.")
                }
            }
        }
    }
}

Ejercicio: Crea un Pipeline de Jenkins para una Aplicación Web #

Diseña un Jenkinsfile completo para una aplicación web con estos requisitos:

• Aplicación Node.js con frontend React y backend Express
• Tests unitarios (Jest), tests API (Supertest) y tests E2E (Playwright)
• Los tests deberían ejecutarse en paralelo donde sea posible
• Despliegue a staging después de que todos los tests pasen
• Quality gate: cero fallos de tests y mínimo 80% de cobertura de código

pipeline {
    agent { docker { image 'node:20-slim' } }

    environment {
        CI = 'true'
        BASE_URL = 'https://staging.example.com'
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Type Check') {
            steps {
                sh 'npm run lint'
                sh 'npm run type-check'
            }
        }

        stage('Tests') {
            parallel {
                stage('Unit Tests') {
                    steps {
                        sh 'npm run test:unit -- --coverage --ci'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                            publishCoverage adapters: [coberturaAdapter('coverage/cobertura-coverage.xml')]
                        }
                    }
                }
                stage('API Tests') {
                    steps {
                        sh 'npm run test:api'
                    }
                    post {
                        always {
                            junit 'api-test-results/junit.xml'
                        }
                    }
                }
                stage('E2E Tests') {
                    agent {
                        docker { image 'mcr.microsoft.com/playwright:v1.40.0-focal' }
                    }
                    steps {
                        sh 'npm ci'
                        sh 'npx playwright test'
                    }
                    post {
                        always {
                            junit 'test-results/junit.xml'
                            publishHTML([
                                reportDir: 'playwright-report',
                                reportFiles: 'index.html',
                                reportName: 'Reporte Playwright'
                            ])
                            archiveArtifacts artifacts: 'test-results/**', allowEmptyArchive: true
                        }
                    }
                }
            }
        }

        stage('Quality Gate') {
            steps {
                script {
                    def testResults = currentBuild.rawBuild.getAction(hudson.tasks.junit.TestResultAction.class)
                    if (testResults && testResults.result.failCount > 0) {
                        error("${testResults.result.failCount} tests fallaron.")
                    }
                }
            }
        }

        stage('Deploy to Staging') {
            when { branch 'main' }
            steps {
                sh './scripts/deploy-staging.sh'
            }
        }
    }

    post {
        always {
            cleanWs()
        }
        failure {
            echo 'Pipeline falló. Revisa los reportes de tests arriba.'
        }
    }
}

Plugins de Jenkins Comunes para QA #

Mejores Prácticas de Jenkins para QA #

1. Siempre usa Jenkinsfiles declarativos almacenados en el repositorio. Nunca configures pipelines a través de la UI de Jenkins — no tiene control de versiones.

2. Mantén la ejecución del pipeline bajo 30 minutos. Si los tests toman más, paralelízalos o divídelos en pipelines separados (pipeline de feedback rápido + regresión nocturna completa).

3. Usa agentes Docker para entornos de test consistentes. Fija versiones específicas de imágenes para evitar sorpresas cuando las imágenes se actualicen.

4. Archiva artefactos de tests en cada build — no solo en fallos. Necesitarás datos históricos para análisis de tendencias.

5. Implementa limpieza adecuada con cleanWs() en el bloque post { always }. Archivos sobrantes de builds anteriores pueden causar tests inestables.

6. Usa shared libraries para código de pipeline común. Si múltiples proyectos usan la misma configuración de reportes de tests, extráela en una librería compartida en lugar de copiarla en todas partes.

Resolución de Problemas Comunes #

Tests pasan localmente pero fallan en Jenkins #

• Diferencia de entorno: Usa agentes Docker para igualar el entorno local
• Dependencias faltantes: Asegura que npm ci (no npm install) se ejecute en CI
• Problemas de timing: Los agentes CI pueden ser más lentos; aumenta timeouts para tests E2E
• Problemas de display: El modo headless del navegador puede comportarse diferente; revisa capturas

El pipeline se ejecuta lentamente #

• Sin paralelización: Divide suites de tests independientes en stages paralelos
• Sin caché: Usa caché de workspace de Jenkins o caché de capas Docker para node_modules
• Contención de recursos: Asegura que los agentes tengan suficiente CPU/RAM para tests basados en navegador

Tests inestables en CI #

• Estado compartido: Tests que comparten base de datos o archivos pueden interferir entre sí
• Condiciones de carrera: Solicitudes de red pueden fallar por timeout bajo carga CI
• Solución: Aísla datos de test, agrega reintentos para operaciones dependientes de red, usa playwright test --retries=1