IA para generar casos de prueba desde requisitos: plantilla y workflow

Por Ignacio Muñoz, Project Manager

La mejor forma de usar IA en testing no es delegarle la calidad. Es usarla para acelerar una parte concreta del trabajo: convertir requisitos, historias de usuario y criterios de aceptación en un primer borrador de casos de prueba que el equipo luego revisa con criterio. Según IBM, las pruebas de software existen para verificar que una aplicación funcione correctamente, de forma segura y eficiente, de acuerdo con sus requisitos. Y, de acuerdo con Atlassian, los criterios de aceptación deben ser claros, concisos y testeables. Si esa base no existe, la IA no la compensa: solo acelera una ambigüedad que ya venía de antes.

Escribí este blog porque este punto importa más de lo que parece. Muchas iniciativas de IA en QA fallan no porque el modelo sea malo, sino porque el insumo llega incompleto: historias vagas, reglas de negocio implícitas, validaciones dispersas o ningún criterio real para decidir cobertura. En la guía de QA con IA, ACL lo baja bien: el valor no está en “automatizar por automatizar”, sino en mejorar cómo el equipo analiza requerimientos, detecta errores antes y decide qué probar con más foco.

Qué sí resuelve la IA en esta etapa

Cuando el requerimiento viene razonablemente ordenado, la IA sí puede ayudar en cuatro cosas útiles:

• Proponer casos positivos, negativos y de borde
• Detectar vacíos obvios en criterios de aceptación
• Estructurar resultados esperados de forma más consistente
• Acelerar la trazabilidad entre requisito, prueba y riesgo
•  

Eso no reemplaza al QA ni al Product Owner. Lo que hace es reducir el tiempo mecánico de redacción inicial para que el equipo se concentre en lo que sigue siendo difícil: cobertura, criticidad, supuestos y decisiones de automatización. Si quieres ampliar ese enfoque, en ACL ya hay una base útil sobre cómo la IA está transformando las pruebas QA de software y sobre herramientas de inteligencia artificial para QA.

Qué necesita la IA para generar casos que sirvan

Una historia de usuario sola casi nunca basta.

“Como cliente quiero actualizar mis datos para mantener mi información al día” alcanza para una conversación inicial. No alcanza para una buena suite de pruebas. Falta saber qué campos cambian, cuáles son obligatorios, qué reglas de validación aplican, qué pasa con perfiles bloqueados, si hay integraciones, si existen datos maestros, si hay trazabilidad regulatoria y qué error es aceptable.

El insumo mínimo razonable debería incluir:

• Requerimiento o historia de usuario
• Criterios de aceptación
• Reglas de negocio
• Validaciones de campos
• Dependencias e integraciones
• Datos de prueba relevantes
• Criticidad o riesgo
• Exclusiones claras
  
  

Este enfoque encaja con cómo ACL aborda el problema en su servicio de QA con IA: partir por análisis de requerimientos, criterios de aceptación, detección temprana de errores y trazabilidad, antes de escalar automatización o sumarle IA al pipeline.

Qué salida conviene pedir

Otro error común es pedirle al modelo “genérame 20 casos de prueba”. Esa instrucción privilegia volumen. No necesariamente cobertura.

La salida útil debería venir, como mínimo, con esta estructura:

• ID del caso
• Criterio de aceptación asociado
• Objetivo
• Precondiciones
• Datos de prueba
• Pasos
• Resultado esperado
• Prioridad
• Tipo de prueba sugerido
• Candidato a automatización
• Observaciones o supuestos
  
  

Eso obliga a que cada caso tenga una razón de existir. También facilita la revisión en herramientas de gestión como Jira, Xray o Zephyr, aunque la estructura concreta dependerá del stack y del flujo de trabajo del equipo.

Flujo de trabajo recomendado

1. Limpia el requisito antes de generar nada

Antes de pedir casos de prueba, pídele a la IA que marque ambigüedades. No es un detalle menor. En muchos equipos, el mejor primer uso no es “redacta casos”, sino “dime qué falta para poder probar esto bien”.

Pídele que identifique:

• Criterios ausentes
• Contradicciones
• Reglas implícitas
• Escenarios negativos no cubiertos
• Dependencias externas no declaradas

Ese paso evita una falsa sensación de avance.

2. Genera casos por criterio de aceptación, no por historia completa

Si el modelo trabaja criterio por criterio, la trazabilidad mejora de inmediato. También se reduce el ruido. En vez de una lista larga y repetitiva, obtienes casos asociados a condiciones concretas de cumplimiento.

3. Obliga a separar escenarios positivos, negativos y de borde

Este punto suele marcar la diferencia entre una salida decorativa y una salida útil. En la práctica, muchos borradores generados por IA cubren bien el happy path, pero fallan en:

• Límites de longitud
• Combinaciones inválidas
• Sesiones vencidas
• Errores de integración
• Restricciones por rol
• Reintentos
• Estados inconsistentes

4. Revisa el tipo de prueba correcto

No todo lo que genera la IA debe terminar como prueba end-to-end. Según Martin Fowler, la pirámide de testing sigue siendo una forma útil de distribuir pruebas por costo, velocidad y mantenibilidad. En términos simples: conviene resolver la mayor cantidad posible de validaciones con pruebas rápidas y estables, y reservar E2E para flujos realmente críticos. ACL aterriza esa misma idea en su artículo sobre tipos de testing en software y en su nota sobre pirámide de pruebas y cobertura basada en riesgo.

