19. Diseño de casos de prueba: transiciones de estado

19.1 Introducción

Algunos sistemas cambian su comportamiento según el estado en el que se encuentran. Una orden puede estar pendiente, pagada, enviada o cancelada. Una cuenta puede estar activa, bloqueada o suspendida. Un ticket puede estar abierto, en progreso, resuelto o cerrado.

La técnica de transiciones de estado ayuda a diseñar pruebas cuando el resultado depende del estado actual y de la acción o evento que ocurre.

Esta técnica es especialmente útil para flujos donde no solo importa qué acción se ejecuta, sino también desde qué estado se ejecuta y hacia qué estado debería pasar el sistema.

19.2 ¿Qué es un estado?

Un estado es una situación o condición en la que se encuentra un objeto, entidad o proceso en un momento determinado.

Ejemplos:

• Una orden puede estar Pendiente, Pagada, Enviada, Entregada o Cancelada.
• Una cuenta puede estar Activa, Bloqueada o Eliminada.
• Un turno puede estar Reservado, Confirmado, Cancelado o Atendido.
• Una factura puede estar Borrador, Emitida, Pagada o Anulada.
• Un reclamo puede estar Abierto, En análisis, Resuelto o Cerrado.

El estado condiciona qué acciones están permitidas y qué acciones deben rechazarse.

19.3 ¿Qué es una transición?

Una transición es el cambio de un estado a otro como resultado de una acción, evento o condición.

Ejemplo:

La transición define qué cambio debería ocurrir. Si el sistema pasa a un estado incorrecto o permite una transición prohibida, existe un defecto.

19.4 Eventos y acciones

Un evento o acción es lo que provoca una transición. Puede ser iniciado por un usuario, por otro sistema o por un proceso automático.

Ejemplos:

• El usuario paga una orden.
• El administrador cancela una reserva.
• El sistema bloquea una cuenta por intentos fallidos.
• Un servicio externo confirma un pago.
• Una tarea programada vence una promoción.
• El usuario cierra un ticket.

Para probar transiciones, debemos conocer estado inicial, acción ejecutada y estado final esperado.

19.5 Cuándo conviene usar esta técnica

Conviene usar transiciones de estado cuando:

• El comportamiento depende del estado actual.
• Existen flujos con etapas claras.
• Algunas acciones están permitidas solo en ciertos estados.
• Hay estados finales de los que no se debería salir.
• El sistema debe rechazar transiciones inválidas.
• Existen procesos automáticos que cambian estados.
• El historial o la secuencia de acciones importa.

Si una acción siempre produce el mismo resultado sin importar el estado anterior, quizá otra técnica sea más simple. Pero si el estado cambia el comportamiento, esta técnica aporta claridad.

19.6 Diagrama de estados

Un diagrama de estados representa estados y transiciones. Los estados suelen mostrarse como nodos y las transiciones como flechas.

Ejemplo conceptual para una orden:

Este diagrama muestra que una orden pendiente puede pagarse o cancelarse. Una orden pagada puede enviarse o cancelarse. Una orden enviada puede entregarse. No se indica, por ejemplo, que una orden entregada pueda volver a pendiente.

19.7 Tabla de transiciones

Además del diagrama, podemos usar una tabla. La tabla suele ser más práctica para derivar casos de prueba.

Cada fila puede convertirse en un caso de prueba.

19.8 Transiciones válidas e inválidas

No solo debemos probar transiciones permitidas. También debemos comprobar que el sistema rechace transiciones inválidas.

Ejemplos para una orden:

• Pendiente -> Pagada: válida.
• Pagada -> Enviada: válida.
• Entregada -> Pendiente: inválida.
• Cancelada -> Enviada: inválida.
• Pendiente -> Entregada directamente: inválida.

Probar solo caminos válidos puede dejar defectos de permisos o reglas de negocio sin detectar.

19.9 Ejemplo 1: orden de compra

Estados posibles:

• Pendiente.
• Pagada.
• Enviada.
• Entregada.
• Cancelada.

Reglas:

• Una orden pendiente puede pagarse o cancelarse.
• Una orden pagada puede enviarse o cancelarse.
• Una orden enviada puede entregarse.
• Una orden entregada no puede cancelarse.
• Una orden cancelada no puede modificarse.

Estas reglas son una base excelente para crear una tabla de transiciones y casos de prueba.

19.10 Casos derivados para orden de compra

Los casos CP-ORD-005 y CP-ORD-006 son importantes porque verifican restricciones.

19.11 Ejemplo 2: cuenta de usuario

Estados posibles de una cuenta:

• Activa.
• Bloqueada.
• Suspendida.
• Eliminada.

Reglas:

• Una cuenta activa puede bloquearse por intentos fallidos.
• Una cuenta bloqueada puede desbloquearse mediante recuperación.
• Una cuenta activa puede suspenderse por decisión administrativa.
• Una cuenta suspendida puede reactivarse por un administrador.
• Una cuenta eliminada no puede iniciar sesión ni reactivarse.

Estas reglas permiten diseñar pruebas de inicio de sesión, administración y recuperación de cuenta.

