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

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.

Hace 10 días, un joven de 14 años aficionado a los dispositivos de Apple descubrió el error, su padre intentó comunicarlo privadamente por vías oficiales a Apple y no pudieron. No les hicieron caso. Solo cuando la prensa lo ha sacado, Apple ha reaccionado.

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 a 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.

Ciclo Red-Green-Refactor del TDD Ciclo Red-Green-Refactor del TDD

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.

La forma de probar las apps de forma automática representa más un método de prevención frente a cambios que una forma productiva de detectar comportamientos no deseados.

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 si altero el código. Una vez valido que falla, la hago correcta, verifico que funciona y obtengo varios resultados correctos cuando sé que está va bien. Y ahora creo una función en otro programa que conecta al programa a probar: un test. En dicho test hago que recalcule mis cálculos previos y verifico que sigue funcionando bien porque devuelve lo que tiene que devolver. Verifico que los resultados que tenía cuando la función era correcta son los mismos que sigue devolviendo.

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.

Las pruebas unitarias son uno de los métodos más usados para verificar que una app que ya funciona, no deja de funcionar como debería. Pero como método de prevención de casos que se salen "de lo normal" no son eficientes.

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.

Desarrollo conducido a pruebas

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.

Pero en esta historia del fallo de FaceTime hay una lección que Apple debe aprender y mejorar más allá del error: los canales para reportar estos.

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. Está claro que nadie se percató en Apple que este era un fallo gordo ni existe ningún canal que permite sortear la burocracia intrínseca a cualquier proceso de este estilo.

Como puede verse en el tweet en la parte superior, 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. Al final, 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. Y 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.

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. No justifico a Apple: 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 haya 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 reaccionar 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.

También te recomendamos

DockPhone es la utilidad que todos los que odien FaceTime instalarán en su Mac

Las mejores ofertas de El Gran Sin IVA de Mi Electro: más de 300 productos rebajados

Apple inicia un programa para retirar del mercado el Beats Pill XL por fallo en la batería

-
La noticia La historia tras el error de FaceTime y la mejora al reporte de fallos que necesita Apple fue publicada originalmente en Applesfera por Julio César Fernández .




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

Comentarios