Idea principal

Cuando un control lo aplica únicamente la interfaz — un tope de descuento comprobado en el formulario de entrada y en ningún otro sitio —, solo caben dos lecturas, y las dos son anomalías.

O bien es una regla de negocio de verdad, mal colocada: debería vivir donde viven las reglas, y su presencia en la pantalla es un defecto de diseño que arbitrar. O bien es sorteable — mediante una importación de fichero, mediante la interfaz que el producto expone a los desarrolladores externos — y entonces es un defecto con implicaciones de seguridad: lo que la pantalla prohíbe, otro camino lo permite.

El caso inverso se trata de la misma manera. Una regla aplicada por el núcleo del código que la pantalla no refleja produce un rechazo incomprensible: el usuario ve su acción rechazada sin ver qué ha hecho mal.

Por qué es importante

Convierte la lectura de las pantallas — habitualmente relegada al final del recorrido, cuando se hace — en una máquina de encontrar anomalías. El rendimiento es alto porque la pregunta no exige ningún juicio: basta con constatar que una regla no tiene gemela del lado del servidor.

También aporta un argumento para no saltarse esa lectura cuando falta tiempo: es la parte del producto que más rinde por hora invertida.

Matices y límites

"Casi siempre": una ayuda a la entrada de datos que no tiene alcance de negocio alguno — un formato de fecha propuesto, un campo oculto para aligerar la pantalla — no es una regla y no se convierte en anomalía.

Sortear la regla supone que haya otro camino realmente abierto. En un producto sin importación ni interfaz externa, el primer caso — la regla de negocio mal colocada — queda como único candidato.

Preguntas abiertas

• Una vez subida la regla al lado del servidor, ¿qué pasa con el control de entrada: duplicación asumida por comodidad, o fuente de divergencia futura?