¿Qué Es State Transition Testing?

State transition testing modela un sistema como una máquina de estados finita — un sistema que puede estar en uno de un número limitado de estados, y transiciona entre estados en respuesta a eventos. Esta técnica es ideal para probar workflows, procesos y cualquier sistema con modos de operación distintos.

Conceptos Clave

  • Estado: Una condición en la que se encuentra el sistema (ej., “Sesión Cerrada”, “Activo”, “Bloqueado”)
  • Transición: Movimiento de un estado a otro
  • Evento: Algo que activa una transición (ej., “ingresar credenciales correctas”)
  • Condición de guarda: Una condición que debe ser verdadera para que la transición ocurra
  • Acción: Algo que sucede durante una transición (ej., “enviar notificación”)

Diagrama de Transición de Estados

stateDiagram-v2 [*] --> SesionCerrada SesionCerrada --> SesionAbierta: Credenciales válidas SesionAbierta --> SesionCerrada: Cerrar sesión SesionAbierta --> Bloqueado: 30 min inactividad Bloqueado --> SesionAbierta: Credenciales válidas Bloqueado --> SesionCerrada: Cerrar sesión SesionCerrada --> SesionCerrada: Credenciales inválidas [intentos < 3] SesionCerrada --> Suspendido: Credenciales inválidas [intentos = 3] Suspendido --> SesionCerrada: Admin desbloquea

Este diagrama muestra un sistema de autenticación con 4 estados y 7 transiciones.

Leyendo el Diagrama

Cada flecha representa una transición con el formato: Evento [Guarda] / Acción

  • Credenciales válidas → Evento que activa la transición
  • [intentos < 3] → Condición de guarda que debe ser verdadera
  • El estado destino es donde apunta la flecha

Cuándo Usar State Transition Testing

Esta técnica brilla cuando:

  • El sistema tiene modos o statuses claramente definidos (orden: pendiente → pagada → enviada → entregada)
  • Los workflows del usuario tienen múltiples caminos (carrito de compras, proceso de checkout)
  • Los protocolos tienen estados definidos (conexiones TCP, flujos de autenticación)
  • Los dispositivos de hardware tienen modos operacionales (standby, activo, error)

Construyendo una Tabla de Transición de Estados

La tabla lista cada combinación estado-evento sistemáticamente:

Estado ActualEventoSiguiente EstadoAcción
SesionCerradaCredenciales válidasSesionAbiertaCrear sesión
SesionCerradaCredenciales inválidas (< 3)SesionCerradaIncrementar contador
SesionCerradaCredenciales inválidas (= 3)SuspendidoBloquear cuenta
SesionAbiertaCerrar sesiónSesionCerradaDestruir sesión
SesionAbierta30 min inactividadBloqueadoGuardar estado
BloqueadoCredenciales válidasSesionAbiertaRestaurar estado
BloqueadoCerrar sesiónSesionCerradaDestruir sesión
SuspendidoAdmin desbloqueaSesionCerradaResetear contador

Identificando Transiciones Inválidas

El verdadero poder de la tabla es encontrar lo que no debería suceder. Para cada par estado-evento que NO está en la tabla, el sistema debería ignorar el evento o mostrar un error.

Estado ActualEvento InválidoEsperado
SesionAbiertaCredenciales válidasIgnorar (ya tiene sesión)
SuspendidoCredenciales válidasRechazar (cuenta suspendida)
Suspendido30 min inactividadIgnorar (no tiene sesión)

Niveles de Cobertura

Cobertura 0-switch: Probar cada transición válida al menos una vez. Cobertura mínima.

Cobertura 1-switch: Probar cada par de transiciones consecutivas. Detecta defectos donde el historial del sistema importa.

Secuencias 1-switch de ejemplo:
SesionCerrada → SesionAbierta → Bloqueado
SesionCerrada → SesionAbierta → SesionCerrada
Bloqueado → SesionAbierta → Bloqueado

Técnicas Avanzadas de State Transition

Máquina de Estados de Orden E-Commerce

Las máquinas de estados del mundo real pueden ser complejas. Este es un ciclo de vida de orden típico:

stateDiagram-v2 [*] --> Creada Creada --> PagoPendiente: Checkout PagoPendiente --> Pagada: Pago exitoso PagoPendiente --> Creada: Pago fallido PagoPendiente --> Cancelada: Usuario cancela Pagada --> Procesando: Almacén confirma Procesando --> Enviada: Carrier recoge Enviada --> Entregada: Entrega confirmada Enviada --> DevolucionSolicitada: Cliente solicita devolución Entregada --> DevolucionSolicitada: Cliente solicita devolución DevolucionSolicitada --> Devuelta: Devolución recibida Pagada --> Reembolsada: Admin reembolsa DevolucionSolicitada --> Reembolsada: Devolución aprobada Cancelada --> [*] Entregada --> [*] Reembolsada --> [*]

