IA para QA: cómo generar casos de prueba sin perder criterio de testing

La IA puede proponerte casos de prueba; decidir qué falta sigue siendo trabajo de QA

Un equipo recibe el requisito de una nueva funcionalidad: permitir que un cliente cambie su contraseña desde la aplicación. La IA genera rápidamente una lista de escenarios: contraseña válida, contraseña incorrecta, campos vacíos y confirmación diferente. A primera vista parece suficiente. Sin embargo, todavía quedan preguntas importantes: ¿qué ocurre con una sesión activa en otro dispositivo?, ¿se invalida el token anterior?, ¿hay un límite de intentos?, ¿qué reglas debe cumplir la nueva contraseña?, ¿qué mensaje se muestra si el correo de recuperación ya no está disponible?

Este ejemplo muestra el valor y el límite de la inteligencia artificial aplicada al diseño de pruebas. Puede ayudar a ampliar las opciones y acelerar una primera exploración, pero no conoce automáticamente todos los riesgos del producto ni puede decidir, sin contexto, qué comportamiento es correcto.

La responsabilidad del QA sigue siendo revisar los supuestos, detectar omisiones, priorizar riesgos y convertir las ideas útiles en casos verificables. En este artículo veremos un flujo práctico para usar IA como asistente en el diseño de pruebas, sin delegar el criterio de testing.

Qué puede aportar la IA al diseño de casos de prueba

Un modelo de IA puede analizar requisitos, reglas de negocio y contexto funcional para sugerir escenarios candidatos. También puede ayudar a reformular criterios ambiguos, proponer datos de prueba o explorar variaciones que el equipo todavía no había considerado.

Su aporte es especialmente útil en una etapa temprana, cuando se necesita construir un mapa inicial de posibilidades. Por ejemplo, ante una funcionalidad de compra en una aplicación B2C, la IA podría proponer escenarios relacionados con:

• Compra con datos válidos.
• Producto sin stock.
• Carrito vacío.
• Dirección de entrega incompleta.
• Pago rechazado.
• Cupones vencidos o no aplicables.
• Interrupción durante el proceso de pago.
• Reintento después de un error.

La lista puede servir como punto de partida, pero no es todavía una suite de pruebas. Un escenario candidato no define necesariamente las condiciones iniciales, los datos concretos, el resultado esperado ni la prioridad del caso.

La IA tampoco puede inferir siempre si una regla sugerida es válida para el negocio. Puede completar una respuesta con supuestos plausibles, pero incorrectos. Por eso conviene tratar sus resultados como hipótesis para revisar, no como evidencia de cobertura.

El flujo recomendado: de los requisitos a los casos verificables

1. Entregar contexto suficiente, no solo una frase

La calidad de las sugerencias depende en gran medida de la información proporcionada. Un pedido como “genera casos de prueba para el checkout” es demasiado abierto. La IA tendrá que completar muchos vacíos por su cuenta.

Un contexto más útil puede incluir:

• Objetivo de la funcionalidad.
• Tipo de usuario involucrado.
• Reglas de negocio conocidas.
• Precondiciones.
• Integraciones, como un proveedor de pagos.
• Estados posibles del proceso.
• Comportamiento esperado ante errores.
• Restricciones conocidas de seguridad, disponibilidad o experiencia de usuario.

Por ejemplo, en lugar de solicitar casos para “cambiar la contraseña”, el equipo puede indicar que el usuario debe estar autenticado, que la contraseña debe cumplir ciertas reglas, que se requiere la contraseña actual y que todas las sesiones activas deben cerrarse después del cambio. Si alguna regla todavía no está definida, también es importante marcarla como una pregunta abierta.

2. Pedir escenarios candidatos por categorías

Una lista plana suele ocultar vacíos. Es preferible solicitar escenarios agrupados por tipos de condición. Esto ayuda a revisar el alcance con una lógica más sistemática.

Las categorías pueden incluir:

