Cada par de meses vuelve la misma pregunta en LinkedIn, en foros, en charlas de pasillo: ¿la inteligencia artificial va a reemplazar al QA? La pregunta está mal planteada, y por eso las respuestas tienden a ser igual de vagas — “no, la IA complementa al QA” o “sí, pero solo lo repetitivo”. Ninguna de las dos dice nada útil.
La pregunta correcta es otra: ¿cuánto de lo que hace un QA hoy es trabajo que nunca debería haber sido manual?
El trabajo que la IA “reemplaza” ya estaba mal diseñado
Cuando un equipo dice “la IA me reemplazó la regresión manual”, lo que en realidad pasó es que existía un proceso de regresión manual que dependía de que una persona ejecutara, a mano, los mismos pasos, release tras release, durante meses. Eso no era “el trabajo de un QA”. Era una tarea operativa que se le había asignado a un QA porque nadie había invertido el tiempo en automatizarla.
La IA no reemplazó al tester. Reemplazó una decisión de diseño de proceso que ya estaba vencida.
Lo mismo pasa con la documentación de casos de prueba escritos a mano desde cero, con el triage manual de logs repetitivos, o con la generación de datos de prueba copiando y pegando valores de un Excel. Son tareas que existen porque automatizarlas nunca fue prioridad — no porque requirieran juicio humano.
Lo que la IA todavía no puede hacer (y probablemente no va a poder)
Donde la IA se cae es exactamente donde el QA aporta más valor:
- Decidir qué es un riesgo aceptable. Una IA puede generar veinte casos de prueba para un flujo de checkout. No puede decidir si ese flujo es lo suficientemente crítico como para bloquear un release si falla un caso de borde.
- Leer el contexto de negocio. Un bug en un campo de texto de un blog interno no pesa igual que un bug en el cálculo de un monto a cobrar. Esa priorización requiere entender el negocio, no solo el código.
- Detectar que el requerimiento está mal escrito. La IA genera casos de prueba a partir de lo que le das. Si la historia de usuario es ambigua, la IA va a generar ambigüedad con más velocidad. El QA que lee entre líneas y pregunta “¿esto qué pasa si…?” sigue siendo insustituible.
- Mantener la trazabilidad y el criterio de cobertura a través del tiempo. Una suite de tests generada automáticamente sin estrategia de mantenimiento se vuelve frágil en semanas. El criterio de qué mantener, qué retirar y por qué, es trabajo humano.
El riesgo real no es que la IA reemplace al QA
El riesgo real es que los equipos usen IA para automatizar más rápido procesos que ya estaban rotos, y terminen con un problema más grande: ahora generan ruido a mayor velocidad. Más tests frágiles, más falsos positivos, más cobertura que no significa nada porque nadie diseñó qué cubrir y por qué.
La IA bien aplicada en testing no es “generame tests”. Es usar la IA para sacarle al QA el trabajo mecánico — generación de casos a partir de criterios de aceptación, mantenimiento de suites, triage inicial de fallos — para que el tiempo humano se concentre en lo que de verdad mueve la aguja: criterio, priorización por riesgo y diseño de estrategia de calidad.
Esa es la diferencia entre “la IA reemplaza al QA” y “la IA libera al QA para que haga el trabajo que en realidad importa”. No es una discusión filosófica. Es una decisión de cómo diseñás tu proceso.
¿Querés revisar qué parte de tu proceso de QA es trabajo mal diseñado disfrazado de trabajo manual? Agendemos un diagnóstico.