IA para QA: la guía práctica que me hubiera gustado tener
Tabla de contenidos
Eres QA y quieres usar la IA pero no sabes por dónde empezar en tu día a día. Lo sé porque me lo preguntan cada semana. Así que armé la guía que me hubiera gustado tener. No es una lista de herramientas. Es cómo pienso y en qué momentos la uso — y en cuáles no.
No voy a decirte qué herramienta usar. Usa la que te funcione: ChatGPT, Claude, Copilot, Gemini, la que sea. Lo que voy a mostrarte es en qué momento del día la necesitas, qué le pides, y cómo decides si lo que te devolvió sirve o no.
El problema nunca fue la herramienta. El problema es que nadie te enseñó cuándo abrirla.
1. Te cae un ticket nuevo
Este es el momento donde la IA tiene más impacto y donde menos gente la usa.
Te asignan una historia de usuario. Lo primero que hacemos como QA es leerla y tratar de entenderla. Pero hay una diferencia entre leer una historia y interrogarla.
Lo que yo hago: antes de escribir un solo caso de prueba, le paso la historia de usuario a la IA y le pido que me ayude a encontrar lo que no está escrito.
No le pido que me genere tests todavía. Le pido que me ayude a pensar.
Ver el prompt que uso para analizar historias de usuario
Eres QA Senior con experiencia en [tipo de aplicación: fintech / e-commerce / healthcare / etc.].
Te comparto esta historia de usuario:
[pego la HU completa con criterios de aceptación]
Antes de generar test cases, necesito que analices esta historia como lo haríaun QA en un refinamiento. Responde:
1. ¿Qué ambigüedades tiene esta historia? (términos vagos, criterios que se pueden interpretar de más de una forma)2. ¿Qué decisiones de negocio no están explícitas?3. ¿Qué escenarios de error no están contemplados?4. ¿Qué preguntas le harías al Product Owner antes de aceptar esta historia?
No generes test cases todavía. Solo el análisis.El resultado no es una lista de tests. Es una lista de preguntas que no se me habían ocurrido. Y esas preguntas, hechas a tiempo, ahorran semanas de retrabajo.
Porque le estás dando un rol (QA Senior), un contexto (el tipo de sistema), y una restricción clara (no generes tests, solo analiza). Esas tres cosas transforman el output de genérico a útil.
Tip: Si leíste mi artículo sobre el costo de no invitar a QA al refinamiento, esto es exactamente lo mismo — pero con la IA como compañera de análisis. Las tres preguntas base aplican igual: ¿qué pasa si falla? ¿Qué no está definido? ¿Quién sufre si sale mal?
2. Tienes que planificar qué testear
Ya entendiste la historia. Ya hiciste las preguntas. Ahora viene la decisión: ¿qué testas primero?
Aquí es donde muchos QAs le piden a la IA «generame los test cases» y obtienen una lista de 40 escenarios sin prioridad. Eso no ayuda. Eso abruma.
Lo que yo hago es pedirle que me ayude a priorizar por riesgo, no solo a listar.
Ver el prompt para generar test cases priorizados
Ahora sí, genera los test cases para esta historia.
Pero necesito que los priorices así:- P1 (Crítico): Si esto falla, el usuario pierde dinero, datos, o acceso- P2 (Alto): Si esto falla, el flujo principal no se completa- P3 (Medio): Flujos alternativos y edge cases importantes- P4 (Bajo): Mejoras de UX, validaciones cosméticas
Para cada test case incluye:- ID- Descripción (que se entienda sin contexto)- Precondiciones- Pasos- Resultado esperado- Prioridad (P1-P4)
Agrupa los que se puedan cubrir con un solo caso parametrizado.No incluyas más de 20 test cases. Si hay más, prioriza.No le pidas una lista. Pídele una lista ordenada por impacto. Ese simple cambio en el prompt transforma el output.
3. Estás escribiendo o manteniendo tests
Este es el momento más obvio — y donde más contenido genérico existe. «Usa IA para escribir tests.» Sí, pero ¿cómo exactamente?
Hay tres escenarios donde realmente me ahorra tiempo:
Generar la estructura base
No le pido que me escriba el test completo. Le pido el esqueleto. Yo lleno la lógica real.
Ver el prompt para generar estructura de tests
Genera la estructura base de un test automatizado en [Playwright / Cypress /el framework que uses] con TypeScript para este escenario:
[descripción del flujo a testear]
Incluye:- El describe y los bloques de test con nombres descriptivos en español- El beforeEach con navegación y setup necesario- Los test blocks vacíos con comentarios de qué debe validar cada uno- La estructura del Page Object si aplica (solo la clase con los métodos, sin implementación)
NO escribas selectores reales — esos los pongo yo.NO escribas assertions completas — solo indica qué se debe validar.¿Por qué no le pido el test completo? Porque la IA es excelente generando estructura repetitiva, pero mediocre eligiendo selectores, assertions, y flujos específicos de tu aplicación. Si le pides todo, vas a pasar más tiempo corrigiendo que si hubieras empezado tú.
Debuggear un test que falla
Ver el prompt para investigar un test roto
Este test de Playwright estaba pasando y ahora falla.
Código del test:[pego el test]
Error que arroja:[pego el error completo del terminal]
Lo que cambió recientemente:[lo que sepa: deploy nuevo, cambio de datos, actualización de dependencias]
Dame las 3 hipótesis más probables de por qué falla, ordenadas porprobabilidad. Para cada una, dime cómo verificarla.No siempre acierta. Pero me da un punto de partida estructurado en vez de leer logs sin rumbo.
Entender código que escribió otra persona
Ver el prompt para entender código heredado
Explícame este test como si fuera nueva en el proyecto.
[pego el código]
Necesito saber:1. ¿Qué flujo del usuario está validando?2. ¿Qué precondiciones asume?3. ¿Qué está verificando cada assertion?4. ¿Hay algo raro, frágil, o que dependa de datos específicos?Esto funciona sorprendentemente bien. Me ha ahorrado horas de arqueología de código.
4. Un test falla y necesitas investigar
Esto es diferente a debuggear el test en sí. Aquí el test funciona bien — lo que falla es la aplicación.
Ver el prompt para diagnosticar fallos de la aplicación
Soy QA y estoy investigando un fallo en [nombre del módulo/flujo].
Lo que debería pasar:[comportamiento esperado]
Lo que está pasando:[comportamiento actual]
Evidencia:- Error del log: [pego el error]- Paso del test donde falla: [el paso específico]- Último deploy: [qué se desplegó y cuándo]
No necesito que me des la solución (eso es trabajo del dev).Necesito que me ayudes a aislar el problema:- ¿Es un error de datos, de integración, de lógica, o de infraestructura?- ¿Qué verificarías primero para descartarlo?- ¿Qué información adicional le pedirías al equipo de desarrollo?«No me des la solución» cambia completamente el tipo de respuesta. Le estás diciendo que tu objetivo es diagnosticar, no resolver. La IA funciona aquí como un rubber duck con conocimiento técnico.
Tip: Entre más específico el contexto, mejor la respuesta. «El test falla» no sirve. «El test de transferencia falla en el paso de confirmación, devuelve 500, el servicio de notificaciones se desplegó ayer con cambios en el endpoint de email» — eso sí sirve.
5. Tienes que reportar resultados
El sprint terminó. Ejecutaste las pruebas. Ahora toca el reporte.
Esta es probablemente la tarea donde más tiempo me ahorra la IA, porque es la más mecánica.
Ver el prompt para generar reportes de ejecución
Te paso los resultados de la ejecución de pruebas del sprint [número]:
Total: [X] testsPasaron: [X]Fallaron: [X]Skipped: [X]
Tests que fallaron:[lista con nombre del test y el error]
Necesito:1. Un resumen ejecutivo de 3-4 líneas para stakeholders no técnicos2. Los fallos agrupados por severidad (bloqueante, alto, medio, bajo)3. Patrón: ¿hay algo en común entre los fallos? (mismo módulo, mismo tipo de error, mismo servicio)4. Recomendación: ¿qué debería investigar el equipo primero en el próximo sprint?
Formato: listo para pegar en [Jira / Notion / Confluence / el que uses]Lo que antes me tomaba 30-40 minutos, ahora son menos de 10. Y el reporte es más consistente porque sigue siempre la misma estructura.
6. El anti-patrón: cuando la IA te hace más lenta
Esto nadie lo dice. Pero es tan importante como los 5 puntos anteriores.
- Cuando ya sabes la respuesta. Formular el prompt, esperar, leer, y corregir puede tomar más que hacerlo directamente. - Cuando necesitas criterio de negocio. La IA no conoce a tus usuarios ni sabe que la regulación cambió el mes pasado. - Cuando estás pensando en la estrategia. Decidir qué automatizar y qué no requiere juicio profesional.
Mi regla: Si el problema requiere contexto que tendría que explicarle a la IA en más de 2 minutos, probablemente sea más rápido resolverlo yo. Si el problema requiere volumen (muchos escenarios, mucho formato, mucha estructura), ahí sí abro la IA.
Por dónde empezar si nunca usaste IA como QA
Semana 1: La próxima historia de usuario que te asignen, pásala por la IA y pídele que te liste las ambigüedades. Solo eso. Fíjate cuántas preguntas no se te habían ocurrido.
Semana 2: Cuando tengas tus test cases escritos (por ti, a mano), pásalos con los criterios de aceptación y pídele: «¿Qué me falta?» Usa la IA como reviewer, no como escritora.
Semana 3: Prueba generar la estructura base de un test automatizado. No el test completo — la estructura. Tú llenas la lógica.
Semana 4: La próxima vez que tengas que hacer un reporte, pásale los datos crudos y pídele que te arme el borrador.
En un mes, vas a tener muy claro dónde te sirve y dónde no.
Lo que quiero que te lleves
La IA no es magia. No te convierte en mejor QA automáticamente. Lo que hace es quitarte de encima el trabajo mecánico para que puedas dedicarle más tiempo a lo que realmente importa: pensar, cuestionar, y encontrar lo que nadie más vio.
Pero necesitas saber de testing primero. La IA multiplica lo que ya sabes. Si sabes poco, multiplica poco. Si sabes mucho, es imparable.
No te dije qué herramienta usar. A propósito. Las herramientas cambian cada seis meses. La forma de pensar no.
Lo que viene
Todo lo que viste en esta guía es IA «básica»: tú le preguntas, ella responde. Un prompt a la vez.
Pero hay un siguiente nivel: agentes, subagentes y skills.
Imagina que en vez de abrir la IA y escribir un prompt, le dices «analiza esta historia, genera los tests, ejecútalos, y dame el reporte» — y lo hace todo. Sin que copies y pegues nada. Sin que cambies de herramienta.
Eso ya existe. Y lo estoy usando.