La historia tras el error de FaceTime y la mejora al reporte de fallos que necesita Apple

Como ya sabrán, hoy han saltado las alarmas por un fallo en las llamadas grupales de FaceTime que permitía (antes de descolgar) que el usuario que llamaba pudiera ver y oír el dispositivo al que llamaba sin su consentimiento. Un error de privacidad provocado por un fallo en la app que ha hecho que Apple reaccione deshabilitando el servicio e informando que prepara un parche de urgencia en breve.

Como es lógico, y siendo Apple, la gente ha empezado a inundar las redes sociales y comentarios completamente ofendida. De hecho ahora mismo es trending topic en Twitter. Es normal que pensemos que una empresa como Apple que defiende la privacidad a capa y espada, no debería tener fallos en su software directamente relacionados con ese tema. Y desde el primer momento quede clara mi opinión: estoy de acuerdo que es un error importante y que debería haber sido detectado y corregido mucho antes incluso de lanzar la funcionalidad al público.

Pero como en todo, siempre hay matices y ahora me voy a ir al otro lado de la barrera, me voy a vestir de desarrollador y voy a intentar explicar (sin justificar) desde el otro lado.

Y además, vamos a contar una historia detrás de este error que a mi, personalmente, sí me parece un fallo mucho más importante de Apple y que deberían arreglar: el cómo un chico de 14 años fue quien descubrió este error hace 10 días y le ha sido imposible contactar con Apple y que le tomen en serio hasta que los medios han hecho público el error.

Los fallos de software

Cuando un programa termina su fase de desarrollo, pasa a pruebas. Estas son automáticas y manuales. Y cuando hablamos de una compañía tan grande como Apple con tantos desarrollos, normalmente las pruebas son más automáticas que manuales.

Las pruebas automáticas también conocidas como tests unitarios, forman parte de una arquitectura de desarrollo llamada TDD o Test driven-development. Traducido algo así como "desarrollo conducido por las pruebas". En esencia, es la capacidad de crear un programa que puede probar la funcionalidad de otros programas. En el caso de Apple existen dos tipos: pruebas unitarias que verifican la funcionalidad de la app y pruebas de interfaz que verifican que estas estén correctas y bien definidas.

En el primero de los casos, las pruebas unitarias, imaginen que yo tengo una función que cuando es llamada debería devolver un resultado concreto que sé que es el correcto a nivel funcional. Llevándolo a lo más simple: tengo un función que coge dos números y me devuelve la suma de sus cuadrados.

Pues bien, como sé que esa función tiene que dar siempre tal y cual resultado, lo primero que hago es comprobar que la función puede fallar. Primero porque la creo vacía y creo un test que me verifica que falla (porque no está hecha la funcionalidad). Luego implemento el código y vuelvo a lanzar el test para verificar que ahora funciona. Estos son los pasos red (el test falla porque la función no está hecha) y green (el test funciona porque ahora la función sí está hecha).

Puedo completar el test cogiendo varios resultados correctos y complemento el test para que recalcule mis cálculos previos y verifique que sigue funcionando porque devuelve lo que tiene que devolver. Si luego hay algún cambio nuevo, entramos en la fase refactor donde volvemos a "estropear" la función y verificamos que el test falla (de nuevo red) para luego volver a implementar los cambios y así ciclicamente.

Como el desarrollo se supedita a crear las pruebas a la vez, por eso es "conducido por las pruebas". Estos test unitarios se lanzan durante el desarrollo y cuando se generan las versiones también se suelen ejecutar para comprobar que nada ha cambiado. Porque si alguien del equipo toca mi función y deja de devolver lo que tiene que devolver (funcionar como debe) saltará el error que ese test no ha pasado.

En el caso de las interfaces, podemos grabar secuencias de uso y comprobar estados. Por ejemplo: si pulso en una fila de una tabla debe llevarme a una pantalla llamada "Detalle" y al pulsar en atrás en "Detalle", debe volver a la pantalla principal llamada "Personas". Ese caso de uso se graba y el programa que ejecuta los tests puede reproducir esa funcionalidad manejando la app de forma automática y verificar que el flujo y las pantallas a las que navega son correctos. En caso que alguien cambiara el flujo, el test fallaría.

Estas son las formas, muy resumidas, en las que se prueban hoy día las apps de forma automática, Y como pueden ver tienen más una función de prevención ante estropear cosas que ya funcionan que en localizar comportamientos inadecuados de la app. La única forma de encontrar casos de uso incorrectos que provoquen fallos como el de FaceTime grupal, es hacer pruebas manuales. Que un probador de apps se ponga a intentar "reventar" la app forzando un mal uso a posta y jugando con su imaginación para ver cómo puede buscar un resquicio por donde encontrar un fallo.

