Siempre que hay un problema se tiende a echar la culpa al sistema informático. Somos culpables de los retrasos de vuelos y las colas en los aeropuertos, de los problemas en los pagos de ayudas por la COVID y un sinfín de otros desastres. Desastres que en muchos casos son atribuibles, como mínimo en parte, a nuestros queridos usuarios.

Aunque, hay que reconocer a veces sí que realmente la culpa es nuestra. Pero no os voy a aburrir con otro post que os cuente la importancia de testear el software. Seguro que ya os pasáis el día escribiendo tests unitarios para asegurar que todas vuestras funcionalidades están cubiertas con sus pruebas correspondientes (¿verdad?).

Hoy os vengo a decir que da igual lo concienzudos que seáis con vuestros tests. No serán suficientes. Ya se sabe que las pruebas de software sirven para detectar errores, no para demostrar que no hay. Y para que aceptéis esta gran verdad con resignación, os traigo esta lista de errores extraños. Si no podéis leerlos todos, os recomiendo el de los emails que no se enviaban si el receptor estaba a más de 500 millas (¿un email que tiene limitaciones físicas?) o el del juego que hacía que una Xbox específica dejara de funcionar (ejemplo del típico en mi máquina funciona). Hay también otras colecciones de bugs curiosos.

Que quede claro, más tests es mejor que menos tests pero vigilad con el exceso de confianza. Que nadie se piense que por tener muchos tests está a salvo (y además que el tema de muchos es relativo, tiene que ser diversos y cubrir el máximo número de casos posibles).

El segundo mensaje del post es que si os fijáis bien, los errores más difíciles suelen mezclar combinaciones de software y hardware, no són “simples” errores en el código. Y hoy en día, casi todos los sistemas software incluyen elementos hardware (IoT, Industria 4.0, domótica, robots…). Así que cada vez más un programador, un ingeniero software tiene que ser multidisciplinar (lo que a veces llamamos un t-shaped developer) y ser capaz de trabajar con gente de otras disciplinas. Aspectos que, en mi opinión, no se tratan suficientemente en las carreras de informática. Y ya ni hablo de todas estas academias y bootcamps tan populares que tienden a crear profesionales superespecializados.

Y ya ni os explico cuando además el sistema incluye componentes IA que, al ser componentes de caja negra (es decir, que realmente no podemos ver como funcionan internamente), aún complican más el testing del sistema. De hecho, en un proyecto de juguete que hice, descubrí que los tests pasaban sólo a veces. Sin tocar nada, simplemente ejecutando los tests varias veces seguidas obtenía resultados diferentes. Hasta que me di cuenta que la red neuronal que utilizaba, como era de juguete y tenía pocos datos de entrenamiento, clasificaba normalmente bien pero no siempre, dependiendo de cómo se inicializaban aleatoriamente los pesos de los nodos de la red.

Resumiendo, disfrutad de las historias de errores sorprendentes y aprended de ellas. Y si habéis sufrido algún bug de estos “fantasma” que os vuelven locos, ¡compartidlo con nosotros!