Módulo 1 · Fundamentos de testing

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

Contenido en preparación

La parte teórica de este módulo la desarrolla el instructor. Aquí están los objetivos, el entregable y los ejercicios base con los datos del laboratorio.

Objetivos

• Explicar qué son las pruebas de software y para qué sirven.
• Distinguir tipos y niveles de prueba.
• Analizar una historia de usuario e identificar dudas, riesgos y criterios de aceptación.
• Priorizar riesgos.
• Diseñar casos positivos, negativos y de frontera.
• Registrar evidencias y reportar resultados.

Contenidos teóricos

Tema	Tiempo
Conceptos y objetivos de las pruebas de software	20 min
Tipos y niveles de pruebas	25 min
Análisis de historias de usuario y criterios de aceptación	25 min
Identificación y priorización de riesgos	20 min
Estructura y diseño de casos de prueba	20 min
Evidencias y reporte de resultados	10 min

Entregable

Una matriz que contenga:

1. Los riesgos identificados, priorizados.
2. Los criterios de aceptación de la historia.
3. Los casos de prueba (positivos, negativos y de frontera).
4. Las evidencias de la ejecución.

---

Ejercicio 1 · Analizar una historia de usuario (35 min)

Esta es la historia tal como llegó del equipo de producto. Está incompleta a propósito: parte del ejercicio es darse cuenta de qué falta.

HU-014 · Cancelar una cita

Como cliente de ReservaLab quiero cancelar una cita que ya reservé para no ocupar un horario al que no voy a asistir.

Criterios de aceptación

• El cliente puede cancelar sus citas desde el listado.
• Una cita cancelada ya no ocupa el horario.
• No se puede cancelar con muy poca anticipación.

Trabaja en grupos y produce tres listas:

a) Dudas para el equipo de producto. Todo lo que la historia no dice y hace falta para poder probarla. Por ejemplo: "¿cuánta anticipación es «muy poca»?", "¿puede cancelar una cita ya pasada?", "¿puede cancelar la cita de otro cliente?", "¿qué pasa si la cita ya estaba cancelada?".

b) Riesgos, priorizados. Para cada riesgo, estima impacto y probabilidad:

Riesgo	Impacto	Probabilidad	Prioridad
Un cliente cancela la cita de otro
Se puede cancelar sin restricción de tiempo
La interfaz dice que canceló pero no cancela
(añade los que se te ocurran)

c) Criterios de aceptación reescritos, ahora sí verificables. Un criterio verificable dice exactamente qué comprobar y cuál es el resultado esperado.

Los datos reales del laboratorio

Las reglas que la aplicación implementa de verdad son: cancelación con al menos 2 horas de anticipación, máximo 4 citas activas por cliente, no se puede reservar en el pasado y dos citas del mismo servicio no pueden solaparse.

No las mires antes de hacer el ejercicio: la idea es que las dudas salgan de ti.

Ejercicio 2 · Diseñar casos de prueba (50 min)

A partir de tus criterios reescritos, diseña casos en tres categorías:

• Positivos: el camino que debe funcionar.
• Negativos: lo que debe ser rechazado, con el mensaje adecuado.
• De frontera: justo en el límite. Aquí se esconden la mayoría de defectos.

Ejemplos de frontera para la regla de las 2 horas: una cita a 2 h 1 min (debe permitir), a exactamente 2 h (¿permite o no? — esto es una duda para producto), a 1 h 59 min (debe rechazar).

Usa esta estructura:

ID	Título	Precondición	Pasos	Resultado esperado	Tipo
CP-01					Positivo

Ejercicio 3 · Ejecutar y evidenciar (25 min)

Ejecuta tus casos en web.theproject.ec y registra:

• Resultado real de cada caso.
• Estado: Pasó / Falló / Bloqueado.
• Evidencia: captura de pantalla con la hora visible, y el dato consultado en la base de datos si aplica.

Verifica por dos vías

Que la interfaz muestre "cancelado" no significa que se haya cancelado. Confirma en db.theproject.ec o con GET /appointments cuál es el estado real. Este hábito te va a ahorrar disgustos toda tu carrera.

Ejercicio 4 · Socialización (10 min)

Cada grupo presenta:

• El riesgo que consideró más grave y por qué.
• Un caso de frontera que encontró y los demás no.
• Un defecto, si dieron con alguno.