Glosario · Diseño de pruebas
Pruebas de transición de estados
En inglés: State transition testing
También llamado: transición de estados, diagrama de transición de estados, tabla de transición de estados, state transition diagram
Definición
Técnica de diseño de pruebas que modela un sistema como estados y los eventos que lo mueven entre ellos, y luego prueba las transiciones válidas y las no válidas.
Las pruebas de transición de estados (state transition testing) se aplican cuando la respuesta del sistema depende de lo que ocurrió antes, no solo de la entrada actual. Modelas el sistema como un conjunto de estados, los eventos que provocan transiciones entre ellos y las acciones o condiciones de guarda de cada transición. Los tests cubren entonces las transiciones válidas y, igual de importante, comprueban que las transiciones no válidas se rechazan.
Ejemplo: bloqueo de login
Una cuenta se bloquea tras tres contraseñas incorrectas consecutivas, y un login correcto reinicia el contador.
Estados: Active (0 failures), 1 failure, 2 failures, Locked, Logged in.
| Estado actual | Evento | Estado siguiente |
|---|---|---|
| Active (0) | Contraseña incorrecta | 1 failure |
| Active (0) | Contraseña correcta | Logged in |
| 1 failure | Contraseña incorrecta | 2 failures |
| 1 failure | Contraseña correcta | Logged in (contador reiniciado) |
| 2 failures | Contraseña incorrecta | Locked |
| 2 failures | Contraseña correcta | Logged in (contador reiniciado) |
| Locked | Contraseña correcta | Locked (rechazado) |
| Locked | Desbloqueo por un administrador | Active (0) |
Tests derivados del modelo:
- Cada transición válida al menos una vez (cobertura 0-switch): incorrecta, incorrecta, incorrecta lleva a Locked; incorrecta, correcta lleva a Logged in.
- Eventos no válidos o inesperados: la contraseña correcta en una cuenta bloqueada debe seguir rechazándose. Ahí es donde se esconden los bugs de seguridad.
- Secuencias: incorrecta, correcta, después logout e incorrecta, incorrecta. ¿Se reinicia realmente el contador, o la cuenta se bloquea en el segundo fallo? Probar pares de transiciones consecutivas se llama cobertura 1-switch.
Dónde se aplica
En cualquier cosa con un ciclo de vida: pedidos (creado, pagado, enviado, entregado, cancelado, reembolsado), flujos de bugs, suscripciones, aprobaciones de documentos, estados de pago, reproductores multimedia y asistentes (wizards) de UI. Preguntas que vale la pena hacerse en cada estado: ¿qué eventos se permiten aquí?, ¿qué ocurre con los no permitidos?, y ¿puede el usuario llegar a este estado por una ruta inesperada, como el botón Atrás del navegador o una llamada directa a la API?
Errores comunes
- Probar solo el camino feliz. Creado, pagado, enviado es un solo camino. ¿Se puede cancelar un pedido después del envío? ¿Reembolsarlo dos veces?
- Probar solo a través de la UI. Puede que la UI oculte el botón Cancelar, pero la API quizá siga aceptando la solicitud. Prueba también las transiciones a nivel de API.
- Olvidar la tabla de estados. El diagrama muestra lo que debería ocurrir; la tabla completa de cada estado frente a cada evento muestra los huecos donde el comportamiento no está definido.