Estrategia de Automatización

Pruebas repetitivas (Regresión), rutas críticas de negocio, pruebas difíciles de realizar manualmente (por ejemplo, verificación precisa de datos) y características estables.

Identifica la causa (entorno, condiciones de carrera, localizadores). Aísla la prueba. Usa esperas explícitas. Verifica el modo de ejecución (sin cabeza vs con cabeza).

Una estrategia donde los scripts de prueba leen datos de fuentes externas (CSV, Excel, Base de datos) en lugar de usar valores codificados, permitiendo que la misma prueba se ejecute con múltiples conjuntos de datos.

CI (Integración Continua) integra los cambios de código con frecuencia en una rama compartida con build y tests automáticos en cada integración. Continuous Delivery significa que el código puede desplegarse automáticamente pero una persona aprueba la release. Continuous Deployment significa que se despliega automáticamente cuando pasan todos los checks, sin aprobación manual.

Commit, build/transpilación, tests unitarios, tests de integración, calidad de código (lint, coverage), escaneo de seguridad, tests E2E, deploy a staging, smoke tests, luego una aprobación manual, deploy a producción y monitorización. Cada etapa es un quality gate; los checks más rápidos y baratos van primero para que los fallos aparezcan pronto.

Un modelo para equilibrar tipos de test: muchos tests unitarios rápidos y baratos en la base; menos tests de integración en el medio (que prueban la comunicación entre capas como API y BD); y pocos tests E2E lentos y caros en la cima. Invertirla (sobre todo E2E) da suites lentas e inestables. Va de la mano del shift-left: detectar bugs lo antes y más barato posible.

Condiciones que el código debe cumplir para avanzar: un umbral mínimo de coverage (p. ej. 80%), cero vulnerabilidades críticas, cero tests fallidos y linting limpio. Imponen un nivel de calidad consistente de forma automática y detienen un cambio malo antes de que llegue a producción.

Un test flaky pasa o falla de forma intermitente sin un cambio real de código. Causas comunes: race conditions/timing, dependencias entre tests, datos compartidos, animaciones e inestabilidad de red. Soluciones: sustituir sleeps fijos por esperas basadas en condiciones (waitForSelector, waitForResponse), hacer cada test independiente y mockear las APIs externas inestables.

Canary (lanzar a un pequeño porcentaje de usuarios primero, vigilar métricas y luego ampliar), blue/green (dos entornos idénticos, cambiar el tráfico al instante y hacer rollback volviendo al anterior), feature flags (activar/desactivar funcionalidades sin redesplegar) y rollback (volver a la versión anterior). Los smoke tests se ejecutan justo tras el deploy para confirmar que la app arranca.

Un workflow (un archivo YAML en .github/workflows) se ejecuta según triggers (on: push, pull_request, schedule, workflow_dispatch). Contiene jobs que corren en un runner (ubuntu-latest), cada uno con steps que usan una action (actions/checkout@v4, actions/setup-node@v4) o ejecutan un comando de shell. Los jobs pueden depender de otros con needs:, ejecutar configuraciones en paralelo con matrix:, cachear dependencias y leer secrets con ${{ secrets.NOMBRE }}.

Nunca pongas credenciales en el código ni en archivos de configuración. Guárdalas como secrets enmascarados en la plataforma de CI (GitHub: Settings -> Secrets) y referéncialas en tiempo de ejecución (${{ secrets.NOMBRE }}). Acótalas por entorno, marca como protegidos los secrets de despliegue y mantenlos fuera de los logs de los jobs.

Ejecuta tipos de test independientes como jobs en paralelo, cachea dependencias (node_modules, binarios de navegador) y reparte (shard) los E2E entre máquinas (p. ej. Playwright --shard=1/4 con una matrix). Ejecuta primero los unitarios como gate rápido, y corre la etapa E2E cara solo tras pasar las etapas más baratas.