Módulo 3 · IA aplicada a QA

4 horas — 1 h 30 de teoría, 2 h 30 de práctica.

Contenido en preparación

La parte teórica la desarrolla el instructor. Aquí están los objetivos, el entregable y los ejercicios base, que se apoyan en el trabajo de los módulos 1 y 2.

Objetivos

• Entender qué es un modelo de lenguaje y, sobre todo, qué no es.
• Escribir prompts efectivos para tareas de QA.
• Identificar en qué partes del ciclo de pruebas la IA aporta y en cuáles estorba.
• Reconocer riesgos: privacidad, alucinaciones, sesgo hacia el camino feliz.
• Validar y corregir lo que produce la IA.

Contenidos teóricos

Tema	Tiempo
Conceptos básicos de IA generativa y modelos de lenguaje	20 min
Estructura de un prompt efectivo	25 min
Casos de uso de IA dentro del ciclo de pruebas	25 min
Herramientas disponibles para QA	10 min
Riesgos, privacidad y validación de respuestas	10 min

Entregable

Una biblioteca de prompts de QA con: casos de prueba generados, datos de prueba, consultas SQL y un borrador de automatización — todo revisado y corregido por ti, con los errores del modelo señalados.

---

Las dos reglas que no se negocian

Privacidad

No pegues en una herramienta de IA pública: credenciales, datos de clientes reales, código propietario del cliente ni información bajo acuerdo de confidencialidad. En este bootcamp usamos datos de laboratorio, así que puedes trabajar tranquilo — pero el hábito se construye ahora.

Validación

Un modelo de lenguaje genera texto plausible, no texto verdadero. En QA eso se traduce en un sesgo muy concreto: produce muchos casos del camino feliz y pocos casos de frontera, e inventa endpoints, columnas y funciones que no existen. Todo lo que salga de la IA se verifica contra el sistema real antes de usarlo.

Anatomía de un prompt útil

Un prompt flojo: "dame casos de prueba para reservar una cita".

Un prompt útil lleva cinco cosas:

Parte	Ejemplo
Rol y objetivo	"Actúa como analista de QA. Necesito casos de prueba."
Contexto real	"La API es POST /appointments, recibe service_id y fecha ISO 8601."
Reglas concretas	"Reglas: no reservar en el pasado; máximo 4 citas activas; no solapar el mismo servicio; cancelar con ≥2 h."
Formato de salida	"Devuélvelo en tabla: ID, título, precondición, pasos, resultado esperado, tipo."
Restricción explícita	"Incluye al menos 4 casos de frontera y 3 negativos. No inventes campos que no te he dado."

---

Ejercicio 1 · Mejorar una historia de usuario (30 min)

Toma la historia HU-014 del módulo 1 tal como estaba (incompleta) y pide a la IA que la mejore: criterios verificables, dudas para producto y riesgos.

Después compara con lo que tú produjiste en el módulo 1:

1. ¿Qué encontró la IA que tú no?
2. ¿Qué encontraste tú que la IA no?
3. ¿Inventó algún criterio que no se sostiene con el sistema real?

Ejercicio 2 · Generar casos positivos, negativos y de frontera (40 min)

Escribe un prompt con las cinco partes de la tabla de arriba y pide casos para POST /appointments.

Después verifica cada caso generado contra la API real (Bruno o curl) y marca cada uno como:

Estado	Significado
✅ Válido	El caso tiene sentido y el sistema se comporta como dice
⚠️ Impreciso	La idea sirve pero los detalles están mal
❌ Inventado	Habla de campos, endpoints o comportamientos que no existen

Cuenta cuántos hay de cada tipo. Ese porcentaje es tu medida de cuánto puedes confiar en el modelo para esta tarea.

Ejercicio 3 · Datos de prueba y consultas SQL (25 min)

3.1 Pide a la IA datos de prueba para el registro de usuarios: emails válidos, inválidos y casos límite. Pruébalos contra POST /auth/register.

Presta atención especial a los que la IA dice que son inválidos: ¿el sistema los rechaza de verdad?

3.2 Dale el esquema real de la base de datos y pide una consulta que responda: "¿cuántas citas confirmadas hay por servicio, incluyendo los servicios dados de baja?"

users        (id, email, password_hash, nombre, rol, created_at)
services     (id, nombre, descripcion, duracion_min, precio, activo, created_at)
appointments (id, user_id, service_id, fecha, estado, notas, created_at, cancelled_at)

Ejecútala en db.theproject.ec. Si falla, corrígela y anota qué se equivocó el modelo.

Ejercicio 4 · Borrador de automatización (30 min)

Pide a la IA una prueba de Playwright para el flujo de cancelación. Dale el contexto real: los data-testid del inventario y la URL de la aplicación.

Luego ejecútala. Anota:

1. ¿Compila?
2. ¿Usa los data-testid que le diste o inventó selectores?
3. ¿Espera correctamente o mete sleep fijos?
4. ¿Limpia lo que crea?

Ejercicio 5 · Revisar y corregir (25 min)

Este es el ejercicio más importante del módulo.

Toma todo lo que generaste y produce la versión corregida y funcional. Para cada corrección, anota en una tabla:

Qué generó la IA	Qué estaba mal	Cómo lo corregí

Cierra con una reflexión de media página: ¿en qué tareas de QA te ahorró tiempo de verdad y en cuáles te hizo perderlo?