Usar ChatGPT para Generar Casos de Prueba: Guía Práctica para QA

"Escribí casos de prueba para un formulario de login" produce una lista genérica que cubre el campo de usuario, el campo de contraseña y el botón de envío. "Formulario de login para una app SaaS con autenticación email+contraseña, Google OAuth y MFA donde las cuentas se bloquean después de 5 intentos fallidos" produce algo que puedes usar. Este artículo cubre la estructura de prompts que hace específica la salida de la IA, cinco categorías donde realmente ayuda, la lista de verificación de lo que consistentemente se equivoca, y un flujo de trabajo de cinco pasos que usa la IA como generador de primer borrador con vos como filtro de calidad.

En qué es bueno ChatGPT para casos de prueba

Antes de los prompts, sé honesto sobre lo que estás obteniendo:

Dónde la IA realmente ayuda

• Generar una lista inicial de escenarios rápidamente: luego tú la refinas
• Encontrar particiones de equivalencia y límites que podrías haber omitido
• Convertir historias de usuario en una tabla de casos de prueba estructurada
• Generar casos de prueba negativos (estos son fáciles de olvidar)
• Crear ideas de datos de prueba (formatos de email válidos/inválidos, números en casos extremos)

Dónde la IA queda corta

• No conoce el comportamiento real de tu aplicación
• No puede probar: solo sugiere qué probar
• Se pierden los casos extremos específicos del negocio para los que no tiene contexto
• Genera aserciones que parecen plausibles pero a veces son incorrectas
• Los prompts genéricos producen salida genérica

La solución para ese último punto: dale contexto. Mucho.

La estructura básica del prompt

Prompt genérico (malo):

"Escribe casos de prueba para un formulario de login."

Obtienes: testing del campo de usuario, testing del campo de contraseña, botón de envío... Nada específico de tu sistema.

Mejor estructura:

Funcionalidad: [describí qué hace la funcionalidad y su propósito]
Reglas: [listá las reglas de negocio reales y las restricciones]
Tipos de usuario: [quién usa esta funcionalidad]
Contexto técnico: [opcional — qué framework, qué tipo de app]
Formato de salida: [cómo querés los resultados]
Pedido: Generá casos de prueba cubriendo el camino feliz, casos negativos y casos extremos.

Ejemplos de prompts que podés usar

1. Historia de usuario a casos de prueba

Convertí esta historia de usuario en casos de prueba cubriendo
el camino feliz, casos negativos y casos extremos.

Historia de usuario:
Como usuario registrado, quiero resetear mi contraseña por email,
para poder recuperar el acceso si la olvido.

Reglas:
- El enlace de reseteo es válido por 1 hora
- Después de usar el enlace, expira de inmediato
- Después de 3 intentos de login consecutivos fallidos, la cuenta se bloquea
- El enlace de reseteo va al email registrado
- La nueva contraseña debe cumplir: 8-64 caracteres, al menos 1 número, al menos 1 mayúscula

Formato: tabla con columnas: ID | Descripción | Pasos | Resultado esperado

• Camino feliz: email válido → recibe enlace → usa enlace → establece contraseña válida
• Enlace vencido: usa el enlace después de 1 hora → error
• Enlace reutilizado: usa el enlace dos veces → error en el segundo uso
• Nueva contraseña inválida: muy corta, sin número, sin mayúscula
• Email no en el sistema: no se envía email, sin error que revele si el email existe

Revisa la salida: ¿coincide con el comportamiento real de tu sistema? Ajusta lo que no coincida.

2. Casos de prueba para endpoint de API

Estoy probando un endpoint de API REST. Generá casos de prueba.

Endpoint: POST /api/users
Propósito: Crear una nueva cuenta de usuario
Reglas:
- email: requerido, formato válido, único en el sistema
- password: requerido, 8-64 caracteres, mín 1 mayúscula, mín 1 número
- role: opcional, valores: 'admin' | 'member' | 'viewer', default 'member'
- name: opcional, máx 100 caracteres

Éxito: Devuelve 201 con objeto usuario (id, email, role, created_at). Sin contraseña en la respuesta.
Error de validación: Devuelve 400 con detalles de error por campo.
Email duplicado: Devuelve 409.

Generá casos de prueba como tabla: Test | Método | Body | Status esperado | Respuesta esperada

Esto te da casos de prueba estructurados que pueden traducirse directamente a tests de API en Playwright.

3. Encontrar casos extremos para un campo específico

Tengo un campo "cantidad" en un carrito de e-commerce:
- Debe ser un número entero
- Mínimo: 1
- Máximo: 99
- La cantidad actual se actualiza en tiempo real

Usando análisis de valores límite y particionamiento de equivalencia,
listá los valores que debería probar y el resultado esperado para cada uno.
Formato: Valor | Partición | Comportamiento esperado

