Las 5 claves de Borland para triunfar con las aplicaciones móviles
Según diferentes analistas las descargas de aplicaciones móviles pasarán de los 30.1 mil millones en 2011 a más de 200 mil millones en 2016.
La razón de este boom se justifica tanto en los cambios experimentados en los hábitos de consumo y la manera como nos socializamos, como en el desarrollo de nuevos canales para buscar información, leer las noticias o consultar las cuentas bancarias. Procesos, todos, mucho más sencillos gracias a las nuevas funcionalidades de los smart phones, el acceso universal a Internet y los cientos de miles de aplicaciones creadas específicas para hacer todo esto.
Según Borland, a Micro Focus company, poco a poco la presión se traslada de los departamentos de TI a otros como marketing y ventas, que tienen que ofrecer nuevas aplicaciones móviles que sean capaces de satisfacer las nuevas necesidades del usuario final. Sin embargo, estos “desarrolladores no profesionales” a menudo evitan o reducen el tiempo necesario para el testing crítico, con el fin de cumplir los plazos cada vez más cortos de entrega o, simplemente, porque no son conscientes de los riesgos que conlleva esta omisión.
“Si estás desarrollando una aplicación, que representa el escaparate de tu negocio, es imprescindible que esté convenientemente probada” dice Chris Livesey, vicepresidente de Gestión y calidad de aplicaciones de Borland. “La aplicación quizá sea muy creativa y ofrezca un increíble interfaz para el usuario pero si está incompleta, rota o funciona despacio, puede perjudicar la relación con los clientes. Nadie quiere una aplicación o página web que se caiga a la primera de cambio”
Livesey continúa: “Las pruebas de funcionalidad y de rendimiento de las aplicaciones móviles y basadas en la Web son importantes y no requieren una gran cantidad de tiempo para el proceso de desarrollo, o conocimientos profundos por parte del desarrollador. La clave está en las pruebas diseñadas específicamente para las aplicaciones móviles. Esto asegura que cualquier posible problema sea identificado y pueda ser rectificado, minimizando el riesgo de fallo que puede costar tiempo, dinero y reputación”.
Para ayudar a evitar estos errores, Borland ha identificado cinco claves para que los profesionales no expertos en desarrollo, puedan ofrecer aplicaciones móviles seguras y fiables:
Tiempo de prueba es igual a tiempo de reparación. A menudo, se emplea más tiempo de prueba en perfeccionar la aplicación que en probar la propia aplicación, lo cual no es una buena idea. Ese tiempo de prueba es el tiempo destinado a corregir la aplicación y a perfeccionar su experiencia de usuario. Probar no es productivo, arreglar cosas, sí.
Asegurar las condiciones de la aplicación. La mayoría de los problemas que ocurren con las aplicaciones móviles están relacionados con las condiciones de los datos, conectividad o condiciones de memoria física del dispositivo. Ejecutar la aplicación a través de la prueba de su uso funcional tiene sentido, pero es necesario asegurarse que las condiciones físicas de la aplicación y el dispositivo sean las correctas.
Priorizar las pruebas. Aunque la confianza es obviamente muy importante, probar todo el tiempo las aplicaciones en cada dispositivo conlleva emplear mucho tiempo y no debería ser así. Pero si es transaccional, tiene mucho tráfico o es el escaparate de su negocio, es necesario asegurarse de que funciona todo el tiempo y en todos los dispositivos habituales. El tiempo empleado en priorizar los objetivos es la mejor inversión que puede hacer.
Reutilizar las pruebas ahorra tiempo y dinero. La automatización de pruebas puede ser útil, ya que es posible grabar una vez un proceso y reproducir los tiempos de prueba muchas veces, lo que aumenta su cobertura, pero no sus horas de trabajo.
Observar los todos los datos mejora la calidad. Prestar atención a los datos previos aporta una ventaja inicial ya que permite conocer lo que es necesario trabajar. Pero no solamente eso, porque los análisis también ayudan a determinar cómo hay que probar la aplicación. Lo que era importante al principio, a menudo se cambia por otras cosas, por eso, las pruebas de aplicaciones tienen que evolucionar con la misma aplicación