Testing con Tablas de Decisión

¿Qué Es Decision Table Testing? #

Decision table testing es una técnica de caja negra para probar sistemas donde el output depende de combinaciones de condiciones. Cuando las reglas de negocio involucran múltiples inputs que interactúan para determinar el resultado, una tabla de decisión asegura que pruebes cada combinación significativa.

Cuándo Usar Tablas de Decisión #

Usa esta técnica cuando:

• Múltiples condiciones se combinan para determinar un resultado
• Las reglas de negocio contienen lógica if/then/else compleja
• La especificación dice “si A y B, entonces X; si A y no B, entonces Y”
• Necesitas verificar que cada combinación se maneje correctamente

Anatomía de una Tabla de Decisión #

Una tabla de decisión tiene cuatro cuadrantes:

                    | Regla 1 | Regla 2 | Regla 3 | Regla 4 |
--------------------|---------|---------|---------|---------|
Condiciones:        |         |         |         |         |
  Condición 1       |    V    |    V    |    F    |    F    |
  Condición 2       |    V    |    F    |    V    |    F    |
--------------------|---------|---------|---------|---------|
Acciones:           |         |         |         |         |
  Acción 1          |    X    |    X    |         |         |
  Acción 2          |         |         |    X    |    X    |

• Condiciones (mitad superior): Condiciones de input que pueden ser verdaderas (V) o falsas (F)
• Reglas (columnas): Cada combinación única de valores de condiciones
• Acciones (mitad inferior): Los resultados esperados para cada regla
• X marca qué acciones deben ocurrir para cada regla

Construyendo una Tabla de Decisión: Paso a Paso #

Ejemplo: Procesamiento de Reclamos de Seguro #

Reglas de negocio:

• Si el reclamante es miembro Y el reclamo es menor a $1000, auto-aprobar
• Si el reclamante es miembro Y el reclamo es $1000+, enviar al gerente
• Si el reclamante NO es miembro Y el reclamo es menor a $1000, enviar a revisión
• Si el reclamante NO es miembro Y el reclamo es $1000+, rechazar

Condiciones:

1. ¿Es miembro? (V/F)
2. ¿Reclamo < $1000? (V/F)

Tabla de decisión:

4 reglas = 4 test cases. Cada test case ejercita una combinación única.

Manejando Más de Dos Valores #

Cuando las condiciones tienen más de dos valores, la tabla crece proporcionalmente. Una condición con 3 valores combinada con una condición binaria produce 3 x 2 = 6 reglas.

Ejemplo: Velocidad de envío + membresía

Simplificando Tablas de Decisión #

Cuando dos reglas tienen las mismas acciones y difieren en solo una condición, puedes fusionarlas. La condición irrelevante se marca con un guión (-).

Antes de simplificar:

Después de simplificar:

La Condición A no importa cuando B es verdadera — una regla reemplaza dos.

Técnicas Avanzadas de Decision Table #

Manejando Tablas Grandes #

Con N condiciones binarias, una tabla completa tiene 2^N reglas. Para 5 condiciones son 32 reglas. Para 10 condiciones, 1024. Las tablas grandes se vuelven impracticables, así que usa estas estrategias:

1. Eliminar combinaciones imposibles. No todas las combinaciones pueden ocurrir en la realidad.

Condición: "Usuario logueado" = F
Condición: "Rol de usuario es admin" = V
→ Imposible: no puedes ser admin si no estás logueado

2. Identificar condiciones independientes. Si algunas condiciones no interactúan, divídelas en tablas separadas más pequeñas.

3. Usar cause-effect graphing (cubierto en la lección 3.5) para identificar restricciones entre condiciones.

Decision Tables para Testing de APIs #

Las tablas de decisión sobresalen al probar endpoints de API con múltiples parámetros que afectan la respuesta:

Ejemplo: GET /orders endpoint

Nota el patrón en cascada: las fallas tempranas (auth, permiso) hacen que las condiciones posteriores sean irrelevantes (marcadas con -).

Tablas de Decisión de Entrada Extendida #

En vez de V/F, las condiciones pueden tener valores específicos. Esto se llama tabla de entrada extendida.

Ejemplo: Cálculo de impuestos

Ejercicio: Construye una Tabla de Decisión #

Escenario: Un sistema de aprobación de préstamos bancarios usa estas reglas:

• Score crediticio: Bueno (700+) o Malo (<700)
• Empleo: Empleado o Desempleado
• Deuda existente: Baja (<50% del ingreso) o Alta (>=50%)

Reglas:

• Buen crédito + Empleado + Deuda baja → Aprobar a tasa estándar
• Buen crédito + Empleado + Deuda alta → Aprobar a tasa mayor
• Buen crédito + Desempleado + Deuda baja → Revisión manual
• Buen crédito + Desempleado + Deuda alta → Rechazar
• Mal crédito + Empleado + Deuda baja → Aprobar a tasa mayor
• Mal crédito + Empleado + Deuda alta → Rechazar
• Mal crédito + Desempleado → Rechazar (sin importar la deuda)

Tarea: Construye la tabla de decisión. ¿Cuántos test cases se necesitan? ¿Se pueden simplificar algunas reglas?

Tips de Profesional #

• Comienza con la especificación. Cada “si/entonces” en los requerimientos se mapea a condiciones y acciones. Resáltalos.
• Valida con stakeholders. Las tablas de decisión hacen visibles las reglas de negocio. Revisa la tabla con product owners para detectar reglas faltantes o contradictorias.
• Cuidado con las acciones por defecto. ¿Qué pasa cuando ninguna regla coincide? La especificación podría no decirlo — eso es un defecto en la spec.
• Usa tablas de decisión para selección de tests de regresión. Cuando una regla de negocio cambia, las reglas afectadas en la tabla muestran exactamente qué test cases re-ejecutar.
• Combina con EP y BVA. Después de identificar combinaciones de reglas con la tabla de decisión, usa EP y BVA para seleccionar valores específicos para cada condición.