Le pides a un chat de IA que te genere casos de prueba para un formulario de login y en cinco segundos tienes veinte líneas. El problema es que la mitad no sirve para nada: prueban lo obvio, se inventan campos que el formulario no tiene o repiten el mismo caso con palabras distintas.
No es un problema de la herramienta, es un problema de cómo se usa. El informe State of QA Automation 2026 de Quash (abril 2026) encontró que el 72% de los profesionales de QA ya usa IA para generar tests u optimizar scripts, pero que casi 9 de cada 10 organizaciones están experimentando con IA generativa en calidad sin haberla llevado de verdad a producción: solo 1 de cada 7 la tiene operativa a escala.
En este artículo no te cuento el potencial genérico de la IA en testing. Te enseño el prompt que uso yo para que el resultado sirva de verdad, qué técnicas de casos de prueba genera bien y cuáles hay que revisar siempre a mano, y los errores que veo más a menudo cuando alguien empieza a usarla para esto.
El primer dato es de Quash, State of QA Automation 2026 (abril 2026). El segundo, del Software Quality Pulse Report de Sembi (mayo 2026, casi 4.000 profesionales de QA, desarrollo y seguridad encuestados). El tercero, del State of AI in Software Testing 2026 de BrowserStack (enero 2026, más de 250 responsables de ingeniería y QA en Estados Unidos, Reino Unido y Europa): el 94% de los equipos ya usa IA en testing de alguna forma, pero solo el 12% ha llegado a una autonomía real. La brecha entre "lo prueba alguien" y "lo tiene integrado en el flujo de verdad" es el patrón que se repite en los tres informes, y encaja con lo que veo en el día a día: mucha gente prueba un prompt suelto, casi nadie tiene un proceso.
Qué genera bien la IA (y qué no)
La IA es rápida generando volumen a partir de tres técnicas concretas de diseño de casos de prueba. Si no las conoces todavía, antes de meter IA en el proceso vale la pena leer cómo escribir casos de prueba en QA: técnicas reales, porque ninguna herramienta compensa no saber qué le estás pidiendo.
Agrupa valores de entrada que deberían comportarse igual. La IA identifica bien los grupos si le das el rango o la regla de negocio exacta.
Genera bien los casos justo en el borde de una condición (el mínimo, el máximo, uno por debajo, uno por encima) si le das el límite exacto.
Es donde más aporta: piensa en inputs erróneos, vacíos o maliciosos que un humano cansado se salta a la tercera hora escribiendo casos.
Lo que no hace bien es priorizar. Te va a dar los 40 casos con el mismo peso, sin saber cuál protege una regla de negocio crítica y cuál es una variación irrelevante. Eso lo decides tú, con contexto que la IA no tiene.
El prompt que uso yo, paso a paso
No le pido "genera casos de prueba" a secas, eso es lo que da resultados genéricos. Le doy tres cosas siempre: el requisito exacto tal cual está en el ticket o la historia de usuario, el formato de salida que quiero (una tabla con columnas fijas), y la instrucción explícita de incluir casos negativos y valores límite, no solo el camino feliz.
Contexto: formulario de login con email y contraseña.
Reglas: el email debe tener formato válido. La contraseña
tiene un mínimo de 8 caracteres, con al menos 1 mayúscula
y 1 número. Máximo 5 intentos fallidos antes de bloquear
la cuenta durante 15 minutos.
Genera casos de prueba en una tabla con columnas:
ID, Escenario, Datos de entrada, Resultado esperado.
Incluye: camino feliz, valores límite en la longitud de
la contraseña (7, 8 y 9 caracteres), casos negativos
(email sin arroba, contraseña sin mayúscula, contraseña
sin número), y el comportamiento en el intento número
5 y 6.
No incluyas casos de interfaz visual, solo de lógica
de validación.Esto es lo que devuelve, resumido a las filas que más importan:
| ID | Escenario | Resultado esperado |
|---|---|---|
| CP-01 | Login con email y contraseña válidos | Acceso concedido |
| CP-02 | Contraseña de 7 caracteres | Rechazado, longitud mínima |
| CP-03 | Contraseña de 8 caracteres sin mayúscula | Rechazado, falta mayúscula |
| CP-04 | Email sin arroba | Rechazado, formato inválido |
| CP-05 | 6º intento fallido consecutivo | Cuenta bloqueada 15 minutos |
Esto ya es un punto de partida usable, no una lista genérica. Pero sigue sin ser el final: puede que CP-05 no aplique si tu sistema no bloquea cuentas, y te va a faltar casos que dependen de contexto que la IA no tiene, como qué pasa si el usuario ya tiene sesión abierta en otro dispositivo. Esa revisión la haces tú, no ella.
Errores que veo constantemente
- Pedir "todos los casos posibles" sin acotar. La IA genera decenas de variaciones redundantes que solo aportan ruido y alargan la ejecución sin sumar cobertura real.
- No dar el contexto de negocio. Sin las reglas exactas, la IA inventa validaciones que el sistema no tiene, y esos casos fallan por un motivo que no es un bug.
- Ejecutar los casos sin revisarlos antes. Algunos prueban comportamiento que ni siquiera está implementado en la versión actual del producto.
- No pedir un formato estructurado. Una lista de frases sueltas tarda más en convertirse en casos ejecutables que una tabla con columnas fijas desde el principio.
¿Esto sustituye a saber testing?
No. La IA acelera la parte mecánica de escribir casos, no la parte de decidir qué merece la pena probar. Eso sigue dependiendo de entender el producto, las reglas de negocio y qué falla importa de verdad para el usuario: exactamente lo que separa a un QA junior de uno que ya sabe priorizar.
Uso esto para arrancar más rápido, no para saltarme el criterio. El tiempo que ahorro escribiendo la primera versión de los casos lo invierto en revisar si de verdad cubren lo que importa, no en generar más volumen.
Si quieres ver cómo se integra la IA en el resto del trabajo diario de un QA (herramientas, agentes, flujo completo), lo cubro con más detalle en cómo usa un QA la IA en su trabajo. Y si tu producto es él mismo un sistema con IA, como un chatbot, el reto cambia: ahí entra en juego el testing no determinista, que trato en cómo probar productos con IA.
Preguntas frecuentes
¿Puede la IA sustituir a un QA a la hora de escribir casos de prueba?
No. Genera volumen rápido a partir de las reglas que tú le das, pero no sabe priorizar qué caso protege algo crítico ni conoce el contexto real del producto. Acelera la parte mecánica, no sustituye el criterio de decidir qué probar.
¿Qué IA es mejor para generar casos de prueba, ChatGPT o Claude?
No hay una diferencia decisiva documentada para este uso concreto: lo que más cambia el resultado es el prompt, no el modelo. Los modelos con ventana de contexto más grande manejan mejor un ticket largo o una especificación completa sin perder información a mitad, eso sí importa.
¿Cómo evito que la IA invente casos que no aplican a mi sistema?
Dándole las reglas de negocio exactas, no una descripción general. Cuanto más específico el contexto (límites numéricos, mensajes de error reales, comportamiento exacto del sistema), menos inventa la IA.
¿La IA genera bien valores límite y partición de equivalencia?
Sí, siempre que le des el rango o la regla exacta. Donde más falla es en casos negativos que dependen de contexto de negocio que no le has dado, y en priorizar cuáles de los casos generados importan de verdad.
¿Sirve esto para testing manual o solo para automatización?
Sirve para las dos cosas, pero de forma distinta. Para manual, te da el borrador de los casos que luego ejecutas a mano. Para automatización, es un punto de partida que hay que convertir en código, no un test automatizado que ya funciona.
¿Quieres aplicar esto en tu día a día como QA?
Aprende a integrar IA en tu flujo de trabajo real de QA, con casos prácticos y sin humo.