• Camino feliz: uso correcto con datos válidos.
• Validaciones: campos obligatorios, formatos y límites.
• Valores límite: cantidades mínimas, máximas, longitudes y fechas.
• Reglas de negocio: permisos, estados y restricciones.
• Errores externos: respuestas fallidas o lentas de otros servicios.
• Seguridad: acceso no autorizado, exposición de información y abuso de intentos.
• Compatibilidad y experiencia: comportamiento en distintos dispositivos, navegadores o condiciones de conectividad.

La categorización no garantiza cobertura, pero hace más visibles las áreas que todavía no fueron discutidas.

3. Revisar los supuestos antes de aceptar las sugerencias

Este es uno de los pasos más importantes. La IA puede presentar como hecho algo que nunca estuvo definido en los requisitos. Por ejemplo:

• Asumir que un usuario puede reintentar un pago indefinidamente.
• Suponer que el sistema redondea los importes de una determinada manera.
• Dar por hecho que una sesión permanece activa después de cambiar credenciales.
• Definir un mensaje de error específico sin que exista una decisión de producto.
• Considerar que una operación fallida no produjo efectos parciales.

Cada supuesto debería convertirse en una pregunta para producto, desarrollo o negocio. Si no se confirma, el caso de prueba no debería registrar una expectativa inventada como si fuera el comportamiento correcto.

4. Buscar límites, excepciones y estados intermedios

Los casos generados suelen cubrir el uso esperado, pero los defectos relevantes aparecen con frecuencia en los bordes del comportamiento. El QA debe preguntar qué sucede justo antes, justo después y durante una transición.

Para una funcionalidad de cupones, por ejemplo, no alcanza con probar un cupón válido y uno inválido. También conviene analizar:

• Cupón aplicado al límite de vigencia.
• Cupón con uso máximo alcanzado.
• Cupón válido para otro producto o segmento de clientes.
• Dos descuentos que no pueden combinarse.
• Eliminación del producto que habilitaba el descuento.
• Actualización del carrito después de aplicar el cupón.
• Reintento de pago con el descuento ya utilizado.

La pregunta no es únicamente “¿qué datos inválidos puedo ingresar?”. También es “¿qué estados puede atravesar el sistema y qué ocurre si cambia una condición durante el proceso?”.

5. Priorizar según el riesgo

No todos los escenarios merecen el mismo nivel de detalle ni deben ejecutarse con la misma frecuencia. La IA puede ayudar a ordenar una lista, pero la prioridad debe relacionarse con el impacto real del producto.

Algunos factores útiles para priorizar son:

• Impacto económico de una falla.
• Exposición de datos personales o financieros.
• Cantidad de usuarios afectados.
• Frecuencia de uso de la funcionalidad.
• Complejidad técnica o cantidad de integraciones.
• Probabilidad de cambio reciente.
• Dificultad para detectar el problema después de desplegarlo.

Un error que permite confirmar dos veces una orden puede ser más urgente que una diferencia menor en un mensaje visual, aunque ambos aparezcan en la lista generada por la IA. La prioridad debe reflejar el riesgo del negocio y del sistema, no el orden en que fueron propuestas las ideas.

6. Convertir solo lo útil en casos verificables

Después de revisar y priorizar, cada caso seleccionado debería poder ser ejecutado y evaluado por otra persona. Como mínimo, conviene definir:

• Identificador o nombre claro.
• Precondiciones.
• Datos de prueba.
• Pasos reproducibles.
• Resultado esperado observable.
• Prioridad o nivel de riesgo.

“Verificar que el pago funcione correctamente” no es un caso suficientemente preciso. Un caso más útil podría indicar que, con un carrito válido y un medio de pago autorizado, al confirmar la compra debe crearse una única orden, mostrarse una confirmación y evitarse un segundo cobro si el usuario reintenta después de una respuesta tardía.

El resultado esperado debe describir un comportamiento observable. Frases como “el sistema responde bien” o “la operación se procesa correctamente” no permiten determinar con claridad si la prueba pasó o falló.

Ejemplo práctico: revisar casos para un cambio de contraseña

