Por qué 10 comprobaciones en verde aún pasaron por alto fallos reales

Una comprobación aprobada es una afirmación, no un hecho. Ese es el argumento central de una nueva nota de phronesis.world, basada en un único día de auditoría en el propio sitio: 18–19 de julio de 2026. En ese periodo, el sitio estaba dando por error un libro de pago, su formulario de contacto estaba tirando cada consulta, su sitemap se rendereaba en blanco y una métrica llamada “coherence” medía en gran parte la longitud del texto. Cada uno de esos fallos ya había pasado una comprobación.

El texto cataloga 10 formas en que las comprobaciones permanecen en verde mientras lo que deberían verificar está roto. Algunas fueron fallos de herramientas evidentes: un script de verificación imprimió 12 líneas que decían BAD y aun así terminó con PASS porque la bandera de fallo se estableció dentro de un subshell y nunca llegó al resumen. Otras fueron más sutiles. Un verificador buscó href=“/courses” mientras el framework emitía href=“/courses/”; otro esperaba min=“0” mientras JSX producía min={0}. En cada caso, la prueba era válida para el sustrato equivocado.

Los ejemplos más contundentes de la nota provienen de comprobaciones orientadas a la capa equivocada. El sitemap se veía bien en la fuente y la consola no mostró errores, pero la página renderizada estuvo en blanco durante la mayor parte del día. Un error de parseo mató el script antes de que cualquier manejador pudiera reportarlo. El único instrumento que miraba la página tal como la vería un usuario fue la mirada humana, que detectó el problema tras cinco auditorías en verde.

Qué falló en la auditoría

El artículo también sostiene que fiabilidad no es validez. Una puntuación de “coherence” basada en la conectividad algebraica de un grafo de oraciones produjo números estables y reproducibles, pero en su mayor parte seguía la concisión: el mismo documento puntuó 0.39 cuando se truncó a ocho oraciones y 0.11 en su versión completa. Textos de muestra escritos a mano reforzaron la conclusión equivocada, mientras que una ejecución sobre 74 documentos de los propios artículos y módulos de curso del sitio la invirtió.

En otros casos, el propio diseño experimental borró el efecto que se medía. Tres diseños seguidos no detectaron un verdadero bucle de histéresis. El bucle solo apareció con un cuarto diseño que fue emparejado, con tasa igualada y absoluto.

Recomendado

La planta Ural patenta un pasador para turbinas que no se atasca en reparaciones

El texto destaca otro modo de fallo recurrente: sistemas que tratan el silencio como éxito. El formulario de contacto se enviaba a un worker que no existía desde hacía semanas. Cada fallo fue tragado por catch(()=>{}), así que el formulario parecía sano mientras cada envío fallaba.

Las soluciones que sí funcionaron

Según el autor, las técnicas que encontraron bugs fueron mucho más simples que el catálogo de modos de fallo:

• Plantear una pregunta distinta, en lugar de volver a ejecutar la misma auditoría
• Escribir aserciones a partir de la afirmación, no del comportamiento
• Usar evidencias anteriores a la pregunta
• Ejercitar el sistema de extremo a extremo en lugar de inspeccionar los registros
• Convertir cada clase de fallo descubierta en una comprobación permanente
• Verificar el artefacto de despliegue inmutable, no el alias en caché
• Preferir herramientas que fallen ante un patrón no detectado
• Mantener a una persona revisando la salida

Una de las secciones más afiladas aborda la deriva de la documentación. Una página afirmaba que un banco de acero y un banco de pino difieren en aproximadamente 9 °C en la piel, basándose en una tabla en el mismo archivo. La tabla cambió después, las pruebas siguieron en verde y solo la prosa se volvió falsa. La solución fue convertir las afirmaciones en aserciones explícitas, incluidas comprobaciones tales como “el acero y el pino están separados por ~9 °C”, “un banco de acero a 65 °C se quema” y “el corcho varía 6 °C con una oscilación de 75 °C mientras el acero varía 69”.

La conclusión del autor es contundente: verificar de nuevo vuelve a ejecutar el instrumento; verificar de forma distinta lo pone a prueba. Un resultado en verde solo significa algo si el instrumento podría haberse vuelto rojo, en la capa donde aparece la consecuencia en el mundo real, frente al artefacto exacto que cambió.