Es jueves en la tarde y el pase a producción está agendado para el lunes. El equipo corre la suite de pruebas: 40 tests en rojo. Nadie cambió esas pantallas; alguien movió un botón y renombró un campo. Lo que sigue son dos días arreglando selectores en vez de probar lo que de verdad cambió en esta versión.
Las pruebas de software automatizadas existen hace décadas, pero la IA cambió quién las escribe y cuánto cuesta mantenerlas. Hoy un asistente puede escribir pruebas unitarias a partir del código o reparar un test que se rompió porque alguien movió un botón. Eso ahorra trabajo de verdad. Lo que la herramienta no hace es decidir qué vale la pena probar, y tampoco se da cuenta cuando una regla de negocio quedó mal entendida desde el principio. En este artículo revisamos qué parte del QA automatizado se puede delegar a la IA, dónde sigue haciendo falta criterio humano y qué preguntarle a un proveedor que te ofrezca "testing con IA".
Qué dicen los datos sobre el testing con IA
El World Quality Report 2025 de Capgemini, Sogeti y OpenText, publicado en noviembre de 2025 a partir de una encuesta a más de 2.000 ejecutivos en 22 países, entrega un panorama bastante sobrio:
- El 89% de las organizaciones está probando o usando IA generativa en sus procesos de calidad, pero solo el 15% la tiene desplegada a escala de toda la empresa.
- La ganancia de productividad promedio reportada es de 19%, aunque un tercio de las organizaciones vio mejoras mínimas.
- Los principales obstáculos son los riesgos de privacidad de datos (67%), la complejidad de integración (64%) y las alucinaciones o falta de confiabilidad (60%).
- El uso se está moviendo desde analizar resultados (reportes de defectos) hacia el diseño de casos de prueba y el refinamiento de requisitos.
Nuestra lectura: casi todos están probando, pocos lo tienen funcionando en serio, y lo que separa a unos de otros tiene más que ver con el proceso que con la herramienta elegida.
Qué se puede automatizar hoy con IA
La IA rinde mejor donde el resultado se verifica rápido. La prueba compila y pasa, o no pasa.
Pruebas unitarias a partir del código
En el mundo .NET, Microsoft documenta GitHub Copilot testing para .NET, que genera las pruebas en un proyecto aparte, las compila, intenta corregir errores y las ejecuta en Test Explorer. Requiere Visual Studio 2026 versión 18.3 o superior y una suscripción pagada de GitHub Copilot, y funciona con MSTest, NUnit y xUnit. Para otros lenguajes, la mayoría de los asistentes de código ofrece algo parecido, aunque con menos integración.
Pruebas de extremo a extremo en aplicaciones web
Playwright incluye tres agentes de prueba: uno que explora la aplicación y escribe un plan de pruebas en Markdown, otro que convierte ese plan en tests ejecutables y un tercero que corre la suite y repara los tests que fallan. Microsoft también publica guías para usar Playwright con asistentes de IA en aplicaciones de Power Platform, donde la recomendación final es explícita: revisar el test generado antes de hacer commit.
Mantenimiento de pruebas de regresión
Es la escena del inicio. Cuando un test falla porque cambió un selector o un tiempo de carga, un agente puede proponer el ajuste y volver a correrlo. Ahí está el ahorro más interesante, porque mantener la suite es justamente lo que hace que muchos equipos abandonen la automatización a los pocos meses.
Datos de prueba y casos borde
La IA es buena sugiriendo combinaciones que nadie anotó: RUT con dígito verificador K, montos en cero, fechas de fin de mes, textos con tildes y eñes.
Dónde sigue haciendo falta criterio humano
Una prueba generada por IA verifica lo que el código hace. No sabe lo que el código debería hacer. Si la regla de cálculo de una comisión está mal implementada, la IA puede escribir, muy prolija, una prueba que confirma el error.
Por eso hay decisiones que no conviene delegar:
| Tarea | ¿Se puede delegar a la IA? | Comentario |
|---|---|---|
| Generar pruebas unitarias de funciones existentes | Sí, con revisión | Revisar que las aserciones prueben reglas de negocio, no solo que "no explota" |
| Proponer un plan de pruebas E2E | Parcialmente | Sirve como borrador; alguien que conozca el proceso debe priorizar |
| Reparar tests rotos por cambios de interfaz | Sí, con revisión | Ojo con el agente que "arregla" un test ocultando un bug real |
| Definir criterios de aceptación | No | Es una conversación con el negocio |
| Decidir qué riesgos cubrir primero | No | Depende del impacto de cada falla en la operación |
| Pruebas de seguridad y permisos | Solo como apoyo | Requiere a alguien que piense como atacante |
| Pruebas exploratorias y de usabilidad | No | La IA no se frustra con una pantalla confusa |
Con el agente que repara tests hay que tener cuidado. La propia documentación de Playwright indica que, si el agente cree que la funcionalidad está rota, puede dejar el test marcado como omitido. Si nadie revisa esos tests omitidos, la suite queda verde y el bug llega igual a producción.
El riesgo que se suele pasar por alto: los datos
El World Quality Report pone la privacidad de datos como el principal obstáculo, y en Chile tiene una arista concreta. Para generar pruebas, la herramienta necesita ver código, esquemas y muchas veces datos. Si el ambiente de pruebas es una copia de producción con RUT, direcciones y sueldos reales, esos datos pueden terminar en el contexto de un modelo externo.
La Ley 21.719 de protección de datos personales hace que esto deje de ser solo una buena práctica. Revisamos el tema en detalle en Datos reales en ambientes de prueba y la Ley 21.719. En la práctica, la regla es usar datos sintéticos o anonimizados para las pruebas y saber qué herramientas de IA tienen acceso al repositorio y bajo qué condiciones.
Qué exigirle a un proveedor de desarrollo
Si vas a contratar desarrollo a medida y el proveedor dice que usa IA para el QA, estas preguntas separan una práctica real de una frase comercial:
- ¿Qué tipos de prueba entregan y en qué proporción? Unitarias, de integración y de extremo a extremo. Pide ver la suite, no solo el porcentaje de cobertura.
- ¿Quién revisa las pruebas que genera la IA? Debe haber un responsable con nombre, y la revisión debe quedar en el pull request.
- ¿Las pruebas corren en cada cambio? Si no están conectadas a un pipeline de CI/CD, se dejan de ejecutar en pocas semanas.
- ¿Con qué datos prueban? La respuesta aceptable es datos sintéticos o anonimizados, nunca una copia directa de producción.
- ¿Qué herramientas de IA ven el código y con qué condiciones de uso? Vale la pena saber si el proveedor usa planes empresariales o cuentas personales.
- ¿Las pruebas son parte del entregable? Al terminar el proyecto, la suite debe quedar en tu repositorio, documentada y ejecutable por otro equipo.
Este último punto se conecta con lo que conviene pedir en cada etapa de un proyecto; lo explicamos en Diseño y desarrollo de software: etapas y entregables.
Por dónde empezar
Si tu sistema hoy no tiene pruebas automatizadas, no partas por los agentes: terminarías con cientos de tests que nadie entiende. Nos ha funcionado este orden:
- Elige los tres o cuatro flujos que más duelen cuando fallan (facturación, cálculo de remuneraciones, despacho, lo que aplique).
- Escribe con el equipo de negocio los criterios de aceptación de esos flujos.
- Usa la IA para generar las pruebas de esos flujos y revísalas una por una.
- Conéctalas al pipeline para que corran en cada cambio.
- Recién ahí amplía la cobertura y suma agentes de mantenimiento.
Preguntas frecuentes
¿La IA reemplaza al equipo de QA?
No. Le quita trabajo repetitivo, como escribir pruebas básicas o arreglar selectores, pero alguien tiene que decidir qué probar, revisar lo que genera la herramienta y hacer pruebas exploratorias.
¿Las pruebas generadas por IA son confiables?
Lo son cuando alguien las revisa. Una prueba generada puede confirmar un comportamiento incorrecto si la regla de negocio estaba mal implementada. La revisión humana en el pull request es lo que les da valor.
¿Puedo usar datos de producción para que la IA genere pruebas?
No es recomendable. Con la Ley 21.719, exponer datos personales reales en ambientes de prueba o en herramientas externas es un riesgo legal además de técnico. Lo correcto es trabajar con datos sintéticos o anonimizados.
Calidad desde el primer sprint
En Disrupsoft desarrollamos aplicaciones web y móviles a medida, con GitHub y CI/CD como parte del trabajo diario. Si estás evaluando un proyecto y quieres revisar desde el inicio cómo se va a probar, conversemos sobre tu desarrollo a medida.
