Cómo integrar pruebas automatizadas en CI/CD sin frenar al equipo
Cómo repartir las pruebas por etapas, qué debe cortar una entrega y qué no, y cómo mantener el primer feedback en minutos cuando la suite crece.
La regla que ordena todo lo demás
En una pipeline, las pruebas se ordenan por coste y velocidad: lo barato y rápido primero, lo caro y lento después. No es una preferencia, es aritmética. Si una build va a fallar, quieres que falle en los primeros noventa segundos y no después de cuarenta minutos de pruebas de interfaz.
| Etapa | Qué se ejecuta | Objetivo de tiempo | ¿Corta la entrega? |
|---|---|---|---|
| Commit | Análisis estático, unitarias, de componente | Menos de 5 minutos | Sí |
| Integración | API, contratos, integración con dobles de prueba | 5 a 15 minutos | Sí |
| Sistema | Flujos críticos de extremo a extremo en entorno desplegado | 15 a 30 minutos | Sí, para los flujos críticos |
| Nocturna | Suite completa, rendimiento, compatibilidad, accesibilidad | Horas | No, pero genera trabajo priorizado |
Qué debe cortar la entrega
Un criterio de calidad que corta la entrega solo tiene sentido si el equipo se lo cree. Si la pipeline se pone roja por motivos que nadie considera graves, la gente aprende a saltárselo y el mecanismo pierde su función.
- Cortan: fallos de compilación, pruebas unitarias y de API en rojo, contratos incumplidos, vulnerabilidades críticas de dependencias, flujos críticos de negocio caídos.
- No cortan, pero se registran y se priorizan: pruebas en cuarentena, avisos de estilo, degradaciones leves de rendimiento, fallos de compatibilidad en navegadores minoritarios.
- Nunca deberían cortar: pruebas conocidas como inestables. Si una prueba no es fiable, o se arregla o se saca del camino crítico; dejarla ahí es entrenar al equipo para ignorar el rojo.
Cuando la primera etapa se pasa de tiempo
El primer reflejo suele ser añadir máquinas y paralelizar. Ayuda, pero tiene techo y cuesta dinero. Lo que de verdad devuelve el feedback a minutos es reducir lo que se ejecuta en esa etapa.
- Paraleliza y reparte por lotes equilibrados, no por orden alfabético de fichero.
- Selecciona por impacto: ejecuta primero las pruebas relacionadas con los ficheros que ha tocado el commit y deja el resto para la etapa siguiente.
- Reutiliza sesiones y estado: iniciar sesión por interfaz en cada prueba es tiempo regalado; hazlo por API una vez.
- Cachea dependencias y artefactos de build con claves estables.
- Mueve al nivel inferior las comprobaciones que no necesitan la interfaz. Suele ser el mayor ahorro y el más duradero.
Entornos, datos y configuración
Una pipeline fiable necesita entornos reproducibles: infraestructura declarada como código, versiones fijadas de navegadores y drivers, y una comprobación de arranque que verifique que el sistema está en pie y con datos base antes de ejecutar una sola prueba. Ese smoke de infraestructura ahorra horas de diagnóstico, porque distingue "el entorno no estaba listo" de "el producto tiene un defecto".
La configuración va fuera del código, por entorno, y los secretos en un gestor de secretos: nunca en el repositorio, donde quedan en el historial para siempre. Y el testware se versiona con trazabilidad hacia la versión del sistema que prueba, para poder reproducir mañana una ejecución de hoy.
Informes que alguien lee
Cada ejecución debe publicar automáticamente su resultado donde el equipo ya trabaja, con las evidencias enganchadas: log, captura, petición y respuesta. Y con tendencia, no solo la foto de la última ejecución: la duración y la tasa de fallos falsos a lo largo de las semanas son las dos señales que avisan de que la suite se está degradando antes de que sea grave.