Cuando una tabla es más clara
En resumen: El texto sirve para una regla, pero es malo para muchos casos. Un proceso muestra quién hace qué y en qué orden, un caso de uso muestra el objetivo y lo que puede salir mal, una máquina de estados muestra la vida del pedido y una tabla de decisión muestra cada combinación.
Problema
Tres frases, dos respuestas
El dueño escribe la regla del descuento:
El código promocional da un 10 % de descuento. El código no se aplica a los productos rebajados. Los clientes fieles siempre tienen un 5 % de descuento. Los descuentos no se suman.
El programador y el tester la leen. Un cliente fiel con un código válido compra un producto sin rebaja. El programador calcula 10 %. El tester calcula 15 %, porque «siempre». Cada frase es clara por separado. La combinación, no.
Tres condiciones con dos respuestas cada una dan ocho casos. El texto los describe a trozos. Una tabla los mostrará todos.
La idea
Cuando una imagen es más clara
El texto sirve para una regla. Cuando hay un orden de pasos, muchos participantes, muchos estados o muchas combinaciones, un modelo dice más:
| La pregunta | El modelo | En la tienda |
|---|---|---|
| ¿Quién hace qué, y en qué orden? | proceso de negocio | el pedido desde el carrito hasta la mensajería |
| ¿Cómo alcanza una persona un objetivo, y qué puede salir mal? | caso de uso | «Hacer un pedido» |
| ¿Cuál es la vida de una cosa? | máquina de estados | nuevo → pagado → enviado → entregado |
| ¿Qué pasa con cada combinación de condiciones? | tabla de decisión | código promocional, precio rebajado y fidelidad |
Un modelo no sustituye a los requisitos. Es un requisito escrito de otra forma, y por eso se puede revisar y probar como cualquier otro.
La idea
El proceso de negocio
Un proceso de negocio muestra los pasos de un trabajo, en orden, por participante. La notación estándar es BPMN. Aquí bastan cuatro símbolos: un evento (un círculo: pasa algo, como un inicio o un fin), una actividad (un rectángulo: alguien hace algo), una compuerta (un rombo: una pregunta con varias salidas) y los carriles (franjas: una por participante).
El proceso del pedido, escrito como tabla:
| # | Carril | Símbolo | Paso |
|---|---|---|---|
| 1 | Cliente | evento (inicio) | El cliente pulsa «Pedir». |
| 2 | Tienda | actividad | Crea un pedido en el estado «nuevo». |
| 3 | Cliente | actividad | Paga con tarjeta. |
| 4 | Tienda | compuerta | ¿Se completó el pago? No → fin «El pedido espera el pago». Sí → 5. |
| 5 | Tienda | actividad | Marca el pedido como «pagado». El almacén imprime la etiqueta. |
| 6 | Almacén | actividad | Embala el paquete y lo entrega a la mensajería. El pedido pasa a «enviado». |
| 7 | Mensajería | actividad | Entrega el paquete. El pedido pasa a «entregado». |
| 8 | Cliente | evento (fin) | El cliente tiene el paquete. |
La tabla es más pobre que el dibujo, pero dice lo mismo. Lo más valioso es el paso 5: ahí el trabajo pasa de la tienda al almacén, y ahí se perdió la dirección nueva.
Más precisamente, para curiosos
BPMN (Business Process Model and Notation) es un estándar de OMG, versión 2.0. Tiene muchos más símbolos: mensajes entre participantes, temporizadores, subprocesos, excepciones. En BABOK, el modelado de procesos es una técnica aparte. Para el analista y el tester basta con saber leerlo: ver los carriles, las compuertas y los lugares donde el trabajo pasa de uno a otro.
Pruébalo
Lee el proceso
La idea
El caso de uso
Un caso de uso describe cómo un actor (un rol fuera del sistema) alcanza un objetivo con el sistema. Tiene un flujo principal, donde todo sale bien, y flujos alternativos para todo lo que puede salir mal.
Caso de uso: Hacer un pedido. Actor: el cliente. Precondición: el cliente ha iniciado sesión.
Flujo principal:
- El cliente abre el carrito.
- El sistema muestra los productos, el importe y el envío: 0,00 € desde 50 € inclusive, y en otro caso 4,90 €.
- El cliente elige una dirección.
- El cliente pulsa «Pedir».
- El sistema crea el pedido como «nuevo» y muestra el pago.
- El cliente paga. El sistema marca el pedido como «pagado» y envía una confirmación.
Flujos alternativos:
- 2a. El carrito está vacío: el sistema no permite hacer el pedido y dice por qué.
- 2b. Un producto tiene más de 10 unidades: el sistema indica el máximo y no continúa.
- 4a. El cliente introdujo un código promocional que ya ha usado: el sistema rechaza el código, el importe queda sin descuento y el cliente continúa desde el paso 4.
- 6a. Se rechaza el pago: el pedido sigue «nuevo» y el cliente puede intentarlo de nuevo.
Todos escriben el flujo principal. El valor está en los alternativos. Cada uno es una regla que el programador tiene que construir y el tester tiene que comprobar.
Más precisamente, para curiosos
El formato de aquí es parecido al de Alistair Cockburn en «Writing Effective Use Cases»: un escenario principal de éxito y extensiones numeradas por paso. UML tiene además un diagrama de casos de uso: un monigote para el actor y un óvalo para el caso de uso. Muestra qué casos de uso existen, pero no qué pasa en ellos. El texto de arriba dice más.
Pruébalo
Lee el caso de uso
La idea
La máquina de estados
Un pedido tiene una vida: es nuevo, luego pagado, luego enviado, luego entregado. Cada una de esas situaciones es un estado, y el paso de uno a otro, ante algún evento, es una transición. Juntos forman una máquina de estados.
Como tabla, la máquina del pedido queda así:
| Desde | Evento y condición | Hasta |
|---|---|---|
| Nuevo | el cliente paga | Pagado |
| Nuevo | el cliente cancela | Cancelado |
| Pagado | el almacén entrega el paquete a la mensajería | Enviado |
| Enviado | la mensajería entrega | Entregado |
| Entregado | el cliente solicita la devolución, dentro de los 14 días desde la recepción | Devuelto |
La tabla muestra también lo que no está permitido. Todo par «desde → hasta» que no está aquí está prohibido. Un pedido enviado no pasa a cancelado. Uno entregado no pasa a nuevo.
Esa es su fuerza. En texto, «se permite cancelar antes del envío» suena claro. En la tabla ves enseguida si cada caso de «antes del envío» tiene su propia fila.
Ejercicio
¿Qué fila falta?
1. La transición que falta. Compara la tabla de transiciones con las reglas de la tienda.
La idea
La tabla de decisión
Una tabla de decisión tiene una fila por cada condición y cada acción, y una columna por cada combinación. La regla del descuento del principio, después de que el dueño haya dicho que cuando se aplican dos descuentos gana el mayor:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| El código es válido | sí | sí | sí | sí | no | no | no | no |
| El producto está rebajado | sí | sí | no | no | sí | sí | no | no |
| El cliente es fiel | sí | no | sí | no | sí | no | sí | no |
| Descuento | ? | 0 % | ? | 10 % | 5 % | ? | 5 % | 0 % |
La tabla hace dos cosas. Primero, es un requisito que se lee de una sola manera: cada caso tiene exactamente una respuesta. Segundo, muestra los huecos del texto. La columna 3 es justo donde el programador y el tester discreparon. La pregunta al dueño («¿10 o 15 %?») sale de la celda vacía, no de la inspiración.
Más precisamente, para curiosos
Las tablas de decisión son también una técnica de diseño de pruebas (ISTQB CTFL, técnicas de caja negra). Allí cada columna es un caso de prueba, y las columnas con el mismo resultado se juntan con «—» (no importa): por ejemplo, las columnas 5 y 7 son «sin código, cliente fiel → 5 %», haya rebaja o no. El módulo «Técnicas de diseño de pruebas» sigue desde aquí. En un requisito la tabla se mantiene completa, para que no quede ningún caso en el que nadie haya pensado.
Ejercicio
Modelos como requisitos
1. Rellena la tabla. Las tres celdas vacías de la tabla de descuentos, y cuántas columnas hay.
Test