Pruebas automatizadas y CI/CD en desarrollo web a medida

He visto demasiados proyectos a medida acabar igual. Empiezan limpios, con ciclos de release semanales y un cliente contento. Doce meses después nadie se atreve a tocar la facturación porque cualquier cambio rompe el módulo de envíos, los despliegues los hace una persona los viernes a las once de la noche y las pruebas se reducen a "lo hemos abierto y parecía funcionar". Si te suena, lo que falta no es talento. Falta un sistema.

Te cuento qué pruebas merece la pena montar, cómo encajar un pipeline que aguante el día a día y por qué la inversión inicial se recupera antes de lo que la mayoría de fundadores cree.

Por qué las pruebas automatizadas son imprescindibles en el desarrollo a medida

Un producto SaaS estándar tiene miles de clientes haciendo de QA gratis. Tú no. Cuando construyes a medida, eres tú quien decide qué se rompe y qué se mantiene en pie. Nadie más va a avisar.

El coste oculto de no automatizar

El cálculo es feo. Un equipo de cuatro personas que prueba manualmente cada release pierde 8 horas semanales que cobras al cliente o pagas tú. Y aun así, se cuelan errores. El estudio clásico de IBM sigue vigente: un bug en producción cuesta entre 30 y 100 veces más que el mismo bug detectado al escribir el código. En proyectos que he auditado en Madrid y Barcelona, el coste medio de una incidencia crítica ronda los 4.000-8.000 euros entre hotfix, comunicación con cliente y horas perdidas. Multiplícalo por las dos o tres incidencias mensuales que sufre un proyecto sin tests y el ROI deja de ser una discusión.

Confianza para evolucionar

El beneficio real, sin embargo, no es el ahorro. Es la velocidad. Un equipo con buena suite refactoriza sin miedo, acepta cambios de alcance sin renegociar plazos y promociona junior a senior más rápido porque la red de seguridad les deja probar cosas. Sin tests, cada cambio es una apuesta. Con tests, una hipótesis verificable en treinta segundos.

Tipos de pruebas automatizadas para tu proyecto web

Ningún tipo de prueba sirve para todo. La pirámide clásica (mucho unitario, integración media, poco E2E) sigue siendo la guía más sólida que tenemos. Yo añadiría una norma propia: si tu pirámide se ha convertido en un cono de helado al revés (muchos E2E, pocos unitarios), tienes un problema serio de mantenimiento esperándote dentro de seis meses.

Pruebas unitarias

Son la base. Verifican funciones o componentes aislados, sin tocar base de datos ni red, y se ejecutan en milisegundos. Si una función calcula el precio final de un pedido con IVA, descuento por volumen y cupón promocional, le lanzas veinte casos distintos y compruebas que la salida es la esperada.

Empieza por la lógica de negocio crítica: cálculos de precios, validaciones, transformaciones de datos. Es lo que más falla y lo más barato de cubrir. Para Node y TypeScript uso Vitest, más rápido que Jest y con mejor integración ESM. Para Python, pytest sigue sin rival. Para PHP, PHPUnit aguanta y Pest gana tracción si vienes de Laravel.

Pruebas de integración

Aquí ya intervienen varias piezas: el controlador llama al servicio, el servicio escribe en base de datos, la base de datos devuelve datos y la respuesta sale serializada. Son más lentas que las unitarias (segundos en vez de milisegundos) pero atrapan errores que el unitario no ve nunca: un índice mal puesto, un constraint que no se cumple, una API externa que cambia el formato del campo.

El error que más veo es no aislar el entorno. Si tus tests apuntan a la base de datos de desarrollo compartida, vas a sufrir. Levanta un contenedor de PostgreSQL o MySQL por ejecución (Testcontainers lo hace fácil) y olvídate de tests intermitentes. Esa media hora de configuración te ahorra meses de "en mi máquina pasa, en CI no".

Pruebas end-to-end (E2E)

Las E2E simulan al usuario real: abren navegador, navegan, rellenan formularios, esperan respuestas y comprueban lo que se ve en pantalla. Son las más cercanas a la realidad y también las más frágiles. Una pantalla que cambia y se te caen veinte tests.

Cypress sigue siendo cómodo para equipos pequeños. Playwright se ha comido el terreno en los últimos dos años, sobre todo cuando necesitas multibrowser real o paralelización seria. Para proyectos nuevos, voy directo a Playwright salvo restricción del cliente.

La regla que repito siempre: máximo 20 o 30 E2E críticos. Checkout, login, alta, generación de factura. Lo que tira el negocio si se rompe. El resto se cubre con integración o unitario. He visto suites de 400 E2E tardando dos horas y ejecutándose tres veces porque fallaban a la mitad. Acabas desactivándolos y perdiendo la confianza en el pipeline entero.

Diseño de un pipeline CI/CD eficaz

El pipeline es el músculo que conecta tus pruebas con la realidad del producto. CI valida cada cambio en cuanto entra al repositorio. CD lleva ese código validado al entorno donde corresponde, ya sea staging o producción, con la menor fricción humana posible.

Etapas fundamentales del pipeline

Un pipeline razonable para un proyecto web a medida suele tener este esqueleto:

Compilación y análisis estático. Compila o transpila, pasa ESLint, Prettier y valida tipos con tsc --noEmit. Te ahorra reviews humanas para discutir comas.