Desde este diagrama, deriva test cases para:

  1. Happy path: Creada → PagoPendiente → Pagada → Procesando → Enviada → Entregada
  2. Fallo de pago: Creada → PagoPendiente → Creada (reintentar) → PagoPendiente → Pagada
  3. Cancelación: Creada → PagoPendiente → Cancelada
  4. Flujo de devolución: … → Entregada → DevolucionSolicitada → Devuelta
  5. Transiciones inválidas: ¿Puede una orden “Entregada” volver a “Procesando”? No debería.

Cobertura N-Switch

Para sistemas críticos, prueba secuencias de N+1 transiciones consecutivas:

0-switch: Cada transición una vez (8 transiciones = 8 tests) 1-switch: Cada par de transiciones 2-switch: Cada triple de transiciones

Mayor N detecta más defectos dependientes del historial pero crece exponencialmente.

Máquinas de Estados Concurrentes

Algunos sistemas tienen múltiples máquinas de estados independientes corriendo simultáneamente. Por ejemplo, un reproductor de medios podría tener:

  • Estado de reproducción: Detenido, Reproduciendo, Pausado
  • Estado de conexión: Online, Offline, Reconectando
  • Estado de descarga: Inactivo, Descargando, Pausado, Completo

Prueba la interacción entre máquinas de estados: ¿Qué pasa con una descarga cuando la conexión se pierde? ¿Qué pasa con la reproducción cuando la descarga del track actual se completa?

State Transition Testing para APIs

Los recursos de API frecuentemente siguen máquinas de estados. Prueba haciendo API calls que activen transiciones:

POST /orders                    → Creada
POST /orders/{id}/checkout      → PagoPendiente
POST /orders/{id}/pay           → Pagada
POST /orders/{id}/cancel        → 409 Conflict (no se puede cancelar orden pagada)

Ejercicio: Diseña un Suite de Tests de Transición de Estados

Escenario: Un sistema de aprobación de documentos tiene estos estados y transiciones:

  • Borrador → Enviar → Pendiente de Revisión
  • Pendiente de Revisión → Aprobar → Aprobado
  • Pendiente de Revisión → Rechazar → Borrador (con comentarios)
  • Pendiente de Revisión → Solicitar Cambios → Cambios Solicitados
  • Cambios Solicitados → Reenviar → Pendiente de Revisión
  • Aprobado → Publicar → Publicado
  • Publicado → Archivar → Archivado
  • Cualquier estado → Eliminar → Eliminado (solo admin)

Tareas:

  1. Dibuja el diagrama de transición de estados
  2. Construye la tabla de transición de estados
  3. Lista todas las transiciones inválidas
  4. Diseña test cases para cobertura 0-switch
Pista

Hay 7 estados y 8 transiciones válidas (más Delete desde cada estado). Para transiciones inválidas, piensa qué eventos no deberían funcionar en cada estado — ej., ¿puedes “Aprobar” un Borrador sin enviarlo primero?

Solución

Tabla de transición de estados:

Estado ActualEventoSiguiente Estado
BorradorEnviarPendiente de Revisión
BorradorEliminar (admin)Eliminado
Pendiente de RevisiónAprobarAprobado
Pendiente de RevisiónRechazarBorrador
Pendiente de RevisiónSolicitar CambiosCambios Solicitados
Pendiente de RevisiónEliminar (admin)Eliminado
Cambios SolicitadosReenviarPendiente de Revisión
Cambios SolicitadosEliminar (admin)Eliminado
AprobadoPublicarPublicado
AprobadoEliminar (admin)Eliminado
PublicadoArchivarArchivado
PublicadoEliminar (admin)Eliminado
ArchivadoEliminar (admin)Eliminado

Transiciones inválidas clave para probar:

EstadoEvento InválidoEsperado
BorradorAprobarError: debe enviarse primero
BorradorPublicarError: no está aprobado
AprobadoEnviarError: ya está aprobado
ArchivadoPublicarError: está archivado
EliminadoCualquier eventoError: documento eliminado

Test cases de cobertura 0-switch: 8 para transiciones válidas + 5 para inválidas = 13 test cases.

Tips de Profesional

  • Comienza con el happy path. Mapea el escenario de éxito principal primero, luego agrega caminos alternativos y de error.
  • Busca transiciones faltantes. Si un estado no tiene transiciones salientes, los usuarios pueden quedarse atrapados. Si un estado no tiene transiciones entrantes (excepto el estado inicial), es inalcanzable.
  • Prueba eventos concurrentes. ¿Qué pasa si dos eventos ocurren simultáneamente? Las race conditions en máquinas de estados son una fuente común de defectos.
  • Usa máquinas de estados para test automation. Muchos frameworks de testing soportan modelos de máquinas de estados para generar secuencias de tests automáticamente.
  • Las condiciones de guarda necesitan BVA. Si una transición tiene una guarda como [intentos < 3], aplica boundary value analysis a la condición de guarda.