CI/CD para QA: automatiza tests con GitHub Actions

Tienes una suite de tests con Playwright o pytest que funciona de maravilla en tu portátil. El problema es justo ese: funciona en tu portátil. Si nadie se acuerda de ejecutarla antes de cada despliegue, no importa lo bien escrita que esté, en la práctica no está protegiendo nada.

Eso es lo que resuelve un pipeline de CI/CD: que los tests corran solos, en cada cambio de código, sin que nadie tenga que abrir un terminal para acordarse. De las 86 ofertas de QA activas que 17lab agrega automáticamente ahora mismo, CI/CD aparece de forma explícita en 17 (una de cada cinco), por delante de Cypress o Postman como tecnología mencionada.

Esta guía monta un pipeline real con GitHub Actions, la opción más directa si tu código ya vive en GitHub: cómo correr tests de Playwright y de pytest automáticamente, qué revisar cuando el pipeline falla y no es un bug de verdad, y cómo convertir eso en un "quality gate" que bloquea un merge roto. Si vienes de automatizar tests de API con pytest o de tu primer test con Playwright, este es el paso que le falta a esa suite para dejar de depender de que alguien se acuerde de correrla.

Qué es CI/CD y qué cambia de verdad para un QA

CI (integración continua) es la parte que le importa directamente a un QA: cada vez que alguien sube código, un sistema automático lo construye y corre la suite de tests contra ese cambio. CD (entrega o despliegue continuo) es el siguiente paso, publicar automáticamente el código que pasa esos tests, y suele ser terreno más de DevOps que de QA en un equipo pequeño.

El cambio real no es técnico, es de responsabilidad: cuando los tests corren a mano, la calidad depende de que una persona no se olvide. Cuando corren en CI, la calidad depende de una regla que no se salta nunca, sin importar quién suba el código o a qué hora.

El dato tiene un matiz honesto: en la mayoría de esas ofertas, CI/CD aparece como una tecnología más del stack, no como un requisito excluyente. Pero es una señal clara de que las empresas dan por hecho que un perfil de automatización sabe integrar sus tests en un pipeline, no solo escribirlos.

Por qué GitHub Actions como punto de partida

GitHub Actions corre directamente sobre el repositorio, sin instalar ni configurar un servidor aparte, y es gratuito sin límite de minutos en repositorios públicos, que es donde suele vivir un portfolio de QA. Un workflow es un archivo YAML dentro de la carpeta .github/workflows/ del propio proyecto: se versiona con Git, como cualquier otro archivo del código.

Tu primer workflow: tests de Playwright en cada push

Este workflow corre la suite de Playwright cada vez que se sube código a la rama principal o se abre un pull request contra ella. Guárdalo como .github/workflows/tests.yml:

name: Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  playwright:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

Cada línea corresponde a algo que ya harías en local: descargar el código (checkout), instalar Node (setup-node), instalar las dependencias del proyecto (npm ci) y los navegadores de Playwright, y ejecutar la suite. La diferencia es que aquí corre en una máquina limpia, cada vez, sin depender de lo que tengas instalado en tu portátil.

Lo mismo con pytest

Si tu suite está en Python, el patrón es idéntico, solo cambia el lenguaje que se instala y el comando final. Como ya se explica en automatizar tests de API con pytest, pytest es un comando de terminal sin interfaz gráfica, así que corre igual en local que en cualquier pipeline:

name: Tests API

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  pytest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - run: pip install pytest requests
      - run: pytest -v

Si ambas suites viven en el mismo repositorio, puedes tener los dos workflows a la vez: GitHub Actions los ejecuta en paralelo, así que tener dos suites distintas no alarga el tiempo total del pipeline.

Cuando el pipeline falla y no es un bug real

La primera vez que un test pasa en local y falla en CI suele generar dudas sobre si el pipeline está mal montado. Casi nunca lo está: lo habitual es una diferencia de entorno, no un fallo del sistema.

• Variables de entorno o secretos ausentes. Una clave de API o una contraseña que en local lees de un archivo .env tiene que declararse como "secret" en GitHub y pasarse al workflow explícitamente, no se copia sola.
• Dependencias del sistema operativo. Un test que asume una fuente instalada, un navegador concreto o una carpeta que ya existía en tu máquina puede no existir en la máquina virtual limpia de GitHub Actions.
• Tests con orden implícito. Si un test depende de datos que dejó otro test anterior, cambiar el orden de ejecución (algo que sí puede pasar en CI) rompe el que depende de ese estado previo.
• Timeouts demasiado ajustados. Una máquina virtual compartida puede ser más lenta que tu portátil en un momento puntual; un timeout pensado solo para local falla en CI sin que haya ningún bug real.

Quality gate: que no se pueda mergear código roto

Tener el pipeline en verde no sirve de mucho si de todas formas se puede fusionar un pull request con el pipeline en rojo. El paso que cierra el círculo es marcar ese check como obligatorio en la configuración de la rama (Settings → Branches → Branch protection rules → Require status checks to pass), para que GitHub bloquee el botón de merge hasta que los tests pasen.

Cómo se traduce esto en tu portfolio o en una entrevista

Un repositorio con un workflow de GitHub Actions funcionando (visible como una insignia verde en el README, o como historial de ejecuciones en la pestaña "Actions" del repo) es una prueba concreta de que sabes integrar tests en un flujo real, no solo escribirlos sueltos. Es exactamente el tipo de detalle que separa un portfolio de QA genérico de uno que demuestra cómo trabajarías en un equipo de verdad.

Según el World Quality Report 2025-26 de Capgemini y Sogeti (2.000 ejecutivos encuestados en 23 países), solo un 8% de las organizaciones tiene ya una estrategia de automatización de pruebas madura y basada en KPIs, frente a un 47% que todavía está en transición hacia ella. Es un dato global, no específico de España, pero confirma algo que se ve también en las ofertas locales: saber automatizar tests no es raro, saber integrarlos de forma sólida en un pipeline sigue siéndolo.