¿Qué Es Use Case Testing?
Use case testing deriva test cases de documentos de use case — descripciones estructuradas de cómo los actores interactúan con un sistema para lograr objetivos. Cada use case contiene un escenario de éxito principal y flujos alternativos, proporcionando escenarios de test naturales.
Anatomía de un Use Case
| Elemento | Descripción | Ejemplo |
|---|---|---|
| Nombre | Título descriptivo breve | “Realizar Pedido” |
| Actor | Quién inicia la interacción | Cliente, Admin |
| Precondición | Qué debe ser verdad antes de empezar | Usuario logueado, carrito no vacío |
| Flujo principal | Happy path paso a paso | 1. Seleccionar envío… 2. Ingresar pago… |
| Flujos alternativos | Desviaciones del flujo principal | 2a. Pago rechazado → mostrar error |
| Postcondición | Qué es verdad después del éxito | Orden creada, email enviado |
Ejemplo: Use Case Realizar Pedido
Actor: Cliente Registrado Precondición: Cliente logueado, carrito con 1+ items
Flujo Principal:
- Sistema muestra resumen del carrito con items y total
- Cliente selecciona método de envío
- Sistema calcula costo de envío y actualiza total
- Cliente ingresa información de pago
- Sistema valida datos de pago
- Cliente confirma el pedido
- Sistema procesa el pago
- Sistema crea el pedido y envía email de confirmación
- Sistema muestra página de confirmación del pedido
Flujos Alternativos:
- 2a. Solo un método de envío → sistema lo auto-selecciona
- 4a. Cliente selecciona método de pago guardado → saltar al paso 6
- 5a. Validación de pago falla → sistema muestra error, volver al paso 4
- 7a. Procesamiento de pago falla → sistema muestra error, sugerir reintentar
- 7b. Timeout de pago → sistema muestra mensaje de timeout, pedido no creado
- 8a. Servicio de email no disponible → pedido creado, email en cola
Derivando Test Cases
Regla: Crear al menos un test case por flujo (principal + cada alternativo).
| TC | Flujo | Descripción |
|---|---|---|
| TC1 | Principal | Happy path, todos los pasos 1-9 exitosos |
| TC2 | 2a | Auto-selección de envío |
| TC3 | 4a | Pago guardado, saltar a confirmar |
| TC4 | 5a | Pago inválido → error → reintentar |
| TC5 | 7a | Pago falla → sugerir reintentar |
| TC6 | 7b | Timeout de pago → pedido no creado |
| TC7 | 8a | Email falla → pedido creado, email en cola |
7 test cases de 1 use case.
Encontrando Cobertura Faltante
Los use cases frecuentemente revelan vacíos de testing. Pregunta:
- ¿Qué si el carrito se vacía entre los pasos 1 y 6?
- ¿Qué si el precio cambia durante el checkout?
- ¿Qué pasa con los permisos del actor?
- ¿Qué sucede después de la postcondición?
Use Case Testing Avanzado
Combinando Flujos
Los escenarios reales frecuentemente combinan múltiples flujos alternativos en secuencia:
| TC | Flujos Combinados | Escenario |
|---|---|---|
| TC8 | 5a → Principal | Pago inválido, reintentar con datos correctos → éxito |
| TC9 | 7a → 4a | Pago falla, usar método guardado → éxito |
| TC10 | 5a → 5a → 7a | Dos intentos inválidos, luego válido pero tarjeta rechazada |
Use Case Testing para APIs
Mapea use cases a secuencias de API calls:
Paso 1: GET /cart → 200 (resumen del carrito)
Paso 2: PUT /cart/shipping → 200 (seleccionar envío)
Paso 3: GET /cart/total → 200 (total recalculado)
Paso 4: POST /orders/payment-intent → 200 (info de pago)
Paso 5: POST /orders/validate → 200 o 400 (validación)
Paso 6: POST /orders/confirm → 201 (pedido creado)
Criterios de Cobertura
Cobertura de flujos (mínimo): Cada flujo ejecutado al menos una vez. Cobertura de pasos: Cada paso en cada flujo ejecutado al menos una vez. Variación de datos: Mismo flujo con datos válidos/inválidos diferentes (combinar con EP/BVA).
Ejercicio: Deriva Test Cases de un Use Case
Use Case: Restablecer Password
Actor: Usuario Registrado Precondición: Usuario tiene cuenta registrada con email verificado
Flujo Principal:
- Usuario hace click en “Olvidé mi Password”
- Sistema muestra formulario de input de email
- Usuario ingresa email registrado
- Sistema envía link de restablecimiento al email
- Usuario hace click en el link dentro de 24 horas
- Sistema muestra formulario de nuevo password
- Usuario ingresa nuevo password (cumpliendo política: 8+ chars, 1 mayúscula, 1 dígito)
- Sistema valida y guarda nuevo password
- Sistema confirma cambio de password y envía email de notificación
Flujos Alternativos:
- 3a. Email no registrado → sistema muestra “Si la cuenta existe, se envió email” (seguridad)
- 5a. Link expirado (>24 horas) → sistema muestra “Link expirado”
- 5b. Link ya usado → sistema muestra “Link ya fue usado”
- 7a. Password no cumple política → sistema muestra error específico
- 7b. Nuevo password igual al anterior → sistema muestra “Elige un password diferente”
Tarea: Deriva test cases para todos los flujos. Agrega 2 escenarios de excepción adicionales no listados.
Pista
Piensa en: ¿Qué si el usuario solicita múltiples links de restablecimiento? ¿Qué pasa si la cuenta está bloqueada? ¿Qué hay de SQL injection en el campo de email?
Solución
Test cases de flujos documentados: 8 test cases (principal + alternativas con variaciones de política)
Escenarios de excepción adicionales:
| TC | Escenario | Esperado |
|---|---|---|
| TC9 | Múltiples solicitudes de restablecimiento → solo último link funciona | Links anteriores invalidados |
| TC10 | Cuenta desactivada → solicitar restablecimiento | Mensaje genérico (no revelar status) |
| TC11 | XSS en campo de email | Input sanitizado |
| TC12 | Concurrente: solicitar reset, cambiar password normalmente, luego click en link | Link debería ser inválido |
Total: 12 test cases.
Tips de Profesional
- Cada flujo alternativo es un test case. No los omitas — los flujos alternativos son donde se esconden la mayoría de los defectos.
- Cuestiona las precondiciones. ¿Qué pasa si una precondición NO se cumple? Ese es otro escenario de test.
- Piensa en las postcondiciones. Verifica no solo que la acción tuvo éxito, sino que todos los efectos secundarios ocurrieron.
- Los use cases combinan bien con testing exploratorio. Los flujos documentados guían el testing estructurado; luego explora más allá de los caminos documentados.
- Numera tus flujos consistentemente. “5a” significa “alternativa en el paso 5, variante a” — esto facilita la trazabilidad.