Cuando el sistema miente: cómo se caza un bug de inventario

Hay una categoría de falla que no se resuelve leyendo código: el sistema entrega un número incorrecto, nadie sabe cuándo empezó y no se puede reproducir a voluntad. En una bodega eso significa que el inventario del sistema y el de la estantería dejaron de coincidir — y a partir de ahí todo lo que se decida encima está mal.

Primero reproducir, después opinar

La tentación es abrir el código y buscar al culpable a ojo. Es la vía rápida al arreglo equivocado: se corrige algo que parecía sospechoso, el síntoma desaparece por un tiempo y vuelve semanas después. Mientras el fallo no se pueda provocar a pedido, no está encontrado — solo está escondido.

Qué significa aislar la causa raíz

• Reproducir el fallo en un ambiente controlado, con datos representativos y sin tocar producción.
• Reducir el escenario hasta el mínimo que todavía falla: sobra todo lo que se puede quitar sin que el error desaparezca.
• Demostrar el mecanismo — qué operación, en qué orden y bajo qué condición produce el número de más.

El arreglo se verifica contra lo que falló

Un fix probado solo contra el caso feliz es una apuesta. La verificación tiene que correr contra el escenario completo que provocaba el error, y quedar registrada: qué se probó, qué se descartó y por qué. Ese informe es lo que permite responder una auditoría después, y lo que evita que el mismo error vuelva por otra puerta.

Si no puedes provocar el error cuando quieres, no encontraste la causa: encontraste una coincidencia.