19.12 Estados finales

Un estado final es un estado desde el cual no se esperan nuevas transiciones normales. Por ejemplo, una orden Cancelada o Entregada podría considerarse final en ciertos sistemas.

Los estados finales requieren atención porque el sistema debe impedir acciones que ya no corresponden.

Ejemplos:

• No permitir pagar una orden cancelada.
• No permitir cancelar una orden entregada.
• No permitir editar una factura anulada.
• No permitir reabrir una cuenta eliminada si la regla lo prohíbe.

Probar estados finales ayuda a evitar inconsistencias.

19.13 Eventos automáticos

No todas las transiciones son iniciadas por usuarios. Algunas ocurren automáticamente.

Ejemplos:

• Una reserva pasa a Vencida si no se paga en 24 horas.
• Una promoción pasa a Inactiva al llegar la fecha de fin.
• Una sesión expira después de cierto tiempo sin actividad.
• Una cuenta se bloquea después de cinco intentos fallidos.
• Un pedido pasa a Demorado si no se despacha a tiempo.

Estas transiciones pueden requerir manipular fechas, ejecutar procesos programados o simular eventos.

19.14 Secuencias de transiciones

A veces no basta con probar una transición aislada. Hay que probar secuencias completas.

Ejemplo de orden:

Ejemplo de cuenta:

Las secuencias permiten detectar problemas que aparecen después de varios cambios de estado, como datos inconsistentes, permisos incorrectos o acciones que quedan habilitadas indebidamente.

19.15 Matriz de estados y eventos

Otra forma de organizar la información es una matriz donde las filas son estados y las columnas son acciones o eventos.

Esta matriz es muy útil para detectar acciones que deben rechazarse en ciertos estados.

19.16 Relación con tablas de decisión

Las tablas de decisión y las transiciones de estado pueden parecer similares, pero se enfocan en problemas distintos.

Si el orden o secuencia de estados importa, probablemente convenga usar transiciones de estado.

19.17 Ventajas

La técnica de transiciones de estado tiene varias ventajas:

• Ordena flujos con estados claros.
• Ayuda a probar acciones permitidas y prohibidas.
• Detecta estados finales mal manejados.
• Permite diseñar pruebas de secuencias completas.
• Facilita conversar con negocio sobre reglas de ciclo de vida.
• Sirve para órdenes, cuentas, tickets, reservas, facturas y procesos.

Es muy útil cuando el comportamiento actual depende de lo que ocurrió antes.

19.18 Límites

También tiene límites:

• No es la mejor técnica si no hay estados claros.
• Puede crecer mucho si hay muchos estados y eventos.
• No reemplaza valores límite, clases de equivalencia o tablas de decisión.
• Requiere entender bien reglas de negocio y estados posibles.
• Puede necesitar preparación compleja de datos para ubicar el sistema en un estado específico.

Si el modelo de estados no está documentado, el primer paso puede ser construirlo con el equipo.

19.19 Errores comunes

Al aplicar esta técnica, algunos errores frecuentes son:

• Probar solo transiciones válidas y olvidar las inválidas.
• No identificar estados finales.
• Confundir estado con acción.
• No preparar correctamente el estado inicial.
• No verificar el estado final después de la acción.
• Olvidar eventos automáticos o vencimientos.
• No probar secuencias relevantes.
• Asumir reglas sin confirmarlas con negocio o documentación.

Estos errores pueden permitir inconsistencias graves en procesos de negocio.

19.20 Buenas prácticas

Para aplicar bien transiciones de estado conviene:

• Listar todos los estados posibles.
• Identificar acciones o eventos que cambian estados.
• Definir estado inicial y estado final esperado.
• Probar transiciones válidas e inválidas.
• Incluir estados finales y acciones prohibidas.
• Diseñar pruebas para secuencias críticas.
• Preparar datos que permitan ubicar el sistema en cada estado.
• Revisar reglas con negocio, analistas o desarrolladores.
• Actualizar el modelo si cambian los procesos.

19.21 Qué debes recordar de este tema

• Un estado representa la situación actual de una entidad o proceso.
• Una transición es el cambio de un estado a otro por una acción o evento.
• La técnica sirve cuando el comportamiento depende del estado actual.
• Debemos probar transiciones válidas e inválidas.
• Los estados finales requieren especial atención.
• Algunas transiciones son automáticas y dependen de tiempo o procesos.
• Las secuencias pueden revelar defectos que una transición aislada no muestra.
• Una matriz de estados y eventos ayuda a organizar casos de prueba.

19.22 Conclusión

Las transiciones de estado permiten probar sistemas donde el comportamiento depende de estados previos y acciones. Son fundamentales para procesos como compras, reservas, cuentas, tickets, facturas, préstamos y flujos administrativos.

Esta técnica ayuda a validar que las acciones permitidas cambien el estado correctamente y que las acciones prohibidas sean rechazadas. También ayuda a detectar inconsistencias en estados finales y secuencias de negocio.

En el próximo tema estudiaremos pruebas positivas, negativas y casos borde, conceptos esenciales para equilibrar caminos exitosos, errores esperados y condiciones extremas.