Supongamos que el requisito funcional indica:

“Un usuario autenticado puede cambiar su contraseña ingresando la contraseña actual y una nueva contraseña que cumpla las reglas de seguridad. Después del cambio, las sesiones activas deben invalidarse.”

Una primera solicitud a la IA podría generar estos escenarios:

• Cambio exitoso con datos válidos.
• Contraseña actual incorrecta.
• Nueva contraseña vacía.
• Confirmación de contraseña diferente.
• Nueva contraseña que no cumple las reglas.
• Usuario no autenticado.

Estos escenarios son útiles, pero la revisión de QA puede ampliar y precisar el análisis.

Preguntas que la IA no debería responder por cuenta propia

• ¿Cuántos intentos fallidos se permiten antes de bloquear temporalmente la operación?
• ¿El bloqueo afecta al usuario completo o solo al cambio de contraseña?
• ¿Qué ocurre con una sesión activa en otro navegador?
• ¿La sesión desde la que se realiza el cambio también se invalida?
• ¿Se envía una notificación por correo o por otro canal?
• ¿Se puede reutilizar una contraseña anterior?
• ¿Qué mensaje debe mostrarse sin revelar información sensible?

Algunas respuestas podrían estar en documentación, otras en la implementación y otras requerir una decisión de producto. Hasta confirmarlas, no deberían transformarse en expectativas definitivas.

Casos que pueden faltar

• La contraseña actual es correcta, pero la nueva coincide con una contraseña utilizada anteriormente.
• El usuario cambia la contraseña mientras otra sesión intenta realizar una operación protegida.
• La solicitud se reenvía debido a un doble clic o a un reintento de red.
• El servicio de notificaciones falla después de completar el cambio.
• La respuesta del servidor llega tarde y el usuario vuelve a enviar el formulario.
• La nueva contraseña contiene espacios al inicio o al final.
• La contraseña cumple la longitud, pero utiliza caracteres que la implementación no procesa correctamente.

No todos estos casos serán necesariamente obligatorios. Su valor depende de las reglas confirmadas, del diseño de la aplicación y del riesgo asociado. Ese juicio es precisamente parte del trabajo de QA.

Errores frecuentes al aceptar casos generados sin revisión

Confundir cantidad de casos con cobertura

Una IA puede producir decenas de casos y aun así ignorar una regla crítica. La cobertura no se mide por el número de elementos de una lista, sino por la relación entre requisitos, riesgos, estados y comportamientos verificados.

Para revisar cobertura, puede ser útil relacionar cada requisito con al menos un caso positivo, uno o más casos negativos y los límites relevantes. Si un requisito no tiene una prueba asociada, existe una omisión visible. Si muchos casos repiten la misma condición, puede existir redundancia en lugar de cobertura adicional.

Aceptar resultados esperados ambiguos

Un caso puede tener pasos detallados, pero seguir siendo difícil de evaluar si el resultado esperado no es observable. “Se muestra un error adecuado” no define qué mensaje, estado, código de respuesta o efecto en los datos se espera.

En una API, por ejemplo, puede ser necesario verificar el código HTTP, la estructura de la respuesta y que la operación no haya modificado información cuando la solicitud fue rechazada. En una interfaz, además del mensaje, puede ser relevante confirmar que el formulario conserva los datos permitidos y que el usuario puede corregir el problema.

Ignorar efectos secundarios

Una prueba puede validar que una pantalla muestra “operación exitosa” y pasar por alto que se creó un registro duplicado, se emitió dos veces un evento o se cobró dos veces una orden.

Cuando una funcionalidad interactúa con bases de datos, servicios externos, colas o notificaciones, el caso debería considerar los efectos secundarios relevantes. No es necesario convertir cada prueba manual en una investigación de arquitectura, pero sí verificar que el resultado visible sea consistente con el estado real del sistema.

Convertir supuestos en requisitos

Las respuestas de la IA suelen sonar seguras incluso cuando falta información. Si el equipo copia esos resultados directamente a su herramienta de gestión, una interpretación provisional puede terminar tratándose como una regla oficial.

