Especificación, invariantes y análisis de casos límite

¿Por qué la mayoría de los errores en producción ocurren exactamente en el número cero, en el último asiento disponible o cuando dos acciones llegan en distinto orden al previsto? Porque las reglas suelen escribirse pensando en los valores intermedios habituales y dejando en penumbra las fronteras del dominio. Analizar casos límite consiste en iluminar esas fronteras antes de que un usuario real tropiece con ellas.

Objetivos y conocimientos previos

Partiendo de Pensamiento analítico y de las invariantes estudiadas en De la lógica al algoritmo, aprenderás a auditar cualquier requisito mediante una matriz sistemática de casos límite, a detectar contradicciones entre reglas de negocio y a verificar la conservación de invariantes.

Qué es un caso límite (edge case) y un valor frontera

Un caso límite es una situación que se sitúa justo en el borde de lo que las reglas del dominio permiten, o donde coinciden varias condiciones extremas a la vez.

No es un suceso mágico ni imprevisible: siempre se puede deducir analizando los tipos de datos, las cantidades, el tiempo y las transiciones de estado del problema.

Las cinco familias universales de casos límite

Cuando analices cualquier especificación o audites lo que construyó un agente, revisa sistemáticamente estas cinco dimensiones:

Dimensión analítica	Preguntas que debes hacer al modelo	Ejemplo en un sistema de reservas y facturación
1. Cantidades y fronteras numéricas	¿Qué ocurre en el `0`, en `1`, en el máximo exacto (`N`), en `N + 1` y con números negativos o decimales?	Una actividad tiene 20 plazas: ¿qué pasa al reservar cuando quedan `1` plaza (pasa a `0`, llena), cuando quedan `0` plazas, o si alguien envía `cantidad_plazas = 0` o `-2`?
2. Ausencia, vacío y duplicidad	¿Qué ocurre si un dato opcional no viene, si una lista tiene `0` elementos, o si un elemento válido viene repetido?	¿Se puede emitir una factura con `0` líneas de detalle? ¿Qué pasa si en una misma solicitud incluyen dos veces el mismo concepto o código?
3. Tiempo y vigencia	¿Qué ocurre justo en el instante de vencimiento, con fechas invertidas o en cambios de día/mes/zona horaria?	Una suscripción vence el `2026-10-31`: ¿durante ese día sigue activa o ya caducó? ¿Qué ocurre si una actividad empieza a las `18:00` y alguien intenta cancelar a las `18:05`?
4. Orden y secuencia de estados	¿Qué ocurre si los eventos llegan en un orden distinto al habitual o si el mismo evento llega dos veces?	¿Qué pasa si la confirmación de pago del banco llega un segundo después de que el pedido expirara por tiempo, o si el usuario pide reembolsar una factura que aún está `PENDIENTE`?
5. Concurrencia y colisión	¿Qué ocurre si dos actores intentan modificar la misma entidad o consumir el último recurso al mismo tiempo?	Dos clientes intentan canjear simultáneamente un cupón de un solo uso, o el administrador anula una actividad en el mismo segundo en que un usuario confirma su plaza.

Análisis de fronteras: por qué un solo signo cambia la regla

Observa este requisito aparente:

«El envío es gratuito para pedidos a partir de 50 €; para pedidos menores de 50 € cuesta 5 €».

Si un programador o un agente traduce descuidadamente esa frase en dos condiciones separadas:

SI importe > 50 ENTONCES envio = 0
SI importe < 50 ENTONCES envio = 5

¿Qué ocurrirá cuando un cliente haga un pedido de exactamente 50,00 €? No cumplirá ni > 50 ni < 50: el valor frontera 50 ha quedado en un vacío lógico.

Por eso, siempre que analices un límite numérico o temporal (como 50 €, 10 plazas o 24 horas), debes comprobar explícitamente la terna de frontera:

El valor inmediatamente anterior al límite (49,99 € o 9 plazas).
El valor exacto del límite (50,00 € o 10 plazas).
El valor inmediatamente posterior al límite (50,01 € o 11 plazas).

