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.
Cuando el requerimiento viene razonablemente ordenado, la IA sí puede ayudar en cuatro cosas útiles:
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.
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:
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.
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:
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.
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:
Ese paso evita una falsa sensación de avance.
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.
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:
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:
Una vez generados los casos, el revisor QA debería responder tres preguntas:
Esa revisión es la diferencia entre “usar IA” y “operar con criterio”.
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.
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
|
ID |
Criterio |
Objetivo |
Resultado esperado |
Prioridad |
Tipo |
|
TC-01 |
CA-01 |
Ingresar correo con formato válido |
El sistema acepta el dato y envía confirmación |
Alta |
Funcional/API |
|
TC-02 |
CA-01 |
Ingresar correo con formato inválido |
El sistema rechaza el dato y muestra validación |
Alta |
Funcional |
|
TC-03 |
CA-02 |
Intentar usar un correo ya registrado |
El sistema bloquea el cambio sin alterar el correo actual |
Alta |
Integración |
|
TC-04 |
CA-03 |
Confirmar cambio desde enlace vigente |
El nuevo correo queda activo |
Alta |
E2E acotada |
|
TC-05 |
CA-04 |
Revisar estado antes de confirmar |
El correo anterior sigue vigente |
Alta |
Integración |
|
TC-06 |
CA-05 |
Usar enlace expirado |
El sistema rechaza el enlace y ofrece reenvío |
Media |
Integración |
|
TC-07 |
CA-06 |
Verificar trazabilidad del evento |
El cambio queda registrado con fecha, usuario y estado |
Alta |
Integración |
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.
“Dame 30 casos” es una mala instrucción. Obliga a inflar.
Si el requerimiento viene débil, la IA solo produce una debilidad mejor presentada.
Un criterio no es un caso. Un criterio puede requerir varios casos.
No todo caso amerita automatización. El costo de mantenimiento importa.
“Debe funcionar correctamente” no es un resultado esperado. Es una evasiva.
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.
Antes de aprobar casos generados con IA, revisa esto:
Si fallas en varias de estas preguntas, todavía no tienes un entregable. Tienes un borrador.
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.
QA vs Testing: diferencias, roles y quién es dueño de la calidad