Una regla simple:

• Lógica aislada → unitarias
• Interacción entre componentes → integración
• Journeys críticos → E2E acotadas
• Cambios sensibles → regresión focalizada
• Validación rápida de build → smoke

5. Revisa supuestos, duplicados y automatización

Una vez generados los casos, el revisor QA debería responder tres preguntas:

• ¿Cubre un riesgo real o solo repite otro caso?
• ¿El resultado esperado es verificable?
• ¿Vale la pena automatizarlo?

Esa revisión es la diferencia entre “usar IA” y “operar con criterio”.

Plantilla lista para usar

Puedes partir con una instrucción como esta:

Actúa como QA senior.
Revisa el siguiente requerimiento y sus criterios de aceptación.
Antes de generar casos de prueba, identifica ambigüedades, reglas faltantes o contradicciones.
Luego genera casos positivos, negativos y de borde.
Para cada caso incluye: ID, criterio asociado, objetivo, precondiciones, datos, pasos, resultado esperado, prioridad, tipo de prueba sugerido y si es candidato a automatización.
No inventes reglas de negocio. Si asumes algo, decláralo como supuesto.

La plantilla no hace magia. Lo que hace es obligar al modelo a trabajar con una estructura que luego sí puedes revisar.

Ejemplo práctico

Supongamos este requerimiento:

Historia de usuario
Como cliente autenticado, quiero actualizar mi correo electrónico desde mi perfil para recibir notificaciones en la dirección correcta.

Criterios de aceptación

1. El nuevo correo debe tener formato válido.
2. No puede estar ya asociado a otra cuenta.
3. El cambio debe confirmarse con un enlace enviado al nuevo correo.
4. Hasta que la confirmación ocurra, el correo anterior sigue siendo el vigente.
5. Si el enlace expira, el usuario debe poder solicitar uno nuevo.
6. El evento debe quedar trazado para auditoría.

Casos de prueba que sí valdría la pena generar

El punto no es que la IA escriba esta tabla “bonita”. El punto es que ayude a construir un borrador que después el equipo pueda discutir en serio: qué se automatiza, qué se deja manual, qué cubre negocio, qué cubre integración y qué todavía está mal especificado.

Errores comunes

1- Pedir cantidad en vez de cobertura

“Dame 30 casos” es una mala instrucción. Obliga a inflar.

2- Generar sin revisar ambigüedades

Si el requerimiento viene débil, la IA solo produce una debilidad mejor presentada.

3- No diferenciar entre criterio y caso

Un criterio no es un caso. Un criterio puede requerir varios casos.

4- Automatizar todo lo generado

No todo caso amerita automatización. El costo de mantenimiento importa.

5- Aceptar resultados esperados vagos

“Debe funcionar correctamente” no es un resultado esperado. Es una evasiva.

6- Ignorar riesgos de datos o gobierno

Si usas IA con información sensible, necesitas controles. El marco de NIST insiste en algo que acá aplica perfecto: la gestión de riesgo debe incorporarse al diseño, desarrollo, uso y evaluación de sistemas de IA. En QA, eso toca directamente el manejo de datos de prueba, la explicabilidad de las decisiones asistidas y la revisión humana. ACL ya lo conecta con mayor detalle en su artículo sobre protección de datos e IA.

Checklist rápido para revisar la salida

Antes de aprobar casos generados con IA, revisa esto:

• ¿Cada caso responde a un criterio o regla real?
• ¿Hay escenarios positivos, negativos y de borde?
• ¿Los resultados esperados son observables?
• ¿Los supuestos quedaron explícitos?
• ¿Hay duplicados?
• ¿Está bien asignado el tipo de prueba?
• ¿La prioridad refleja riesgo de negocio?
• ¿Se identificaron candidatos razonables a automatización?
• ¿La salida serviría para ejecución real o solo para “verse completa”?

Si fallas en varias de estas preguntas, todavía no tienes un entregable. Tienes un borrador.

Entonces, ¿vale la pena?

Sí, si el objetivo está bien acotado.

Usar IA para generar casos de prueba a partir de requisitos sí puede ahorrar tiempo y mejorar consistencia. Pero funciona bien solo cuando el equipo ya tiene una base mínima: criterios claros, revisión humana, foco en riesgo y una forma de cerrar el ciclo entre requisito, prueba y resultado. Si ese orden todavía no existe, conviene resolverlo primero. En ACL hay buen material para seguir esa conversación desde varios ángulos: QA vs testing, qué hace un QA, STLC/SDLC aplicado: dónde entra QA con IA y, sobre todo, la guía de QA con IA.

Si tu equipo ya está evaluando cómo usar IA para mejorar análisis de requerimientos, generación de casos, trazabilidad y regresión sin sumar ruido operativo, el siguiente paso razonable no es comprar otra herramienta. Es revisar si el proceso está listo para sostenerlo. Ahí es donde toma sentido conversar con ACL sobre su enfoque de QA con IA. 

¿Te ha interesado este contenido? No te pierdas nuestros otros artículos

• STLC/SDLC aplicado: dónde entra QA con IA

• QA vs Testing: diferencias, roles y quién es dueño de la calidad 

• QA con IA: guía práctica para implementar testing inteligente
• Diferencias entre Bug, Issue y No Conformidad | Guía Completa de QA
• QA y QC: Diferencias y beneficios en la calidad del software
• ¿Qué es QA? Descubre la Importancia del Quality Assurance