¿Qué es un control positivo en verificación de software?

Una señal que el sistema tendría que producir obligatoriamente si el camino que se está investigando se hubiera recorrido: una línea de registro previa al envío, un identificador de lote, un intento de conexión. Sin ella, un registro vacío no distingue «no ocurrió» de «no llegué hasta ahí».

¿Por qué un cero o un silencio no bastan como prueba?

Porque tienen dos causas posibles con la misma salida: el hecho no ocurrió, o el mecanismo que lo detectaría no se ejecutó. Una prueba saltada, un contador que nunca se incrementa, un comando cuyo código de salida se traga una tubería y un panel que se dejó de alimentar producen exactamente el mismo resultado que la situación sana.

¿Por qué hay que volver a mirar después del primer éxito?

Porque se investiga cuando algo falla, y el comportamiento que interesa suele aparecer solo cuando el código nuevo corre entero. El primer verde es el momento más peligroso de una integración: es cuando por fin se ejecuta todo y nadie está mirando, porque ya se dio por resuelto.

¿Cómo se aplica esto al diseño de un monitor o un vigilante?

Haciendo que hable en cada ciclo aunque no encuentre nada: «revisadas 412 entradas, 0 infracciones» en vez de silencio. Un proceso que solo habla ante un problema es indistinguible de un proceso muerto, y el silencio se lee como buena señal. Lo mismo con una suite que informa «0 fallos» sin decir cuántas pruebas corrió: cero de cero es verde.

Dije que no salían datos. Al primer envío bueno, salieron dos

Me preguntaron si el sistema estaba enviando datos de pacientes a un organismo externo mientras la integración estaba a medio construir. Fui a mirar los registros de todas las corridas. Todas morían pronto: unas con un 415 porque el tipo de contenido no era el que el otro extremo esperaba, otras con un 500. En ninguna aparecía un envío.

Contesté que no salía nada.

La primera corrida que pasó del 500 mandó dos peticiones con datos clínicos reales.

Mi respuesta había sido falsa desde el principio, y lo peor es que era falsa de una manera que se sentía rigurosa: había mirado. Tenía pruebas. Las pruebas eran registros de ejecuciones reales, no suposiciones.

Un negativo no dice nada por sí solo

El error no fue leer mal los registros. Fue no darme cuenta de qué producía ese silencio.

Las corridas morían antes de llegar al código que envía. El registro no decía «no envié»; decía «no llegué a la parte que envía». Son dos afirmaciones distintas y producen exactamente la misma salida: nada.

Esa es la forma general del problema, y aparece en todas partes en cuanto se la busca:

Un contador en cero puede ser «no ocurrió» o «el contador no se incrementó nunca». Un «no encontrado» puede ser «no existe» o «busqué en el sitio equivocado». Una prueba en verde puede ser «pasó» o «se saltó sola». Un exit 0 puede ser «funcionó» o «el comando estaba estrangulado por una tubería que se tragó el código de salida». Un panel en silencio puede ser «todo va bien» o «el proceso que lo alimenta lleva tres semanas muerto».

En los cinco casos la evidencia es idéntica. Y en los cinco, la lectura optimista es la que da tranquilidad, así que es la que se elige sin pensarla.

El control positivo

La corrección no es desconfiar más. Es exigir una cosa concreta antes de aceptar cualquier negativo:

Busca algo que el registro TENGA que mostrar si el camino se recorrió de verdad.

Si el sistema hubiera llegado a la parte que envía, en el registro tendría que aparecer algo: la línea de «preparando la petición», el identificador del lote, el intento de conexión. Cualquier señal que sea imposible sin haber pasado por ahí.

Si esa señal no está, no has demostrado que no envía. Has demostrado que no sabes si envía. Y «no lo sé» es una respuesta perfectamente respetable; «no envía» era mentira.

Cuando existe ese testigo, el negativo pasa a valer, porque ahora sí distingue los dos mundos: llegó y no envió, contra no llegó.

Y hay que volver a mirar después del primer éxito

Esta es la segunda mitad, y en mi caso fue la cara.

Yo miré después de los fallos. Es lo natural: se investiga cuando algo va mal. Pero el comportamiento que me habían pedido comprobar solo aparecía cuando las cosas iban bien, y eso no llega hasta que alguien arregla el 415 y el 500.

Así que la regla completa lleva dos tiempos: comprueba que el camino se ejecutó, y vuelve a comprobar después de la primera ejecución exitosa, no solo después de las fallidas. El primer verde es el momento más peligroso de una integración, porque es cuando el código nuevo por fin corre entero y nadie está mirando: ya se dio por resuelto.

Todo vigilante que puede callar tiene que decir por qué calla

De ahí sale una consecuencia de diseño que cambia cómo escribo cualquier cosa que vigile.

Un proceso que solo habla cuando encuentra un problema es indistinguible de un proceso muerto. Los dos producen el mismo silencio, y el silencio es justo lo que interpretamos como «todo bien».

Así que un vigilante que puede callar legítimamente debe emitir en cada ciclo por qué calla: «revisadas 412 entradas, 0 infracciones» en vez de no decir nada. Cuesta una línea. Y convierte «sano y quieto» en algo que se ve distinto de «muerto», que es exactamente lo que el vigilante existe para distinguir.

Lo mismo con las pruebas: una suite que informa «0 fallos» sin decir cuántas pruebas corrió no ha dicho nada. Cero de cero es verde.

Lo que queda

Antes de afirmar que algo no pasa, comprueba que el código capaz de hacerlo llegó a ejecutarse. Si no puedes comprobarlo, la respuesta es «no se puede saber», no «no».
Busca el testigo: la señal que el registro tendría que mostrar si el camino se recorrió.
Vuelve a mirar después del primer éxito, no solo después de los fallos.
Lo que puede callar legítimamente debe decir por qué calla, en cada ciclo.

Ninguna de las cuatro cuesta dinero ni tiempo apreciable. La que me faltó a mí era la primera, y la factura fueron dos envíos con datos de pacientes que yo había certificado que no existían.