Detectar contradicciones entre reglas de negocio

En los sistemas reales, los problemas más difíciles no vienen de una sola regla aislada, sino de dos reglas que parecen razonables por separado pero chocan entre sí cuando coinciden en un mismo caso.

Analicemos estas dos reglas que el responsable de un producto te pide implementar:

Regla A: «Los clientes con suscripción VIP tienen siempre un 20 % de descuento en todas sus facturas».
Regla B: «Durante la campaña de otoño, cualquier cliente puede aplicar un cupón de descuento de 30 %, pero ningún descuento total en el sistema puede superar el 35 % del importe base».

Si las lees por separado parecen claras. Pero el pensamiento analítico cruza ambas reglas y pregunta inmediatamente: ¿Qué ocurre cuando una clienta VIP (20 %) introduce además el cupón de otoño (30 %)?

¿Los descuentos se suman (20 % + 30 % = 50 %) y luego se recortan al tope del 35 %?
¿Son incompatibles y solo se aplica el mayor de los dos (30 %)?
¿Se aplica primero el 20 % y sobre el resultado restante el 30 %?

Si no detectas esa colisión durante el análisis y dejas el requisito así, el agente elegirá una de las tres interpretaciones al azar en el código sin que tú lo sepas.

Proceso analítico para auditar una especificación antes de implementar

1. Listar todas las entidades, estados e invariantes que nunca deben romperse
2. Probar cada límite con su terna de frontera (anterior, exacto y posterior)
3. Cruzar las reglas entre sí para detectar solapamientos o contradicciones
4. Convertir cada ambigüedad descubierta en una regla determinista y un caso de prueba

Practica

Vas a analizar la especificación de una nueva regla para el sistema de reservas de actividades:

Requisito inicial: «Un socio puede cancelar su reserva sin coste si lo hace con más de 24 horas de antelación respecto al inicio de la actividad. Si cancela con menos de 24 horas de antelación, se le cobra una penalización del 50 % del precio de la actividad. Los socios con tarifa Plena tienen actividades gratuitas (precio 0 €)».

Análisis de frontera temporal: ¿Qué pasa si la actividad empieza el sábado a las 10:00 y el socio cancela el viernes a las 10:00:00 exactas (justo a las 24 horas)? ¿Por qué la redacción «más de 24 horas» y «menos de 24 horas» deja un hueco lógico y cómo la reescribirías sin ambigüedad?
Análisis de secuencias y estados (Dimensión 4): ¿Qué pasa si el socio intenta cancelar una reserva cuando la actividad ya terminó hace dos días, o si intenta cancelar por segunda vez una reserva que ya estaba en estado CANCELADA?
Cruce de reglas y cantidades: ¿Qué ocurre cuando un socio con tarifa Plena (cuya actividad costó 0 €) cancela a falta de 2 horas, o si ha sido el propio organizador quien canceló la actividad por lluvia a falta de 3 horas?

Criterio de comprensión: debes identificar el hueco exacto en t = 24 h (usando >= 24 h frente a < 24 h), exigir que solo reservas en estado ACTIVA y con fecha futura admitan cancelación del socio (evitando penalizar dos veces o cancelar actividades pasadas), y distinguir la cancelación iniciada por el socio de la anulación de la actividad por parte del organizador.

Profundiza con IA

Aquí tienes mi análisis de fronteras, estados y cruce de reglas para la política de cancelación de reservas: [tu respuesta]. Revisa si he cubierto todas las ambigüedades. Después, actúa como responsable de producto y propónme una regla de reembolsos parciales en facturas que contenga a propósito un hueco en un valor frontera y una contradicción entre dos condiciones para que yo los encuentre.

Siguiente lectura

Incluso tras analizar con cuidado los requisitos y casos límite, al construir o ejecutar un sistema real pueden surgir fallos inesperados. Cuando eso ocurre, ¿cómo investigamos la causa raíz sin dar palos de ciego? Continúa con El error como información: diagnóstico y abducción.