Hoy muchos equipos de QA en Chile viven la misma tensión: sprints cada vez más cortos, arquitecturas más complejas y usuarios menos tolerantes a los errores, mientras los procesos de prueba siguen apoyándose en automatizaciones frágiles y mucho trabajo manual.
La automatización tradicional ayudó a ejecutar más rápido, pero chocó con límites conocidos. Los scripts se rompen ante cambios pequeños en la interfaz, las suites tardan horas en ejecutarse, la cobertura en áreas críticas es irregular y cuesta explicar el riesgo real al directorio o a las áreas de negocio. En paralelo, la presión por lanzar nuevas funcionalidades no disminuye.
En ese contexto, IA en Testing QA significa usar inteligencia artificial (machine learning, grandes modelos de lenguaje, visión computacional) para diseñar, ejecutar, priorizar y mantener pruebas de software de forma más inteligente que con reglas fijas. No se trata solo de “automatizar más”, sino de tomar mejores decisiones sobre qué probar, cuándo y con qué profundidad.
Entre 2024 y 2025, muchas organizaciones en Chile y el mundo comenzaron a experimentar con estas capacidades: pilotos, POC, primeros acercamientos a herramientas que prometen autocuración de scripts, generación de casos de prueba y priorización basada en riesgos. La pregunta que hoy se hacen los líderes de TI y QA ya no es si la IA llegará al testing, sino qué tan rápido se volverá parte del modelo operativo estándar.
Todo indica que 2026 será un punto de inflexión: el momento en que la IA en Testing QA deja de ser un experimento en paralelo y empieza a integrarse de forma sistemática en el ciclo de vida del software.
Para entender la magnitud del cambio, vale la pena mirar algunas cifras. El World Quality Report 2024–25 elaborado por Capgemini, sobre la base de más de 1.700 encuestas a ejecutivos de TI y QA, muestra que alrededor de un 68% de las organizaciones ya utiliza IA generativa para avanzar en quality engineering. Más de tres cuartas partes declaran estar invirtiendo en IA para procesos de QA y pruebas.
Resúmenes de este mismo informe y de otros análisis de la industria indican que los equipos que incorporan herramientas de testing apoyadas en IA han logrado reducir el esfuerzo de mantenimiento de scripts hasta en un 70% y mejorar la estabilidad de los pipelines de pruebas alrededor de un 50% cuando la adopción es madura. En algunos casos se reportan reducciones de entre 60% y 80% de defectos en producción y ciclos de salida a producción entre 40% y 50% más rápidos, al combinar IA con estrategias de shift-left y automatización continua.
Al mismo tiempo, varios estudios coinciden en que muchas organizaciones siguen atrapadas en la fase de experimentación. Se prueban pilotos aislados, pero solo una parte de ellos llega a producción. Las razones se repiten: falta de gobierno de datos, dificultades de integración con pipelines existentes y brechas de capacidades internas en los equipos de QA.
En concreto no es que la IA sea una varita mágica. La conclusión es que ya existe evidencia suficiente de impacto como para tratar la IA en testing como parte de la estrategia de calidad y no solo como una curiosidad tecnológica.
Cuando se habla de Smart Test Design, se hace referencia al uso de IA para generar, optimizar y priorizar casos de prueba a partir de código, requisitos, historias de usuario y datos reales de uso.
La idea es que los modelos puedan leer historias de usuario, criterios de aceptación, documentación funcional, cambios en el código y logs de producción para proponer nuevos casos, datos de prueba y escenarios completos de extremo a extremo.
La diferencia con el enfoque tradicional es sutil, pero poderosa. En lugar de que el tester tenga que diseñar manualmente casi todo, la IA propone una base sobre la cual el equipo ejerce criterio: acepta, ajusta o descarta. El valor se desplaza desde la “producción masiva” de casos hacia la selección inteligente de los casos que realmente ayudan a gestionar el riesgo del negocio.
En la práctica, esto permite aumentar la cobertura sin inflar el tamaño del equipo, acercar los casos de prueba al uso real en producción y reducir el tiempo invertido en “partir de cero” en cada funcionalidad nueva.
Otro caso de uso muy mencionado es el de los tests autocurativos, o self-healing tests. Aquí la IA se encarga de detectar cambios en la interfaz o en la estructura del sistema y ajustar los scripts de forma automática. Si el ID de un botón cambió, si un campo se movió de lugar o si apareció una nueva variante visual, el modelo intenta identificar el elemento correcto por contexto y actualizar el selector sin intervención manual.
Esto es especialmente valioso en aplicaciones de banca digital, retail o seguros, donde la interfaz cambia con frecuencia por campañas, ajustes normativos o nuevas funcionalidades. En muchos equipos, el mantenimiento de scripts de interfaz consume una porción considerable del tiempo de automatización. Reducir ese esfuerzo, a la vez que se gana estabilidad, libera capacidad para pruebas de más alto valor.
La idea de QA predictivo es utilizar IA para anticipar dónde es más probable que aparezcan defectos antes de que el software llegue a producción. Los modelos cruzan información sobre historial de bugs, complejidad del código, volumen de cambios, métricas de rendimiento y patrones de uso de los clientes.
Con esa información se construyen mapas de riesgo que ayudan a responder preguntas como: “Si solo puedes probar en profundidad una parte del sistema en este sprint, ¿Qué parte tiene más sentido cubrir?”. En industrias reguladas o muy expuestas al cliente final, como la banca y los seguros, esta priorización basada en datos puede marcar una diferencia importante en términos de incidentes, reclamos y cumplimiento normativo.
El testing exploratorio asistido por IA combina el criterio humano del tester con un “copiloto” capaz de sugerir rutas, datos y escenarios poco habituales. Mientras el tester recorre la aplicación, la IA puede proponer atajos a zonas históricamente problemáticas, sugerir valores de borde o recordar casos extremos que suelen causar errores.
Otra dimensión interesante es la capacidad de registrar lo que hace el tester y transformarlo en casos automatizables. Lo que antes quedaba como “saber tácito” del equipo se convierte en artefactos reutilizables que alimentan la estrategia de pruebas. Lejos de reemplazar el olfato del tester, la IA actúa como un amplificador.
Finalmente, la IA también empieza a modificar la forma en que se prueba el rendimiento y la carga. Tradicionalmente los escenarios se diseñan con patrones sintéticos: cierta cantidad de usuarios concurrentes, tanto tráfico por minuto, y así. Con IA, los modelos pueden aprender del comportamiento real de los usuarios para generar perfiles de carga más parecidos a la realidad.
Esto permite simular picos similares a fin de mes en un banco, al Cyber en un retail o a ciertas campañas en seguros, sin depender de suposiciones estáticas. El resultado es un performance testing que conversa mejor con lo que de verdad ocurre en producción.
El concepto de shift-left testing lleva años circulando, pero muchas organizaciones todavía lo viven como un objetivo aspiracional. La IA hace más concreto ese movimiento hacia la izquierda. Cuando cada pull request puede gatillar análisis automáticos de impacto, generación de pruebas unitarias sugeridas y selección dinámica de suites relevantes, la calidad empieza a incorporarse en el día a día del desarrollo.
El efecto no se ve solo en QA, sino en el conjunto del ciclo: menos defectos críticos escapando a producción, menos re-trabajo en etapas tardías y una conversación más fluida entre desarrollo, QA y negocio sobre el estado real de cada release.
Para un gerente de TI o de QA, la discusión no se cierra con “tenemos IA”, sino con métricas. Algunas de las que suelen moverse cuando se adopta IA en Testing QA de forma seria son:
El tiempo de mantenimiento de scripts, especialmente en pruebas de interfaz.
El número de defectos críticos que llegan a producción por release.
El tiempo de ciclo de QA, desde que se abre una historia hasta que se valida.
La cantidad de pruebas inestables o “flaky”.
La cobertura real en módulos o servicios de alto riesgo.
La combinación de estas métricas ofrece una visión más completa de cómo evoluciona la calidad. Permite dejar atrás la conversación centrada solo en “cantidad de casos de prueba” y avanzar hacia una mirada de riesgo gestionado y experiencia de cliente.
La IA no solo trae nuevas herramientas. Cambia el perfil del equipo de QA. El tester que aporta más valor ya no es únicamente quien domina una herramienta de automatización, sino quien entiende el negocio, sabe leer datos y se siente cómodo trabajando con modelos de IA como parte de su flujo diario.
No se trata de convertir a todo el mundo en data scientist, pero sí de desarrollar una base común: conceptos de machine learning y LLM, comprensión de cómo se construyen y evalúan los modelos, sensibilidad frente al uso de datos de prueba y capacidad para interpretar dashboards y recomendaciones automáticas.
Uno de los riesgos menos visibles es confiar demasiado en lo que dice la IA. Suites generadas automáticamente que nadie revisa, priorizaciones de riesgo aceptadas sin entender sus criterios, reportes que muestran “todo verde” mientras los usuarios siguen encontrando problemas: son situaciones más comunes de lo que parece.
La respuesta no es desconfiar de la IA, sino mantener una mirada crítica estructurada. Definir qué decisiones puede tomar un modelo sin supervisión y cuáles requieren revisión humana. Establecer revisiones periódicas de reglas y modelos, y diseñar espacios donde QA y negocio puedan cuestionar las recomendaciones cuando algo no calza con la realidad del usuario.
Para que la IA funcione en testing necesita datos: logs, errores, patrones de uso, características de los clientes, métricas de rendimiento. Muchas veces esa información está cerca de producción, e incluso es imposible replicarla exactamente en un entorno aislado.
Aquí aparece un segundo bloque de desafíos: privacidad, seguridad y cumplimiento normativo. ¿Qué datos se usan para entrenar o alimentar modelos? ¿Cómo se anonimiza o pseudonimiza la información? ¿Dónde se guardan esos datos y quién puede acceder? ¿Cómo se asegura que la práctica de QA alinee lo que se hace con la legislación de protección de datos y con los estándares de cada industria?
Para sectores como la banca y los seguros, esto implica que QA no puede trabajar aislado. TI, Ciberseguridad, Legal y Riesgo tienen que acordar políticas de datos de prueba, controles de acceso y responsabilidades claras en torno al uso de modelos.
Los modelos de IA pueden exagerar patrones, pasar por alto casos minoritarios o directamente inventar resultados. En el contexto de testing, esto puede llevar a casos de prueba irrelevantes, a subestimar riesgos en ciertos módulos o a resúmenes de resultados que no reflejan lo que el usuario vivirá.
Por eso, las organizaciones más maduras avanzan hacia la construcción de un catálogo de modelos usados en QA: qué hace cada uno, qué datos utiliza, quién es responsable de su mantenimiento. También definen procedimientos de actualización y retraining cuando cambian la arquitectura, el negocio o el comportamiento de los usuarios, y establecen mecanismos para auditar cómo se llegó a ciertas decisiones automatizadas.
El primer paso suele ser explorar pilotos pequeños, con bajo riesgo y un objetivo principal: aprender. Por ejemplo, usar IA para ampliar el diseño de casos de prueba en un módulo específico, probar capacidades de autocuración de scripts en un conjunto acotado de pantallas, o incorporar un copiloto que ayude a documentar y resumir resultados.
Lo importante en esta etapa no es “ganar en grande”, sino medir. Cuánto tiempo se ahorra, cómo cambia la estabilidad de los tests, cómo percibe el equipo la utilidad de estas capacidades.
El segundo nivel comienza cuando la IA deja de ser un experimento y empieza a participar en decisiones de todos los días. Por ejemplo, al integrar herramientas de IA en el pipeline de CI/CD para que seleccionen qué pruebas ejecutar según el impacto del cambio, generar datos de prueba sintéticos de forma sistemática o priorizar defectos en función de su severidad y del impacto en negocio.
En este punto, QA ya no es solo “usuario de una herramienta con IA”, sino también diseñador de reglas y criterios para esa IA.
El nivel más avanzado no tiene que ver con funcionalidades nuevas, sino con la forma en que la organización entiende la calidad. La IA pasa a ser parte estable de la estrategia, con un marco de gobierno que define qué hace la máquina, qué hace la persona y cómo se audita el conjunto.
Aquí aparecen KPIs de calidad que se reportan a niveles directivos, donde conviven métricas técnicas (defectos, tiempos de ciclo, disponibilidad) con indicadores de riesgo y experiencia. También se vuelve central el upskilling continuo: capacitar a testers, líderes de QA y líderes de TI para sacar provecho de este nuevo contexto.
En este nivel, QA deja de percibirse como “el equipo que testea al final” y se posiciona como uno de los pilares de la confianza digital de la organización.
Aun así, hay tropiezos que se repiten. Comprar herramientas antes de tener claro qué problema se quiere resolver.
Son errores comprensibles, pero evitables si la conversación se plantea desde el principio como una transformación de modelo de trabajo y no solo como un cambio de stack tecnológico.
Si algo deja claro esta evolución es que el rol del tester cambia. En 2026, el tester de mayor impacto se parecerá menos a un “ejecutor de scripts” y más a un arquitecto de calidad aumentada. Será alguien que entiende el negocio, que sabe dónde duele un fallo, que puede dialogar con desarrolladores, con modelos de IA y con gerencias en un mismo lenguaje.
Esa persona no pierde relevancia frente a la IA; la gana. Porque en entornos complejos, regulados y cambiantes, lo que más falta no son herramientas, sino criterios. La IA ayuda a ver más, pero no reemplaza la necesidad de decidir mejor.
La idea central se resume en una frase sencilla:
la IA no va a sustituir al QA, pero sí va a reemplazar la forma en que se ha hecho QA hasta ahora.
Los equipos que combinen experiencia humana, automatización clásica y capacidades de IA podrán detener defectos antes de que lleguen a producción, reducir tiempos de ciclo sin sacrificar calidad y conversar de igual a igual con negocio sobre riesgo y experiencia de cliente. Para sectores como banca, retail y seguros en Chile, eso no es un lujo, es una condición de competitividad.
Definir cómo se dará ese paso en cada organización requerirá conversaciones internas y, probablemente, apoyo externo. En ese punto tiene sentido mirar experiencias y prácticas de actores que ya están combinando quality engineering, datos e IA a escala. Desde Chile, ACL powered by DataArt participa de ese ecosistema y comparte sus aprendizajes en su página de QA con IA y en los contenidos de Quality Engineering de DataArt.
Si tu equipo de QA ya siente la presión de más releases, más complejidad y menos margen de error, este es el momento para empezar a incorporar IA de forma planificada, no impulsiva.
En ACL powered by DataArt te apoyamos a:
👉 Conversemos cómo llevar la IA a tu estrategia de calidad de aquí a 2026, partiendo por tus pipelines, métricas y procesos actuales de QA.