.png?width=138&height=45&name=Logo%20(5).png "Logotipo (5)"){kind=small}
Ya sea un despertador programado en tu smartphone o pedir comida a través de una aplicación, todo implica un código... ¡y a veces ese código se descontrola!
Los fallos de software pueden ser benignos, pero algunos han costado miles de millones, han provocado crisis importantes e incluso han puesto vidas en peligro.
Para los probadores, estos fracasos son lecciones valiosas que nunca deben olvidarse.
En este artículo exploramos algunos de los fracasos de software más importantes de la historia y las lecciones que se pueden extraer de ellos.
1. Ariane 5 (1996) - un bicho de 370 millones de dólares
El 4 de junio de 1996, en Kourou (Guayana Francesa), se lanzó por primera vez el cohete Ariane 5.
37 segundos después de despegar, se desvió de su trayectoria, se desintegró en pleno vuelo y explotó, causando la pérdida de equipos por valor de más de 370 millones de dólares, todo ello debido a un error de software.
El software de guiado utilizaba una parte de código reutilizado de la versión anterior, Ariane 4, y las condiciones de vuelo de Ariane 5 eran radicalmente diferentes.
Al convertir un número de coma flotante en un número entero, se producía una excepción no controlada que hacía que el sistema de navegación perdiera el control.
Además, el error se produjo en un módulo de software que ya no era necesario tras el despegue, pero que seguía activo.
Este fallo podría haberse detectado durante simulaciones realistas o una auditoría en profundidad del código. De hecho, era un fallo conocido, pero que se había considerado improbable.
La lección para los responsables de las pruebas:
Nunca se debe dar por sentado que un código antiguo es fiable simplemente porque antes funcionaba. Toda reutilización de código debe situarse en el contexto del nuevo sistema.
Las pruebas no solo consisten en validar la funcionalidad actual, sino también en evaluar la pertinencia y solidez del código heredado, especialmente en entornos de misión crítica.
2. El efecto 2000 (el año 2000)
A finales de los 90, un problema aparentemente sencillo adquirió proporciones mundiales: la gestión de fechas en los sistemas informáticos.
Durante décadas, para ahorrar memoria, los desarrolladores han codificado los años con sólo dos dígitos (por ejemplo, "99" para 1999).
Muchos temían que los ordenadores interpretaran el año 2000 como 1900, lo que provocaría errores masivos en los cálculos de fechas, los sistemas bancarios y los programas de navegación, por ejemplo.
Contrariamente al pánico generalizado, el 1 de enero de 2000 no fue un día de caos generalizado.
No hubo cortes de electricidad a gran escala, ni aviones en tierra, ni colapso de los sistemas bancarios. Sin embargo, esto no significa que el fallo se sobreestimara o que no tuviera consecuencias.
Se han invertido cientos de miles de millones de dólares en prevención, principalmente por parte de gobiernos, bancos, hospitales y compañías de seguros. Desde hace varios años se lleva a cabo una campaña mundial de actualización y comprobación de los sistemas informáticos.
Sin embargo, se han detectado varios fallos:
- Las tarjetas bancarias emitidas con fecha de caducidad "00" han sido rechazadas.
- El equipo de control nuclear de Japón se averió brevemente.
- Las máquinas expendedoras y los sistemas de venta de billetes interpretaron mal las fechas.
- Algunas aplicaciones informáticas mostraban el año "19100" debido a conversiones mal gestionadas.
Nada catastrófico, pero suficiente para demostrar que el riesgo era muy real.
La lección para los probadores:
Es crucial comprobar los casos límite relacionados con el tiempo y no hacer suposiciones implícitas en el código ("nunca llegaremos al año 2000").
También demuestra que las pruebas preventivas, aunque sean costosas e invisibles para el usuario final, pueden ser decisivas para evitar crisis colosales.
3. Heathrow Terminal 5 (2008) - caos logístico causado por el software
El 27 de marzo de 2008, el aeropuerto londinense de Heathrow inauguró su nueva Terminal 5, diseñada para revolucionar la experiencia de los pasajeros.
Desde el primer día, se perdieron decenas de miles de piezas de equipaje, se cancelaron o retrasaron vuelos y la imagen de British Airways quedó gravemente empañada, todo por culpa de un nuevo sistema automatizado de tratamiento de equipajes que no se había probado suficientemente en condiciones reales.
Los errores se debieron a una combinación de problemas de software, falta de coordinación entre los distintos sistemas (elevadores de equipaje, cintas transportadoras, escáneres, etc.) y escasa formación del personal.
En pocos días se perdieron más de 42.000 equipajes, con pérdidas estimadas en varias decenas de millones de euros.
La lección para los probadores:
Un sistema puede funcionar perfectamente en un entorno de pruebas, pero fallar en producción.
Por tanto, las pruebas deben incluir escenarios complejos y multisistema y tener en cuenta el comportamiento humano.
4. Knight Capital (2012) - 440 millones de pérdidas en 45 minutos.
El 1 de agosto de 2012, Knight Capital, empresa estadounidense especializada en negociación de alta frecuencia, puso en marcha un nuevo software de negociación en los mercados financieros.
Menos de una hora después, la empresa perdió más de 440 millones de dólares.
Una antigua función de prueba, que se suponía desactivada, seguía activa en algunos servidores.
El programa enviaba automáticamente órdenes de compra y venta masivas e incoherentes sobre cientos de acciones. El sistema fue incapaz de detectar la anomalía porque no se había puesto en marcha ningún mecanismo de reversión o supervisión en tiempo real.
La empresa intentó limitar los daños, pero el daño estaba hecho. El fallo provocó una volatilidad inusitada en el mercado, arruinó literalmente a Knight Capital y la empresa fue comprada unos meses después.
Esto se debió a un error de despliegue y a la ausencia de pruebas de validación posteriores al lanzamiento. No se realizaron pruebas reales en todos los servidores y no se informó a tiempo de los errores.
La lección para los probadores:
Las pruebas deben incluir la propia fase de despliegue, no sólo las funcionalidades. Es esencial validar que todos los entornos sean coherentes, que las funcionalidades antiguas estén desactivadas y que las herramientas de supervisión estén activas.
Un error de configuración puede tener a veces tanto impacto como un fallo funcional, y la más mínima desviación puede provocar un desastroso efecto dominó.
5. Actualización de Windows 10 (2018): eliminación de archivos de usuario
En octubre de 2018, Microsoft lanzó una actualización de Windows 10 que supuestamente mejoraba la estabilidad del sistema.
Pocos días después de su despliegue, miles de usuarios informaron de un fallo especialmente grave. La actualización borraba archivos personales de la carpeta "Documentos", sin previo aviso ni posibilidad de recuperación.
Sin embargo, este fallo había sido notificado por los probadores varias semanas antes del lanzamiento oficial. Obviamente, los comentarios no se tuvieron en cuenta a tiempo y no se aplicaron medidas correctoras.
El problema surgió de un conflicto entre la herramienta de redirección de carpetas (Redirección de carpetas conocidas) y la gestión de duplicados, un caso conocido, pero mal gestionado durante las pruebas.
Microsoft suspenderá temporalmente la actualización y publicará un parche, pero el daño ya está hecho y la confianza de los usuarios se está resintiendo.
La lección para los probadores:
No basta con probar casos "normales". Los casos específicos, las configuraciones personalizadas y los comentarios de los usuarios deben formar parte integrante del ciclo de pruebas.
Un buen proceso de control de calidad también debe ser capaz de escuchar y reaccionar con rapidez.
¿Qué deben recordar los probadores de hoy?
1. La prueba no se detiene en "funciona como se espera".
Un programa puede hacer lo que se le pide, pero puede hacerlo mal en la vida real. El papel del probador también consiste en imaginar qué podría salir mal.
2. Probar significa anticipar lo improbable
Que un caso sea improbable no significa que no merezca ser probado. El impacto potencial debe guiar las prioridades de las pruebas tanto como la frecuencia.
3. La comunicación es un arma antibichos
La mayoría de los errores importantes son el resultado de una falta de comunicación entre equipos, entre desarrolladores y probadores, o entre la empresa y sus usuarios.
4. Las herramientas de automatización no sustituyen a la intuición humana
Herramientas como Mr Suricate permiten automatizar escenarios de prueba sin código de una forma muy potente. Por otro lado, la curiosidad del probador y su capacidad para formular las preguntas adecuadas siguen siendo insustituibles.
5. Documentar para no repetir errores
Cada fallo descubierto es una oportunidad de aprendizaje. Documentar las causas, repercusiones y soluciones contribuye a elevar el nivel general de calidad en la empresa.
Probar también significa aprender del fracaso
En Mr Suricate, vemos cada día hasta qué punto la automatización de las pruebas sin código permite a los equipos de desarrollo anticipar, detectar y corregir errores con mayor rapidez.
Como dijo Benjamin Franklin: "Un penique ahorrado es un penique ganado". Teniendo esto en cuenta, las pruebas de control de calidad son un componente esencial del retorno de la inversión de una empresa.
👉 Ver el artículo - ROI y automatización de pruebas: ¿qué ahorro y generación de ingresos?
Si desea calcular su propio ROI y medir el impacto de la automatización en sus proyectos, podemos ofrecerle un presupuesto gratuito.
