Probar reglas de decisión: tablas de decisión, MC/DC y cobertura
Cómo probar una regla de decisión: tablas de decisión, casos de prueba a partir de una tabla de verdad, MC/DC con los pares de independencia del motor, cobertura de condición frente a cobertura de decisión, pruebas de mutación y los patrones detrás de las reglas de elegibilidad, control de acceso y feature flags.
Una regla booleana con cinco entradas tiene 32 casos; nadie prueba los 32, y nadie debería tener que hacerlo. Estas páginas muestran las técnicas que eligen los pocos casos que importan y dicen qué puede y qué no puede prometer cada técnica. Las tablas de decisión (la técnica del nivel Foundation de ISTQB) condensan la tabla en reglas. MC/DC, el criterio que debe cumplir el software aeroespacial, pide por cada entrada un par de casos que difieran solo en esa entrada y cambien el resultado; el motor calcula esos pares. Las pruebas de mutación preguntan si tus pruebas notarían un operador cambiado.
Cada ejemplo de estas páginas es una regla real calculada por el motor: la regla de descuento, la de envío gratuito, la de entrada, el enclavamiento de máquina, la regla del préstamo. Las páginas de MC/DC muestran los pares que el motor encontró para cada entrada, o indican que no existe ninguno y por qué.
Las páginas de patrones son para analistas: cómo suelen estar formadas las reglas de elegibilidad, control de acceso y feature flags, las excepciones que suelen olvidarse y las pruebas que las detectan.
- Tabla de decisión frente a tabla de verdad: cuándo usar cada una
Una tabla de verdad enumera todas las combinaciones de las entradas de una regla con la salida en cada fila. Una tabla de decisión agrupa esas filas en reglas de negocio con condiciones y acciones. - Prueba con tabla de decisión, ejemplo resuelto (estilo ISTQB Foundation 4.2.3)
Un diseño de pruebas con tabla de decisión resuelto al estilo de la sección del temario ISTQB Foundation sobre pruebas con tablas de decisión: tres condiciones, una regla de envío gratuito, ocho… - MC/DC explicado: cobertura de condición/decisión modificada para reglas booleanas
La cobertura de condición/decisión modificada pide, para cada condición de una regla booleana, un par de casos de prueba que difieran solo en esa condición y produzcan resultados distintos. - Pares de independencia MC/DC, ejemplo resuelto con el informe de cobertura del motor
Un par de independencia para una condición son dos escenarios que difieren solo en esa condición y dan resultados distintos. - MC/DC frente a cobertura de condición y cobertura de condición múltiple
La cobertura de condición pasa cada condición por sus dos valores. La cobertura de condición múltiple pasa por todas las combinaciones. - Cobertura de condición frente a cobertura de decisión (ramas)
La cobertura de decisión pide que el resultado de la regla sea VERDADERO en alguna prueba y FALSO en otra. La cobertura de condición pide lo mismo de cada condición. - Derivar casos de prueba de una tabla de verdad sin probar todas las filas
Una tabla de verdad es una lista completa de entradas de prueba con resultados esperados; la cuestión es qué filas conservar. - Pruebas de mutación para reglas booleanas: mutantes de operador, negación y literal
Las pruebas de mutación plantan pequeños errores deliberados en una regla, como cambiar un operador, eliminar una negación o sustituir un literal, y preguntan si el conjunto de pruebas lo nota. - Pruebas de regresión para reglas de decisión que cambian
Cuando una regla cambia, la cuestión es qué filas cambiaron con ella. - Escribir reglas de negocio en lenguaje claro que se traduzcan a lógica
Una regla de negocio escrita en lenguaje claro debería traducirse a una sola fórmula booleana sin necesidad de un comité. - Reglas de elegibilidad: el patrón, las excepciones habituales y las pruebas
Las reglas de elegibilidad comparten una forma: un grupo que cumple, un motivo de exclusión y un segundo requisito. - Reglas de control de acceso: roles, excepciones y el error del usuario vetado
Las reglas de acceso combinan roles que conceden, roles que conceden con condiciones, y un bloqueo o veto que tiene prioridad. owner OR admin OR (editor AND NOT locked) es el patrón con cuatro… - Lógica de feature flags: combinar flags sin sorpresas
Los feature flags combinan una audiencia, un interruptor maestro y un interruptor de emergencia, y las sorpresas vienen de cómo se combinan. - Lista de revisión de reglas de decisión (para analistas y revisores)
Una lista de revisión para una regla de decisión antes de ponerla en producción, escrita para analistas y revisores más que para programadores. - Convertir un contraejemplo en una prueba de regresión
Un contraejemplo es una asignación completa en la que dos cosas que deberían coincidir no coinciden. Esa es también la definición de una buena prueba de regresión.
Preguntas
¿La app calcula la cobertura MC/DC?
El informe de cobertura de la app mide la cobertura de valores de entrada, de salida de compuertas, de resultado de decisión y de influencia de entradas con denominadores publicados, y sugiere pares de independencia para las entradas cuya influencia tus pruebas no han mostrado. Las páginas de aquí usan ese mismo cálculo. La app no certifica el cumplimiento de MC/DC; te da los pares y el informe.
¿La cobertura equivale a la corrección?
No, y las páginas lo dicen a cada paso. Un conjunto de pruebas con cobertura total y valores esperados equivocados hace pasar una regla equivocada. Los valores esperados deben venir del requisito, no de la fórmula.
Generado a partir del motor de Tangibool, semántica tangibool-semantics/1, motor 1.0.0, compilación . Cada tabla, mapa, simplificación y veredicto de estas páginas lo calculó el motor de Tangibool al compilar el sitio, y cada afirmación la volvió a comprobar el mismo verificador exacto que usa la app. Los límites se indican donde aplican. © 2026 Foreranger LTD.