Automatización de pruebas con IA: cobertura E2E autorreparable
La mayoría de las baterías de tests E2E cuestan más de lo que ahorran. Usamos IA para generar, mantener y autorreparar tests: regresión visual que ignora el ruido, selectores que se adaptan a los cambios de interfaz y una tasa de tests inestables con la que se puede vivir.
- Si corrección de lógica o funciones
- Tests unitarios (sin IA)
Rápidos, baratos y deterministas. Aquí la IA es excesiva: escríbelos a mano o genéralos a partir de los tipos.
- Si recorridos y flujos reales de usuario
- E2E generados con IA + autorreparables
Los selectores se adaptan a los cambios de interfaz, y la IA genera los tests a partir de sesiones reales de usuario. Aquí está el mayor retorno.
- Si corrección visual o de píxeles
- Regresión visual asistida por IA
La IA ignora el ruido (antialiasing, animación) y señala las diferencias reales. Reduce el ruido más de un 90 % frente a una comparación de píxeles ingenua.
No estamos en contra de la IA para testing: estamos en contra de los tests con IA que sustituyen a tests que ya funcionaban.
Qué obtienes
Cuándo encaja
- La batería actual de tests es tan inestable que los PR se fusionan con la CI en rojo «porque siempre está en rojo»
- Los lanzamientos se ralentizan porque el QA manual es el cuello de botella
- El producto cambia cada semana y los tests no dan abasto: tener menos tests, pero mejores, sería preferible a los actuales
- Hay un responsable de ingeniería dispuesto a exigir «no se fusiona con tests rotos» en cuanto la batería sea fiable
Cuándo no
- No hay ningún test ni cultura de testing: empieza con tests unitarios y una CI básica, no con automatización con IA
- La superficie del producto es inestable y cambia a diario por diseño: los tests siempre irán por detrás de la velocidad del producto
- El QA manual es realmente más barato a tu escala (producto pequeño, equipo diminuto)
Proceso
Semana 1: auditoría y cuarentena (qué conservar, qué borrar, qué reescribir). Semanas 2–4: sustitución del 20 % más inestable de los tests por tests E2E autorreparables que cubren los mismos recorridos. Semanas 5–6: tests generados con IA para las rutas críticas sin cobertura, más regresión visual. Semana 7: traspaso, con un manual del «Test Owner» incluido (el rol que la mayoría de los equipos se salta).
Proceso de entrega completoPrecios
Precio cerrado ($40–120k) para un sprint acotado de 6–8 semanas. Cuota trimestral para la propiedad continua de los tests. La infraestructura de testing (Playwright Cloud, Chromatic, etc.) se factura a precio de coste.
Ver modelos de colaboraciónCasos de éxito
Marketplace multivendedor
Marketplace escalable que procesa más de 10 millones de dólares al mes, con recomendaciones basadas en IA y gestión de inventario en tiempo real.
Sistema ATS con IA
ATS integral con matching por IA, análisis automático de CV y comunicación en tiempo real con reclutadores, para más de 10.000 candidatos al mes.
Preguntas frecuentes
- ¿Los tests generados con IA no serán inestables ellos mismos?
- Lo serán si el prompt es «genera tests» sin más ingeniería detrás. Nuestro patrón envuelve la generación con un filtro de inestabilidad: un test nuevo tiene que pasar 10 ejecuciones seguidas de CI antes de poder bloquear un merge. Los tests que no superan ese listón se ponen en cuarentena automáticamente: no consiguen acostumbrar al equipo a ignorar builds en rojo.
- ¿Y Cypress frente a Playwright?
- Por defecto usamos Playwright: mejor soporte multinavegador, más rápido, mejores herramientas de depuración, y la mayoría de las herramientas de generación de tests con IA lo soportan de forma nativa. Trabajamos con Cypress si tu equipo ya tiene una inversión importante en él, pero la mayoría de los proyectos nuevos que empezamos van a Playwright.
- ¿Podéis integraros con nuestra CI?
- Sí: GitHub Actions, CircleCI, Buildkite, GitLab CI, Jenkins. Diseñamos la CI como un entregable de primer nivel: paralelización, sharding, políticas de reintento y un resumen de fallos razonable que cabe en un mensaje de Slack.
- ¿Qué pasa después de la colaboración?
- Te entregamos un manual del «Test Owner» que cubre cuándo borrar tests, cuándo arreglarlos y cuándo escribir otros nuevos. El error más habitual que vemos es tratar los tests como algo que «se escribe una vez»: necesitan un responsable, igual que el código de producto. Nosotros dejamos montado el rol, pero alguien de tu equipo tiene que asumirlo.
Quién lo construye
Nuestro propio equipo, que trabaja desde nuestra oficina en Istočno Sarajevo, Bosnia y Herzegovina. Los ingenieros de tu llamada para definir el alcance son quienes lo construyen.
Conoce al equipo