Una práctica simple es separar los elementos en tres grupos:

• Confirmado: está respaldado por un requisito o una decisión del equipo.
• Candidato: parece relevante, pero todavía requiere revisión.
• Pregunta abierta: falta definir el comportamiento esperado.

Cómo pedir mejores resultados sin delegar el criterio

Un pedido útil a la IA debería indicar su rol y sus límites. Por ejemplo:

Analiza el siguiente requisito y propón escenarios candidatos de prueba agrupados en:
camino feliz, validaciones, límites, reglas de negocio, errores externos y seguridad.

No inventes reglas que no estén presentes. Marca como preguntas abiertas
los comportamientos que no puedan deducirse del requisito.

Para cada escenario indica:
- condición inicial
- acción
- resultado que debería confirmarse
- supuesto involucrado, si existe
- riesgo potencial

Este tipo de instrucción no reemplaza la revisión, pero ayuda a obtener una respuesta más fácil de auditar. También conviene pedir que la IA señale contradicciones o información faltante, en lugar de forzarla a completar todos los espacios.

Después de recibir la respuesta, el QA puede utilizar preguntas de control:

• ¿Qué requisito cubre este caso?
• ¿Qué riesgo se está verificando?
• ¿Cuál es el comportamiento esperado exacto?
• ¿Qué supuesto utiliza esta propuesta?
• ¿Qué ocurre en el límite o durante una transición?
• ¿Qué efecto secundario podría producirse?
• ¿Este caso agrega cobertura o repite otro?

Cuándo conviene usar IA y cuándo tener cautela

La IA puede ser especialmente útil para:

• Explorar una funcionalidad nueva antes de una sesión de refinamiento.
• Generar variaciones de datos de prueba.
• Detectar categorías que no se consideraron inicialmente.
• Revisar la claridad de pasos y resultados esperados.
• Transformar reglas confirmadas en una primera lista estructurada.
• Comparar escenarios entre una versión anterior y una nueva de una funcionalidad.

Se requiere más cautela cuando el contexto es incompleto, el comportamiento depende de decisiones de negocio no documentadas o la prueba involucra información sensible. También es importante revisar las políticas de la organización antes de compartir requisitos, datos de clientes, credenciales, tokens o información confidencial con una herramienta de IA.

En dominios regulados o con alto impacto, una sugerencia generada no debería considerarse evidencia suficiente de cumplimiento. Puede apoyar el análisis, pero la trazabilidad de los requisitos, la revisión de riesgos y la aprobación de los casos deben mantenerse bajo control del equipo.

La habilidad central sigue siendo formular buenas preguntas

Incorporar IA al testing no consiste en pedir una lista y ejecutarla sin cambios. El valor aparece cuando el QA utiliza la herramienta para ampliar el espacio de exploración y luego aplica conocimiento del producto, pensamiento crítico y técnicas de diseño de pruebas.

Un flujo razonable es:

• Entender el requisito y sus objetivos.
• Proporcionar contexto suficiente a la IA.
• Obtener escenarios candidatos organizados.
• Separar hechos, supuestos y preguntas abiertas.
• Explorar límites, excepciones, estados y efectos secundarios.
• Priorizar según impacto y probabilidad de riesgo.
• Redactar casos con pasos y resultados verificables.
• Revisar la cobertura antes de ejecutar.

La IA puede acelerar la generación de alternativas, pero no conoce por sí sola qué falla sería más costosa para el negocio, qué comportamiento contradice una decisión del producto o qué omisión compromete la confianza del usuario. Esa interpretación continúa siendo una responsabilidad profesional del equipo de QA.

Si estás incorporando IA al trabajo de testing, comienza con una funcionalidad acotada y compara las sugerencias con una revisión manual de riesgos. Usa la IA para ampliar opciones, pero conserva la revisión de riesgos, cobertura y resultados esperados como responsabilidad del QA. Esa combinación permite aprovechar la herramienta sin convertir una lista generada en una falsa sensación de calidad.