Como pueden comprender, es sumamente difícil encontrar un fallo de esas características porque ni el probador más avispado tiene por qué pensar que haciendo tal o cual combinación puede llegarse a un fallo. A toro pasado, que se diría, es fácil pensar: "es que es un fallo muy tonto y podían haberlo probado". Pero a ninguno de nosotros se nos ocurrió (ni a nadie más en el mundo que sepamos) hasta hace 10 días que un joven de 14 años encontró este error e intentó reportarlo a Apple. Y ahí empieza la segunda parte de nuestra historia.

Cuando un joven encuentra un fallo, pero nadie le hace caso

Un fallo de software puede arreglarse si es descubierto y replicado. Todas las compañías, como Apple, llevan cometiendo errores en sus programas y sistemas desde que crearon la primera línea de código. Es algo inherente al desarrollo y como ya sabemos, es imposible solucionarlo. No por nada, ya hablamos hace poco cómo Apple había corregido nada menos que 31 fallos de seguridad importantes en la última versión iOS 12.1.3.

Por lo tanto queda claro que tal como es hoy día la estructura de los programas es absolutamente imposible crear un software carente de errores por muchas pruebas y prevenciones que intentemos aplicar. Son tantas las capas y posibles casos, que insisto, es imposible. Miren cómo todas las compañías están continuamente sacando parches de sus sistemas, aplicaciones y demás. Vivimos en un estado de beta sin fin, desde cierto punto de vista.

En Twitter descubrimos al usuario @MGT7500, que vive en Tucson (Arizona) que está reportando pruebas constatables con emails, tweets y vídeos, que demuestran que su hijo encontró este error de FaceTime hace 10 días y que le ha sido imposible informar de este error a Apple. Más en concreto, que lo tomen en serio y actúen.

Este tuit del día 21 de enero demuestra cómo ya se había reportado el error a Apple, los cuales cuando se quiso contactar con ellos contestaron diciendo que para informar de un error en el sistema, se debían dar de alta como desarrolladores en el portal de Apple (con cuenta gratuita). Una vez dados de alta, enviaron el informe pero Apple no hizo nada al respecto. Entró en un saco de informes de errores donde pueden recibir cientos al día y donde un equipo los intenta verificar uno a uno pero sin que ninguno tenga una etiqueta de: "urgente".

Como puede verse en el tweet bajo estas líneas, el padre del joven de 14 años intentó que alguien en Apple se saltara la burocracia y le pusieran en contacto con un supervisor aportando pruebas que este era un fallo muy gordo del sistema. Pero nadie le hizo caso ni consiguió sortear en forma alguna los canales oficiales para que le dieran mayor prioridad a su caso.

¿Qué ha pasado al final? Pues ni siquiera un medio como Fox, al que referenció en su primer tweet le hizo caso. Finalmente han sido otros medios que han conseguido replicar el fallo quienes se han hecho eco del mismo y en ese momento es cuando Apple ha reaccionado y se ha empezado a mover toda la maquinaria.

El padre, obviamente, se siente bastante frustrado y pide ya no una recompensa económica por encontrar el error (que Apple ofrece dinero por encontrar errores en sus sistemas). Simplemente pide un reconocimiento a su hijo y que mejoren los canales de comunicación para que cuando llegue algo así, se busque una forma de darle prioridad. Al menos que alguien con un poco más de poder de decisión pueda verificar las pruebas aportadas sin tener que llegar a la prensa. Desde luego, la mala publicidad para Apple a este respecto no les beneficia y tendrían que poner solución.

Porque este error podía haberse resuelto silenciosamente, sin llegar a la prensa, dentro incluso de la última versión iOS 12.1.3 y, como suele decirse, la sangre no hubiera llegado al río.

Los errores, algo difícil de gestionar

Sirva el final del artículo para poner en claro dos cosas, como desarrollador con más de 30 años de experiencia: detectar todos los errores de software es imposible. Y por muy obvio o tonto que parezca este error de FaceTime la realidad, como ya he dicho, es que a nadie (que sepamos) se le ha ocurrido probar el caso de uso exacto que lleva a ese fallo hasta hace 10 días desde que con iOS 10.1 se lanzaron las llamadas grupales de FaceTime. Ni siquiera a Apple, obviamente. No justifico a la compañía: pongo en perspectiva una realidad del software que le sucede a todas las compañías, incluida Apple.

Por otro lado, y sinceramente, agradezco la capacidad de reacción de Apple cuando por fin se han dado cuenta del error. Pero me parece más grave que los canales de comunicación hayan fallado para reportar este error y que haya tenido que ser la prensa la que ha hecho saltar las alarmas para que la maquinaría en Cupertino reaccione y se ponga a trabajar.

Me parece ejemplar lo que han hecho al reaccionar, pero tuvieron la oportunidad de hacerlo antes sin tanto revuelo y se ha demostrado que tienen una importante lección que aprender al respecto de la comunicación de errores de forma privada a Apple.