La historia de cuando la NASA perdió una nave por no tener QA

Admito que el título tiene su punto de clickbait. No sé si en 1999 había un “QA” como tal en la NASA, pero la anécdota sirve para explicar muy bien lo que pasa cuando se dan cosas por sentado y los equipos no están alineados. Pido perdón por adelantado, pero espero que la lectura merezca la pena.

Lo que sí es verdad es que el caso se extrapola fácil a nuestro día a día en QA. Por ejemplo, a un escenario muy común: integrar dos sistemas de software.

En 1999, la NASA perdió la Mars Climate Orbiter por una desalineación de libro. El contratista generaba datos de impulso de los propulsores en libras-fuerza·segundo (lbf·s) y el equipo de navegación los consumía como si fueran newton·segundo (N·s), justo lo contrario de lo que exigía la especificación. Esa diferencia mete un factor 4,45 en los cálculos y, acumulada durante el crucero, dejó la trayectoria aproximadamente 170 km más baja de lo previsto al llegar a Marte. Resultado: la sonda ardió en la atmósfera o rebotó al espacio. No fue mala suerte: fue una interfaz de datos mal definida.

¿Y el dinero? La pérdida fue estimada oficialmente en 125 millones de dólares equivalentes a 330 millones de euros actuales si ajustamos inflación y costes asociados al desastre. Son “muchos ceros” para una conversión de unidades mal alineada.

Lo más humano del asunto: hubo señales. En primavera del 99, el equipo de navegación detectó anomalías y las discutió por e-mail, pero no se elevó un informe formal de incidencia (el proceso ISA: Incident/Surprise/Anomaly). La investigación también señaló comunicaciones pobres, validación insuficiente del software de tierra y un TCM (maniobra de corrección) que nunca se ejecutó. Vamos, que no faltó inteligencia; faltó disciplina de interfaz y de proceso.

Muchas veces en QA vemos avisos que se subestiman: se escalan riesgos, se archivan esperando que no pase nada y se prioriza no retrasar la release. A la NASA esa apuesta le costó una nave espacial.

De la estación espacial a la oficina

Imagina que estás en un proyecto de integración entre sistemas. El sistema origen envía un payload, que quizá pasa por un middleware, y el sistema destino lo traga “como puede”. En el kick-off todos asentimos: sí, sí, está claro. Pero nadie ha dejado por escrito formato, unidad, longitudes ni reglas de transformación y error de cada campo. Ahí es donde la órbita empieza a torcerse: cada equipo “traduce” a su manera, el desvío se acumula y la nave puede estrellarse.

Ejemplo clásico: fechas y zonas horarias.

Un sistema envía 01/04/2025 pensando en 1 de abril; el otro lo lee como 4 de enero. Añade UTC vs. hora local y ya tienes informes desfasados, caducidades mal calculadas y procesos disparándose cuando no toca. La vacuna es tan poco épica como infalible: ISO 8601 en el intercambio (2025-04-01), UTC como referencia y reglas de conversión bien definidas (y probadas) en los bordes. Dependiendo del negocio, cuatro meses de desfase pueden ser un susto… o millones.

Moraleja

No subestimes lo básico. Lo obvio no se sobreentiende: unidades, formatos, longitudes, zona horaria y reglas de error. Escríbelo, ciérralo y pruébalo. Cuando damos por supuesto lo básico, lo caro llega sin avisar. Si a la NASA le pasó por las unidades, nadie está a salvo de meter la pata por algo simple.