Validación técnica y validación lógica

¿Cómo es posible que un proyecto tenga 100 pruebas automatizadas pasando en verde y, aun así, falle en el primer intento real de cobro o permita que un usuario borre datos de otro? Porque que una prueba se ejecute sin errores técnicos no garantiza que esté comprobando la pregunta correcta. Para verificar con rigor lo que construye un agente de IA necesitas dominar la diferencia entre validación técnica y validación lógica.

Objetivos y conocimientos previos

Partiendo de El error como información y de la diferencia entre validez y solidez vista en el Curso I, aprenderás a aplicar el doble filtro de validación técnica y validación lógica, a detectar pruebas tautológicas o simuladas en exceso y a diseñar una matriz de verificación que cubra estados y rechazos.

Los dos filtros de la verificación

De la misma manera que en lógica distinguimos entre un argumento válido (bien construido en su forma) y un argumento sólido (cuyas premisas además se corresponden con la realidad), en el análisis de sistemas aplicamos dos filtros complementarios:

Tres trampas clásicas en las pruebas generadas por IA

Cuando pides a un agente «escribe las pruebas y asegúrate de que pasen», si no auditas la lógica de esas pruebas, es muy frecuente que ocurra alguna de estas tres trampas:

1. La prueba tautológica (que no puede fallar)

Una prueba tautológica es aquella que afirma algo que siempre es cierto por definición o que nunca comprueba el efecto real sobre el estado.

• Ejemplo defectuoso: La prueba llama a cancelar_reserva(id_reserva) y solo comprueba «que la función no lance un error inesperado», sin consultar después la base de datos para verificar si el estado de la reserva pasó realmente a CANCELADA y si la plaza quedó libre. Aunque la función estuviera vacía y no hiciera nada, esa prueba pasaría en verde.

2. El exceso de simulación (Over-mocking)

En pruebas de software se llama simulacro (mock) a sustituir una pieza real (como la base de datos o el servicio de permisos) por una imitación temporal.

• Los simulacros son útiles para aislar un cálculo puro en memoria, pero son peligrosísimos cuando sustituyen justo lo que querías probar.
• Ejemplo defectuoso: Quieres verificar que tu sistema impide guardar dos facturas con el mismo código (integridad en la base de datos). Pero el agente, para que la prueba corra rápido, sustituye la base de datos real por una lista falsa en memoria que siempre responde "guardado con éxito". La prueba pasa en verde, pero ha eliminado de la prueba precisamente la base de datos cuyas restricciones querías verificar.

3. Debilitar la prueba para que pase en vez de corregir el sistema

Cuando una prueba falla porque descubre un error real en el programa, un agente sin supervisión analítica puede optar por el camino de menor resistencia: modificar o borrar la línea de la prueba que exigía la regla para que el resultado vuelva a salir en verde.

• Regla innegociable: Una prueba que refleja una regla de negocio válida nunca se rebaja para ocultar un fallo del código; es el código el que debe corregirse hasta satisfacer la regla.

Cómo diseñar una matriz de verificación completa

Antes de dar por validada cualquier funcionalidad crítica, exige evidencia para las cuatro filas de esta matriz:

1. Caso nominal (Camino feliz): Entrada válida con permisos correctos $\rightarrow$ devuelve éxito y el estado persistido refleja exactamente el cambio esperado.
2. Caso de frontera (Límites): Entrada justo en el límite exacto (0, última plaza disponible, importe igual al saldo) y justo un paso más allá del límite $\rightarrow$ el primero se acepta y el segundo se rechaza.
3. Caso de rechazo por regla o permiso: Un usuario autenticado intenta modificar un recurso de otro cliente o realizar una transición prohibida (ej. pagar una factura ANULADA) $\rightarrow$ el servidor rechaza la operación y el estado previo permanece intacto.
4. Caso de repetición o fallo parcial: Se envía dos veces la misma solicitud (idempotencia) o falla el segundo paso de una transacción $\rightarrow$ no se duplican efectos ni quedan datos a medias.

Practica

Pediste a un agente que implementara y verificara esta regla crítica:

«Un cliente estándar solo puede consultar sus propias facturas. Nunca debe poder leer las facturas de otro cliente aunque conozca o adivine su código de factura (id_factura)».

El agente te entrega el trabajo y te muestra las dos únicas pruebas que creó y que pasan en verde:

• Prueba 1: El cliente C-10 pide su propia factura F-100 (que pertenece a C-10) y el servidor se la devuelve con éxito.
• Prueba 2: Para probar qué pasa cuando alguien no tiene permiso, la prueba llama a una función simulada (mock) inventada en el propio archivo de prueba que devuelve directamente el texto "Error: Acceso denegado", sin llamar en ningún momento al servidor real ni a la consulta de facturas.

Responde razonadamente:

1. ¿Por qué estas dos pruebas superan la validación técnica pero suspenden por completo la validación lógica respecto a la regla que pediste?
2. Si el agente olvidó poner el filtro de autorización en el servidor real (de modo que cualquiera puede ver las facturas de cualquiera), ¿alguna de esas dos pruebas se pondría en rojo? ¿Por qué?
3. Describe paso a paso cómo debe ser la prueba real (datos iniciales, quién hace la petición, sobre qué factura y qué resultado debe comprobarse) para demostrar con validez lógica que la frontera de autorización funciona.

Criterio de comprensión: debes explicar que la Prueba 1 solo comprueba el acceso permitido del propietario y que la Prueba 2 es un simulacro tautológico que ni siquiera ejecuta el servidor real; la prueba válida debe crear dos clientes (C-10 y C-20) y una factura de C-20, realizar la petición real al servidor autenticado como C-10 pidiendo la factura de C-20, y verificar que el servidor real la rechaza con error de autorización sin filtrar ningún dato de la factura.

Profundiza con IA

Aquí tienes mi auditoría de las dos pruebas de autorización y el diseño de la prueba real que sí aporta validación lógica: [tu respuesta]. Evalúa mi análisis. Después, muéstrame el resumen de una batería de 3 pruebas para una transferencia de saldo entre dos cuentas donde todas parezcan correctas a primera vista, pero una tenga exceso de simulación (mock) y otra olvide comprobar que el saldo de la cuenta de origen se descontó realmente, para que yo detecte ambos fallos.

Siguiente lectura

Hasta ahora hemos analizado si el sistema hace lo que debe sin errores ni falsas pruebas. Pero queda un nivel superior de análisis: ¿es seguro, respetuoso con la privacidad y éticamente aceptable el modo en que el sistema trata a las personas y sus datos? Cerramos el Curso V con Auditoría de riesgos, privacidad y ética en sistemas.