5 cosas que la IA hace mejor que yo en QA — y 3 donde falla horrible
Tabla de contenidos
Uso IA en mi flujo de trabajo diario como QA. No como experimento. Como herramienta real.
No hablo de “el futuro del testing” ni de demos bonitas en conferencias. Hablo de abrir Claude a las 8am, pasarle un user story, y que a las 8:30 tenga casos de prueba que antes me tomaban toda la mañana.
Después de meses de uso honesto — con éxitos y con fracasos — tengo una lista muy clara de dónde la IA me supera y dónde falla horrible. Sin humo.
Donde la IA me supera
1. Generar casos de prueba desde user stories
Lo que antes me tomaba una mañana entera ahora son 30 minutos. Le paso el user story con sus criterios de aceptación y me devuelve happy path, negativos y edge cases que yo habría agregado recién en la segunda revisión.
Pero el truco está en cómo le pides. No es “generame test cases para un login”. Es darle contexto: el rol del usuario, las reglas de negocio, las restricciones técnicas, los datos que maneja el sistema.
Ver ejemplo real de cómo le pido test cases a la IA
Eres QA Senior. Genera casos de prueba para este user story:
[pego el user story completo con criterios de aceptación]
Incluye:- Happy path- Casos negativos (datos inválidos, campos vacíos, formatos incorrectos)- Edge cases (límites numéricos, caracteres especiales, concurrencia)- Casos de seguridad (inyección SQL, XSS en campos de texto)
Formato: tabla con columnas ID, Descripción, Precondiciones, Pasos,Resultado esperado, PrioridadEl output no es perfecto. Pero es un borrador de alta calidad que puedo refinar en minutos en vez de construir desde cero.
2. Sugerir escenarios que no consideré
Esto me dolió aceptarlo.
Hay combinaciones de datos y flujos alternativos que la IA detecta antes que yo. No porque sea más inteligente. Porque no tiene los sesgos de “esto nunca pasa” o “el usuario nunca haría eso”.
Después de 15 años testeando, desarrollas intuición — pero también desarrollas puntos ciegos. Sabes qué suele fallar y te enfocas ahí. La IA no tiene esa historia. Le da el mismo peso a cada camino posible.
En un proyecto reciente, le pasé mis test cases ya escritos y le pedí: “¿qué escenarios me faltan?”. Me sugirió un caso de concurrencia — dos usuarios editando el mismo registro al mismo tiempo. No es un escenario exótico. Es algo que pasa en producción. Y yo lo había pasado por alto porque “nunca nos lo reportaron”.
3. Detectar gaps en cobertura
Le paso mis test cases existentes junto con los criterios de aceptación del story, y me dice qué falta. Criterios de aceptación sin cubrir. Flujos alternativos ignorados. Condiciones de borde que nadie probó.
Es como tener un peer review instantáneo. Y a diferencia de un compañero humano, no tiene reuniones, no está apurado, y no te dice “se ve bien” por compromiso.
Esto es especialmente valioso cuando heredas una suite de tests de otro QA. Le pasas los tests + los requerimientos y en 5 minutos tienes un mapa de qué está cubierto y qué no.
4. Documentación y reportes repetitivos
Resúmenes de ejecución, reportes de bugs, matrices de trazabilidad, notas de release.
La IA no se aburre. Yo sí.
Hay tareas que son necesarias pero mecánicas. Escribir el reporte de un bug con pasos para reproducir, resultado esperado, resultado actual, evidencia — lo he hecho miles de veces. El formato no cambia. La estructura no cambia. Lo que cambia son los datos.
Le paso el log del error, el screenshot, y el contexto del flujo. Me devuelve el bug report formateado. Lo reviso, ajusto lo que haga falta, y lo publico en Jira.
5. Automatizar reportes cruzando múltiples herramientas
Esta es la que más impacto tiene en mi día a día y la que menos gente conoce.
Tengo un flujo automatizado que cruza datos de Jira con Notion para generar mis reportes de standup. En vez de abrir Jira, filtrar tickets del sprint, revisar estados, copiar datos y formatear un reporte manualmente — lo hago con un solo comando.
Lo que antes me tomaba 30-40 minutos cada mañana ahora toma menos de 2 minutos. Y el reporte es más completo y consistente que el que hacía a mano, porque no se me olvida ningún ticket ni me equivoco calculando métricas.
MCP (Model Context Protocol) le da a la IA acceso directo a tus herramientas. Sin MCP, tendrías que copiar y pegar datos entre Jira, Notion y Claude manualmente. Con MCP, la IA lee y escribe en tus herramientas directamente.
Donde falla horrible
1. Genera casos de prueba redundantes
Le pides 20 test cases y te da 40. De esos 40, fácilmente 15 son variaciones del mismo escenario con datos ligeramente diferentes.
Sin criterio humano para filtrar, terminas con más ruido que cobertura. El equipo de desarrollo ve 40 test cases y piensa “esto es demasiado”. Y tiene razón — pero no porque haya que testear menos, sino porque la IA no sabe priorizar.
La solución: siempre le pido que agrupe por funcionalidad y priorice. Y aun así, reviso y consolido. El output de la IA es materia prima, no producto terminado.
2. Sin instrucciones específicas, el output es genérico
Si le dices “generame test cases para un login” te da lo mismo que le daría a cualquier persona en el mundo. Campos vacíos, contraseña incorrecta, usuario no existe. Lo básico.
Pero tu login no es “un login”. Tu login tiene reglas específicas: bloqueo después de 3 intentos, OTP por SMS, sesión que expira en 30 minutos, redirección según el rol del usuario, integración con SSO.
La calidad del output depende 100% de la calidad de tu prompt. Y escribir un buen prompt requiere saber de testing primero. No puedes pedirle a la IA que considere escenarios de concurrencia si no sabes qué es concurrencia.
La IA multiplica lo que ya sabes. Si sabes poco, multiplica poco. Si sabes mucho, es imparable.
3. Siempre necesita revisión humana
Siempre. Sin excepción.
No importa qué tan bueno sea el prompt. No importa qué tan avanzado sea el modelo. El output es un borrador, no un entregable.
- Assertions que validan lo incorrecto (el test pasa pero no verifica lo que debería) - Selectores CSS inventados que no existen en la aplicación - Flujos técnicamente imposibles por restricciones del sistema - Tests que pasan siempre — no porque el código esté bien, sino porque el test no verifica nada
Si confías ciegamente, puedes entregar basura con buena gramática. Y eso es peor que no tener tests, porque te da una falsa sensación de seguridad.
Mi regla: cada test generado por IA pasa por el mismo code review que cualquier test escrito por un humano. Si no entiendes qué valida, no lo publiques.
Lo que aprendí
La IA no reemplaza a un QA. Reemplaza las horas que un QA desperdicia en tareas mecánicas.
No me hizo peor QA. Me hizo más rápida. Las horas que antes gastaba escribiendo boilerplate, formateando reportes y generando el primer draft de test cases, ahora las uso en lo que realmente importa: pensar en la estrategia, analizar riesgos, y cuestionar requerimientos.
Pero para llegar ahí necesité tres cosas:
-
Saber de testing antes de usar IA. La IA amplifica lo que ya sabes. Si no entiendes la diferencia entre un caso límite y un caso negativo, la IA tampoco te la va a enseñar.
-
Aprender a escribir prompts específicos. “Generame tests” no sirve. “Genera tests para un flujo de pago con tarjeta expirada, saldo insuficiente y doble cobro, considerando que el sistema usa pasarela X con timeout de 30 segundos” — eso sí sirve.
-
Nunca confiar ciegamente. Revisar cada output. Cuestionar cada sugerencia. La IA es el junior más productivo del equipo, pero sigue siendo un junior. Necesita supervisión.
La pregunta ya no es si usar IA en QA. La pregunta es si estás dispuesta a invertir el tiempo en aprender a usarla bien — o si prefieres que alguien más lo haga y te saque ventaja.