Pruebas unitarias e integración. El corazón. Si esto falla, el pipeline se detiene. Punto. No hay "es solo un test flaky, mergea igual". Esa frase es el principio del fin.

Pruebas E2E contra staging. Solo si lo anterior ha pasado. Levantas el entorno, despliegas el build, lanzas los tests críticos. Tarda más, así que lo dejas para la rama principal, no para cada commit.

Análisis de seguridad. Snyk, OWASP Dependency-Check o Dependabot escaneando dependencias. Si manejas datos personales (LOPDGDD, RGPD), una vulnerabilidad alta sin parchear es un riesgo legal, no solo técnico.

Despliegue. Promoción automática a staging, validación opcional manual, promoción a producción. Con feature flags despliegas sin activar y enciendes cuando quieras.

Estrategias de branching compatibles con CI/CD

GitFlow tuvo sentido cuando se publicaban releases cada tres meses. Hoy, con despliegues diarios, complica más de lo que ayuda. Trunk-based development con ramas de uno o dos días de vida y feature flags para lo que no esté listo es lo que mejor funciona en proyectos a medida.

La regla que defiendo siempre: si una rama vive más de tres días, algo está mal. O la tarea es demasiado grande y debería partirse, o el equipo no se atreve a mergear porque no confía en los tests. Ambos problemas se resuelven, pero hay que verlos.

Herramientas para implementar CI/CD en tu proyecto

GitHub Actions

Si tu código vive en GitHub, no busques más. La integración nativa, el marketplace de acciones y los runners gestionados cubren el 95 % de los casos. Para proyectos pequeños y medianos sale prácticamente gratis dentro del free tier. El YAML es legible y la curva se mide en horas.

GitLab CI

GitLab CI es el equivalente natural si trabajas en GitLab, y en algunos aspectos va por delante: gestión de entornos más rica, registry integrado y runners self-hosted bien resueltos. Es la opción habitual en clientes corporativos españoles que necesitan el código en infraestructura controlada.

Otras opciones

Jenkins sigue vivo en corporaciones y bancos, donde el control absoluto sobre la infra pesa más que la comodidad. CircleCI es buena alternativa cloud si vienes de ese ecosistema. La pregunta no es cuál es la mejor en abstracto: es cuál encaja con tu equipo, tu repositorio y tu presupuesto. Cambiar de CI a los seis meses por modas es de los peores usos de tiempo que conozco.

Beneficios concretos para proyectos a medida

Reducción de costes a medio plazo

La inversión inicial (entre dos y cuatro semanas para dejar la base montada) se amortiza entre el mes tres y el mes seis. Lo que ahorras no es solo tiempo de QA: es el coste de incidencias que no llegan a producción, horas extra de los viernes y descuentos al cliente para compensar fallos.

Entregas más rápidas y predecibles

Con un pipeline serio puedes desplegar cinco veces al día sin sudar. Eso cambia la conversación con el cliente: deja de ser "tendrás esta funcionalidad en la release de mayo" y pasa a ser "mañana lo tienes en producción". Esa agilidad, en un proyecto a medida, vale más que cualquier descuento.

Mayor calidad del producto final

Menos incidencias en producción, menos llamadas de soporte el lunes por la mañana y un equipo que se acuesta tranquilo. Para el cliente final esto se traduce en NPS más alto, churn más bajo y referencias activas. Para ti, en renovación de contrato.

Documentación viva del comportamiento

Una suite bien escrita es la mejor documentación que vas a producir, porque está obligada a mantenerse al día: si miente, el pipeline rompe. Cuando entra un developer nuevo y lee los tests, entiende cada módulo en una tarde. Sin tests, dedicas dos semanas a explicarle el negocio y aun así se confunde el primer mes.

Cómo empezar: una hoja de ruta práctica

No intentes pasar de cero a Netflix en un mes. Es un error clásico que acaba con el equipo frustrado y el cliente preguntando por qué nadie hace features.

Yo siempre recomiendo este orden. Identifica los tres o cuatro componentes que más miedo te dan tocar (los típicos cálculos, autenticación, integración con pasarela de pago) y cúbrelos con unitarios. En paralelo, monta un pipeline mínimo que ejecute esos tests en cada push y bloquee el merge si fallan. Una vez la cultura se asienta (suele costar entre cuatro y seis semanas), añade tests de integración para los flujos centrales y dos o tres E2E para checkout, login y alta. Después automatiza el despliegue a staging y, cuando todo el equipo confíe en el sistema, a producción.

Lo que más cuesta no es técnico. Es cultural. Desde el día uno: ninguna PR se mergea sin tests, ningún hotfix esquiva el pipeline, y si un test es flaky se arregla, no se desactiva.

Conclusión

Las pruebas automatizadas CI/CD desarrollo web a medida dejaron de ser un lujo hace una década. Son higiene básica para cualquier proyecto que pretenda durar más de dieciocho meses y crecer sin colapsar al equipo. Bajan costes reales, aceleran entregas, mejoran la experiencia del cliente y, sobre todo, te devuelven el control sobre tu propio producto.

Si necesitas ayuda para diseñar la estrategia de pruebas y montar un pipeline que encaje con tu equipo y tu proyecto, Contacta con Tangram Consulting. Trabajamos con equipos de desarrollo a medida desde la primera línea de test hasta el despliegue continuo en producción.