ChatGPT conoce el análisis de valores límite. Este prompt te da una lista estructurada y defendible.

4. Ampliar criterios de aceptación escasos

Nuestros criterios de aceptación para esta funcionalidad son vagos.
Ayudame a identificar escenarios faltantes.

Funcionalidad: Búsqueda de productos
Criterios de aceptación:
- Los usuarios pueden buscar por nombre de producto
- Los resultados se muestran en menos de 2 segundos
- Los resultados más relevantes aparecen primero

¿Qué escenarios faltan en estos criterios de aceptación?
¿Qué debería añadir el equipo de QA antes de que empiece el testing?

Este es un prompt de "¿qué nos falta?". Útil en la planificación del sprint.

5. Generar datos de prueba

Necesito datos de prueba para probar un campo de email.
Generá 15 valores de prueba que cubran:
- Formatos de email válidos (incluir internacionales, subdominios, plus-addressing)
- Formatos inválidos (varias formas en que los emails fallan)
- Casos extremos (muy largo, vacío, solo espacios, intento de SQL injection, emoji)

Formato: Valor | ¿Válido? | Por qué

La IA es muy buena generando conjuntos de datos de prueba variados. Esto ahorra tiempo significativo.

Cómo mejorar la calidad de la salida

Decile lo que ya tenés

Ya tengo el camino feliz y casos negativos básicos.
Estos son mis casos de prueba actuales: [pegalos aquí]

¿Qué me falta? Enfocate en casos extremos y escenarios de seguridad.

Esto previene la duplicación y lo hace enfocarse en las lagunas.

Darle el stack tecnológico

Esta es una app Next.js usando PostgreSQL.
¿Qué casos extremos a nivel de base de datos debería probar
en el formulario de registro de usuario que podrían no ser obvios desde la UI?

El contexto del stack produce salida más específica.

Pedirle que priorice

De esta lista de 30 casos de prueba, ¿cuáles 8 debería priorizar
si solo tengo 2 horas para probar antes de un release?
Considerá: impacto en el usuario, probabilidad de bugs, riesgo de la funcionalidad.

Pedirle código Playwright

Convertí estos casos de prueba a código Playwright TypeScript.
La URL de la página es https://lab.becomeqa.com/login.
Selectores: data-testid="email-input", data-testid="password-input",
data-testid="login-button", data-testid="error-message".

Casos de prueba:
1. Login válido con admin@test.com / ValidPass1
2. Contraseña inválida muestra mensaje de error
3. Email vacío muestra error de campo requerido

La salida necesitará revisión y ajuste, pero es un punto de partida rápido.

Qué siempre revisar en los casos de prueba generados por IA

Verifica el relleno genérico

"Verificar que el botón es clickeable" no es un caso de prueba. Bórralo.

Verifica que los resultados esperados sean específicos

"Se muestra mensaje de error" es débil. "El mensaje de error dice 'El email es requerido'" es testeable.

Verifica la lógica de negocio

La IA no conoce las reglas de tu dominio. Si tu app tiene precios especiales para ciertos tipos de usuarios, no va a generar tests para eso.

Verifica los escenarios de integración

La IA genera tests aislados. "¿Funciona el email de reseteo si el usuario cambia su dirección durante el flujo de reseteo?": la IA probablemente lo omitió.

Verifica los valores límite

La IA a menudo se equivoca levemente en los límites. Si tu máximo es 64 caracteres, verifica que diga 63/64/65, no 63/64.

Un flujo de trabajo práctico

1. Escribe tus propios escenarios primero (5-10 minutos). ¿Cuáles son los flujos de usuario clave?

2. Dale a ChatGPT la funcionalidad + reglas + tus escenarios, pide: "¿Qué me falta? Expande estos en casos de prueba detallados."

3. Revisa la salida: tacha los genéricos, ajusta los resultados esperados para que coincidan con tu aplicación real.

4. Añade casos específicos del dominio que la IA no conocería (las reglas de negocio especiales de tu empresa, bugs conocidos del pasado, escenarios de integración).

5. Usa el resultado como tu lista real de casos de prueba o conviértelo en código de tests Playwright.

Así, la IA es tu generador de primer borrador y tú eres el filtro de calidad, que es exactamente la división correcta del trabajo.

Qué no hacer

No copies y pegues casos de prueba de la IA sin revisión

Parecerán completos pero omitirán las cosas específicas de tu sistema.

No lo uses como reemplazo para entender la funcionalidad

Si no entiendes lo que estás probando, la IA no puede salvarte.

No omitas el contexto

Cuanto más específico sea tu prompt, más específica la salida. "Formulario de login" produce basura. "Formulario de login para una app SaaS con autenticación email+contraseña, Google OAuth y soporte MFA donde las cuentas se bloquean después de 5 intentos fallidos" produce algo útil.