Desde hace un tiempo, en el mundo de la informática, las aplicaciones que desarrollamos y usamos, son técnicamente muy distintas a las antiguas de escritorio. Estas aplicaciones por lo general interaccionan con otras aplicaciones, por ejemplo utilizan repositorios de datos e invocan servicios externos que podrían estar distribuidos. La pregunta que nos hacemos hoy es, para las aplicaciones de smartphones (teléfonos inteligentes), comúnmente llamadas apps, ¿se requieren nuevas formas de testear?
Casi todos hemos visto videos en los que se prueban celulares sumergiéndolos en agua, soltándolos en caída libre, tirándolos contra algo para probar ciertas propiedades del hardware, tales como la resistencia de la pantalla, etc.
También existen aplicaciones web para comparar 2 modelos de celulares, incluso de diferentes marcas, se puede evaluar características, comparar funcionalidades, tamaños, etc. Pero si lo que queremos es probar una app nativa en una versión determinada de un sistema operativo x, en principio surge la interrogante ¿Qué tipos de prueba es conveniente ejecutar?
Durante el desarrollo de cualquier software, el testing unitario es fundamental para obtener información de la calidad del producto. Lo ideal es que el desarrollador ejecute pruebas funcionales en el hardware en el cual espera que su app se ejecute, con la versión del software de base correspondiente. En el testing unitario se prueban las funcionalidades sin interaccionar con otros sistemas, luego se integra con otros módulos, por ejemplo a través de una API que encapsula los elementos de comunicación (gmaps, gps, etc.). Estas primeras pruebas son de caja blanca, y pueden automatizarse por el equipo de desarrollo.
Cuando haya un prototipo o una primera versión de la aplicación se comienzan a ejecutar pruebas de caja negra, para comprobar que las funcionalidades requeridas existen y se comportan según los requerimientos. En este punto se puede ser tan imaginativo y exigente como se quiera/requiera: revisar pantallas, botones, flujos de navegación, con/sin conexión a internet, agotando la energía (batería), ciclos funcionales que incluyan llamadas telefónicas y mensajes de texto. Hoy en el mercado el horizonte se amplía muchísimo ya que los distintos modelos de celulares tienen diferentes pantallas (tradicional/táctil), con varios diseños de botones para utilizar desde la aplicación, diferentes sistemas y versiones de los mismos.
En lo que a seguridad se refiere recomendamos a los analistas y desarrolladores aplicar alguna de las propuestas de buenas prácticas existentes (por ejemplo OWASP), logrando así, desde el comienzo del proyecto un producto “defensivo”, por ejemplo definir y aplicar métodos de protección de datos (archivos temporales, logs, contraseñas, credenciales). Desarrollar teniendo en mente las debilidades más comunes de las aplicaciones y los fundamentos de una programación segura para prevenir posibles ataques.
Luego un equipo diferente del de desarrollo puede diseñar pruebas para intentar penetrar en la aplicación en busca de posibles vulnerabilidades.
Cuando consideremos que la aplicación es estable, y que las funcionalidades hacen lo que se espera, podemos pasar a evaluar nuestra app, desde el punto de vista de su performance. Nuevamente recomendamos que el equipo de desarrollo tenga en mente la performance desde el inicio del proyecto, defina los requerimientos de performance y evalúe módulos y su integración (por ejemplo que el tiempo de respuesta no supere los 3 segundos). En este punto es importante diferenciar el tipo de arquitectura, ya que definirá los tipos de prueba a aplicar. En una arquitectura cliente servidor, será tan importante probar el cliente como el servidor (en el caso del servidor se ejecutan las pruebas usuales para aplicaciones web). A continuación veremos las particularidades de probar el cliente.
El equipo de testing, teniendo en cuenta los requerimientos definidos evaluará la performance de la aplicación, agregando puntos de monitorización y llevando al límite la utilización de recursos (GPS, 3G, WiFi) y combinando su ejecución con algunas de las acciones frecuentes al usar un celular, por ejemplo girar el dispositivo, llamadas y mensajes entrantes, aplicaciones que corran en background (esto podría mejorar o empeorar la performance).
En conclusión, tecnológicamente las aplicaciones que usamos están teniendo un giro casi radical y el universo de pruebas posibles se hace cada vez mayor. Sin embargo, los tipos de testing que recomendamos ejecutar son básicamente los mismos, comenzando por un testing de caja blanca (automatizadas o no). Continuando con diferentes pruebas de caja negra preferentemente diseñadas y ejecutadas por un equipo diferente al de desarrollo.
