Cuando el resultado de un sistema depende de la mezcla de varias condiciones y no de un solo dato de entrada, las técnicas individuales como particiones de equivalencia o valores límite se quedan cortas. Aquí es donde las tablas de decisión se convierten en la herramienta precisa para detectar interacciones ocultas, combinaciones olvidadas y requisitos incompletos antes de escribir una sola línea de código.
¿Por qué un solo campo de entrada no basta para cubrir la lógica real?
Imagina el checkout de una tienda online: el descuento final no depende solo del monto del carrito. Depende de si eres miembro, si tienes cupón y si superaste un umbral de gasto. Cambia una combinación y cambia todo [0:18]. Probar cada condición por separado es como probar cada ingrediente de una receta de forma individual y asumir que el plato sale bien.
La lógica combinatoria aparece cuando el resultado del sistema se determina por la interacción simultánea de múltiples condiciones. Hay cuatro señales claras de que la necesitas [0:42]:
- El resultado cambia según qué condiciones aparecen juntas.
- Necesitas verificar dos o más condiciones simultáneamente para saber qué acción se dispara.
- Una condición es irrelevante en un caso pero relevante en otro.
- Existen combinaciones imposibles que no pueden ocurrir en la vida real.
Un ejemplo concreto: un sistema de renta de bicicletas da veinte por ciento de descuento a miembros, pero si ese miembro se pasó de la fecha de devolución, el descuento desaparece. Ninguna prueba individual sobre membresía o sobre fecha captura esa interacción.
¿Qué son las condiciones y acciones en una tabla de decisión?
Antes de construir la tabla necesitas dos ingredientes. Una condición es una expresión que solo puede ser verdadera o falsa, como un interruptor [1:10]. Pero la redacción importa: no escribas "el usuario está activo", que es vago. Escribe "el usuario ha iniciado sesión en los últimos treinta días". Dos personas leyéndola deben llegar a la misma conclusión.
Una acción es lo que el sistema hace después de evaluar las condiciones, y debe ser medible. No "el sistema responde rápido", sino "devuelve confirmación en menos de dos segundos". Si un tester no puede verificarlo, la redacción necesita revisión.
¿Cómo evitar la explosión de combinaciones al construir la tabla?
Con tres condiciones binarias tienes ocho columnas. Con cinco, treinta y dos. Con diez, más de mil. Cada condición nueva duplica el número [1:55]. La solución no es abandonar la tabla, es construirla con inteligencia aplicando tres estrategias:
- Eliminar combinaciones imposibles: un no miembro no puede recibir un regalo reservado exclusivamente para miembros. Esa columna se marca como "no aplica" y se excluye.
- Fusionar columnas: cuando una condición no cambia el resultado, dos columnas se vuelven una y la condición irrelevante se marca con un guion.
- Priorizar combinaciones de alto riesgo: pérdida de datos, fallas en pagos, problemas de seguridad. Esas merecen columna propia sin negociación.
La cobertura se mide dividiendo columnas factibles probadas entre el total de columnas factibles [2:27].
¿Cómo se ve una tabla de decisión aplicada a un caso real?
Tienda online, tres condiciones en el checkout [2:40]: ¿es miembro?, ¿tiene cupón válido?, ¿el carrito supera cincuenta dólares? Las acciones posibles son: descuento de membresía, descuento de cupón y envío gratis. Las ocho combinaciones producen resultados distintos:
- Miembro con cupón y carrito alto: las tres acciones.
- Miembro con cupón y carrito bajo: descuento de membresía y cupón, sin envío.
- Miembro sin cupón y carrito alto: descuento de membresía y envío.
- Miembro sin cupón y carrito bajo: solo descuento de membresía.
- No miembro con cupón y carrito alto: cupón y envío.
- No miembro con cupón y carrito bajo: solo cupón.
- No miembro sin cupón y carrito alto: solo envío.
- No miembro sin cupón y carrito bajo: nada.
¿Cómo validar que tu tabla está completa?
Antes de dar por terminada la tabla, pasa esta lista de verificación [3:38]:
- ¿Cada columna tiene resultado claro?
- ¿Las combinaciones imposibles están eliminadas?
- ¿No hay columnas duplicadas?
- ¿Las condiciones irrelevantes están marcadas con guion?
Si una columna no tiene resultado definido, acabas de encontrar un requisito incompleto sin ejecutar ninguna prueba. Cada columna validada se convierte en un caso de prueba con entrada específica y resultado esperado.
Con particiones, valores límite y tablas de decisión se completa un arsenal sólido de técnicas de caja negra. El siguiente paso natural es cambiar de perspectiva: ¿qué ocurre cuando sí tienes acceso al código o a la arquitectura interna? Ahí entran las pruebas de caja blanca y caja gris. Si ya identificaste reglas combinatorias en tu proyecto, intenta dibujar la tabla: cada hueco que encuentres es valor real antes de que nadie escriba código.
