Cómo crear una app nativa (IV): usability y app testing

Como fase final en el proceso de de­sa­rro­llo de una apli­ca­ción, el app testing re­pre­se­n­ta la opo­r­tu­ni­dad de evaluar su co­m­po­r­ta­mie­n­to y su madurez. En este estadio se examina la apli­ca­ción en lo referente a sus aptitudes fu­n­cio­na­les y a su usa­bi­li­dad, así como se comprueba su co­m­pa­ti­bi­li­dad con di­fe­re­n­tes di­s­po­si­ti­vos y sistemas ope­ra­ti­vos. Una vez de­sa­rro­lla­da té­c­ni­ca­me­n­te y fijado el diseño final, lo más normal es querer publicar la apli­ca­ción cuanto antes. Sin embargo, lo más oportuno sería examinar la idoneidad de la apli­ca­ción en di­fe­re­n­tes ámbitos. Los métodos más uti­li­za­dos para ello son los tests de usa­bi­li­dad, de re­n­di­mie­n­to y de co­m­pa­ti­bi­li­dad, pro­ce­di­mie­n­tos incluidos dentro del de­no­mi­na­do testing de apli­ca­cio­nes móviles o, se­n­ci­lla­me­n­te, app testing, y para el cual se disponen de diversas he­rra­mie­n­tas que pre­se­n­ta­mos más abajo.

El éxito final de una apli­ca­ción depende no poco de los co­n­te­ni­dos que ofrece y de una buena co­me­r­cia­li­za­ción, pero aún más de un fu­n­cio­na­mie­n­to impecable y de un diseño amigable. Esto hace que las pruebas previas a su la­n­za­mie­n­to sean im­pre­s­ci­n­di­bles, in­de­pe­n­die­n­te­me­n­te de que se trate de una apli­ca­ción móvil o para es­cri­to­rio, aunque en el caso de las primeras se ha de contar con un factor extra de gran peso como es la ada­p­ta­ción a los di­fe­re­n­tes te­r­mi­na­les, aspecto mucho más complejo en las apli­ca­cio­nes móviles que en otro tipo de software.

En los albores del de­sa­rro­llo de apli­ca­cio­nes, ajustar la apli­ca­ción a las di­fe­re­n­tes pantallas no co­m­po­r­ta­ba tanta di­fi­cu­l­tad porque aún no existía tanta di­ve­r­si­dad, pero en­tre­ta­n­to la variedad de te­r­mi­na­les móviles y de pre­s­ta­cio­nes ha crecido ex­po­ne­n­cia­l­me­n­te, de tal forma que cada modelo de sma­r­t­pho­ne o de tablet cuenta con un hardware co­m­ple­ta­me­n­te diferente. En pa­r­ti­cu­lar, co­m­po­ne­n­tes como el pro­ce­sa­dor (unidad de CPU), la memoria RAM, el tamaño de la pantalla o su re­so­lu­ción son decisivos a la hora de ejecutar una apli­ca­ción.

También el software del di­s­po­si­ti­vo tiene un papel im­po­r­ta­n­te. En este caso son, en primera instancia, los distintos sistemas ope­ra­ti­vos de una pla­ta­fo­r­ma los que influyen en el fu­n­cio­na­mie­n­to de la apli­ca­ción. Aquellos sistemas más antiguos pueden di­fi­cu­l­tar el uso de una de­te­r­mi­na­da apli­ca­ción por falta de ac­tua­li­za­ción (y conviene no su­b­e­s­ti­mar la expansión de versiones an­te­rio­res tanto de sistemas Android como iOS). La di­ve­r­si­dad de sistemas ope­ra­ti­vos uti­li­za­dos en la práctica se pone más aún de ma­ni­fie­s­to cuando ob­se­r­va­mos la uti­li­za­ción de las distintas versiones de Android, pues, en general, las versiones antiguas superan en usuarios a la más nueva, lo que tiene que ver con el retraso de algunos fa­bri­ca­n­tes en ofrecer la ac­tua­li­za­ción para sistemas Android. Y, si bien es cierto que en sistemas iOS la nueva versión del sistema operativo llega a los te­r­mi­na­les Apple más rá­pi­da­me­n­te, también lo es que los iPhones o iPads más antiguos ya no tienen ocasión de ac­tua­li­zar­se más, motivo por el que también es posible encontrar versiones iOS obsoletas en te­r­mi­na­les Apple.

Esta di­ve­r­si­dad en cuanto al hardware y al software de los te­r­mi­na­les móviles recibe el nombre de fra­g­me­n­ta­ción y sitúa a la garantía de calidad de las apli­ca­cio­nes ante im­po­r­ta­n­tes desafíos. Es aquí donde in­te­r­vie­ne el app testing, durante el cual se comprueba si la apli­ca­ción, en efecto, funciona y, si lo hace, si se dan pro­ble­má­ti­cas durante su ejecución. Ga­ra­n­ti­zar una ex­pe­rie­n­cia de usuario óptima para el mayor número posible de usuarios solo es posible de­te­c­ta­n­do y so­l­ve­n­ta­n­do estos ob­s­tácu­los, pues, úni­ca­me­n­te si una apli­ca­ción ofrece una buena pe­r­fo­r­ma­n­ce y usa­bi­li­dad en tantos di­s­po­si­ti­vos como sea posible, puede lograr la expansión deseada.

A la hora de realizar pruebas de calidad son posibles diversas apro­xi­ma­cio­nes. Las cue­s­tio­nes que deciden cómo se van a llevar a cabo son pri­n­ci­pa­l­me­n­te, quién o qué ha de hacerlo (tests manuales o au­to­ma­ti­za­dos) y cómo (en cada terminal o mediante un simulador o emulador).

Test manual por parte de un usuario La prueba manual, en la cual es el usuario quien evalúa la apli­ca­ción, es la variante más clásica del app testing y tiene su razón de ser en lo difícil que es para los equipos de de­sa­rro­lla­do­res, por el tiempo que supone, probar ellos mismos el fu­n­cio­na­mie­n­to de una apli­ca­ción, en especial en el caso de las apps para Android. Como solución, se recurre a un conjunto de personas lo más re­pre­se­n­ta­ti­vo posible que ha de utilizar la apli­ca­ción según unas co­n­di­cio­nes pre­de­fi­ni­das por el equipo de de­sa­rro­llo y evaluarla al final. La ventaja de integrar en el test a personas externas al equipo es que no disponen de ningún tipo de co­no­ci­mie­n­to previo en relación con la ope­ra­ti­vi­dad de la apli­ca­ción, lo que las coloca, a la hora de valorarla, en la posición más cercana al juicio del usuario potencial. Otro tipo de test manual de apli­ca­cio­nes consiste en el cro­w­d­te­s­ti­ng. Para este tipo de pruebas, el equipo de de­sa­rro­llo recurre, a través de empresas de cro­w­s­te­s­ti­ng, a un grupo de testers que se co­rre­s­po­n­de con su audiencia para que prueben su apli­ca­ción en sus propios di­s­po­si­ti­vos. El app testing no tiene lugar, así, en un entorno de prueba aislado, sino en el entorno natural del usuario, lo que aumenta la au­te­n­ti­ci­dad de los re­su­l­ta­dos de las pruebas. Con el de­no­mi­na­do Te­s­t­Fli­ght Beta Testing de Apple se puede organizar un cro­w­d­te­s­ti­ng invitando hasta a 2000 personas para que prueben apli­ca­cio­nes para iOS, así como para watchOS o tvOS. Google también ofrece a los de­sa­rro­lla­do­res de software di­fe­re­n­tes opciones para realizar pruebas alpha y beta de apli­ca­cio­nes Android. Test au­to­ma­ti­za­do mediante he­rra­mie­n­tas de app testing A di­fe­re­n­cia del manual, el control au­to­ma­ti­za­do se aplica sobre todo en ámbitos en los cuales se trata de probar ciertos procesos de forma co­n­ti­nua­da bajo co­n­di­cio­nes ca­m­bia­n­tes mediante un software especial. La mayor ventaja de este tipo de examen radica en el ahorro de tiempo que supone, ya que estos programas pueden llevar a cabo las pruebas en una fracción del tiempo que re­que­ri­ría una persona para hacer lo mismo. Sin embargo, no es apropiado para todos los campos de prueba.

Probar una apli­ca­ción en un terminal físico

La eva­lua­ción de una apli­ca­ción en todos los di­s­po­si­ti­vos móviles es la solución ideal que permite controlar el fu­n­cio­na­mie­n­to de una apli­ca­ción en co­m­bi­na­ción con el software y el hardware propio de cada caso. Sin embargo, se trata de una opción cara y exigente en cuanto a la duración, pues, si se quieren realizar pruebas exhau­s­ti­vas es necesario un gran número de sma­r­t­pho­nes y tablets, en cada uno de los cuales hay que probar el co­m­po­r­ta­mie­n­to de la apli­ca­ción desde cero. La mejor ale­r­na­ti­va consiste en recurrir a diversos pro­vee­do­res a través de los que se obtiene acceso a un co­n­ti­n­ge­n­te de di­s­po­si­ti­vos di­fe­re­n­tes, a menudo de­no­mi­na­dos “Device Lab” o “Test Lab”, con los cuales se puede probar la apli­ca­ción.

Utilizar un emulador / simulador

Los si­mu­la­do­res y los emu­la­do­res son programas que imitan el fu­n­cio­na­mie­n­to de ciertos di­s­po­si­ti­vos y que permiten probar apli­ca­cio­nes vi­r­tua­l­me­n­te. Sin embargo, los re­su­l­ta­dos obtenidos con este tipo de app testing no son siempre ab­so­lu­ta­me­n­te fiables al no poder ser simuladas todas las in­ter­ac­cio­nes de los usuarios de forma co­m­ple­ta­me­n­te veraz. Dado que la si­mu­la­ción tiene sus límites, algunos tipos de prueba requieren ne­ce­sa­ria­me­n­te ser rea­li­za­dos en un terminal físico.

No obstante, aunque los si­mu­la­do­res y emu­la­do­res no pueden sustituir por completo a las pruebas en aparatos físicos, sí co­n­s­ti­tu­yen un buen co­m­ple­me­n­to a los mismos, sobre todo de los au­to­ma­ti­za­dos. Con su ayuda es posible probar la aptitud de una apli­ca­ción en di­fe­re­n­tes co­n­di­cio­nes de software y de hardware. Muchos de estos programas están di­s­po­ni­bles de forma gratuita, por ejemplo, en Android Studio o en el Xcode de Apple.

De la misma forma que existen pro­ce­di­mie­n­tos di­fe­re­n­tes a la hora de evaluar la madurez de una apli­ca­ción, también cabe examinar distintos aspectos en un testing de apli­ca­cio­nes móviles exhau­s­ti­vo. Los cuatro apartados que pre­se­n­ta­mos a co­n­ti­nua­ción, si bien re­pre­se­n­tan solamente una selección, son im­pre­s­ci­n­di­bles. Además de estos cuatro, es posible también comprobar la seguridad (security testing) o la lo­ca­li­za­ción (lo­ca­li­za­tion testing), entre otros muchos.

Con una prueba funcional se controla si la apli­ca­ción actúa realmente como se había pla­ni­fi­ca­do: se comprueba que todos los co­n­te­ni­dos de la apli­ca­ción trabajen de la forma correcta, in­s­pe­c­cio­na­n­do cada función, cada pantalla y cada botón. El test funcional gira en torno a las preguntas:

• ¿Se puede instalar y des­in­s­ta­lar fá­ci­l­me­n­te?

• ¿Funcionan todos los co­n­te­ni­dos como estaba previsto?

• ¿Puede continuar usándose sin ningún problema después de haber sido mi­ni­mi­za­da?

• ¿Se producen errores y caídas de la apli­ca­ción?

• ¿Recibe el usuario la no­ti­fi­ca­ción co­rre­s­po­n­die­n­te cuando se produce un error?

Pero, además de la apli­ca­ción en sí, también hay que examinar su co­m­po­r­ta­mie­n­to en de­te­r­mi­na­dos es­ce­na­rios:

• Cuando la apli­ca­ción es mi­ni­mi­za­da, ¿se pueden seguir eje­cu­ta­n­do otras apli­ca­cio­nes y otras funciones del di­s­po­si­ti­vo sin problemas?

• ¿Se minimiza au­to­má­ti­ca­me­n­te cuando entra una llamada?

• ¿Se reciben y almacenan los mensajes de texto y otras no­ti­fi­ca­cio­nes durante el uso de la apli­ca­ción?

La prueba de usa­bi­li­dad permite comprobar la facilidad de uso de la apli­ca­ción para el usuario, lo que también se denomina usa­bi­li­dad. Ob­via­me­n­te, en este caso el test au­to­má­ti­co no es una opción, pues solo los usuarios pueden evaluar en qué medida una apli­ca­ción es fácil o difícil de usar, de la misma forma que tampoco es muy práctico en muchos aspectos utilizar un emulador o un simulador, pues solo es posible evaluar el manejo de una apli­ca­ción mediante un di­s­po­si­ti­vo físico. Solo así es posible saber cómo se percibe el control táctil de la pantalla y las di­fe­re­n­tes acciones que se pueden llevar a cabo en ella, así como los tiempos de reacción cuando se activan estos comandos. Otros aspectos que se toman en co­n­si­de­ra­ción en un test de usa­bi­li­dad son los si­guie­n­tes:

• ¿Se puede entender su fu­n­cio­na­mie­n­to de forma evidente? ¿Se ofrecen ex­pli­ca­cio­nes en el caso de funciones más complejas?

• ¿Se ha colocado el contenido de tal forma que el usuario puede acceder a las funciones más im­po­r­ta­n­tes sin ob­s­tácu­los?

• ¿Siguen la co­lo­ca­ción de los co­n­te­ni­dos y la co­m­po­si­ción de la interfaz un concepto coherente re­co­no­ci­ble en todos los aspectos de la apli­ca­ción e in­te­li­gi­ble de forma intuitiva?

• ¿Se han colocado bien los botones y diseñado en su tamaño adecuado? No hay que olvidar a aquellos usuarios con movilidad reducida.

• ¿Es la redacción de los textos lo su­fi­cie­n­te­me­n­te precisa y tiene el formato adecuado en cuanto a le­gi­bi­li­dad?

El usability test detecta estos y otros problemas en el uso de la apli­ca­ción, así como omisiones en la re­pre­se­n­ta­ción amigable del layout. Con el objetivo de recabar re­su­l­ta­dos elo­cue­n­tes, hay que intentar que el test sea llevado a cabo por su­fi­cie­n­tes sujetos. Asimismo, también es una ventaja que al menos una gran parte de estas personas se integren en el público objetivo para el cual se diseña la apli­ca­ción, pues de esta forma se puede optimizar la uti­li­za­ción y la es­tru­c­tu­ra del layout en función de los deseos de la audiencia, lo que, en de­fi­ni­ti­va, permite ofrecer a los usuarios la mejor ex­pe­rie­n­cia de usuario posible.

Esta prueba controla la co­m­pa­ti­bi­li­dad de una apli­ca­ción en relación con el hardware y el software de los distintos di­s­po­si­ti­vos móviles. Respecto al hardware, por ejemplo, hay que probar la vi­sua­li­za­ción de la apli­ca­ción en pantallas di­fe­re­n­tes, ya que, debido a la di­ve­r­si­dad de tamaños y re­so­lu­cio­nes de pantalla presente en el mercado móvil, es fácil que se produzcan errores de ajuste o de vi­sua­li­za­ción, sobre todo si no se crearon layouts di­fe­re­n­tes para cada formato de pantalla. Otros aspectos como la CPU o la memoria RAM también varían mucho en función del terminal. Conviene recordar aquí que los aparatos antiguos no son ninguna rareza y si la apli­ca­ción no solo está pro­ye­c­ta­da para los modelos actuales, sino que también funciona de forma aceptable en los antiguos, se amplía co­rre­s­po­n­die­n­te­me­n­te su público potencial.

En lo que hace re­fe­re­n­cia al software, en un test de co­m­pa­ti­bi­li­dad se controla que la apli­ca­ción se ejecute sin problemas en los más diversos sistemas ope­ra­ti­vos. En pa­r­ti­cu­lar en el caso de una apli­ca­ción para Android, probarla en las di­fe­re­n­tes versiones de su sistema operativo es es­pe­cia­l­me­n­te relevante, ya que a través de esta pla­ta­fo­r­ma se di­s­tri­bu­yen y utilizan muchas más versiones di­fe­re­n­tes que en iOS.

Mediante un test de co­m­pa­ti­bi­li­dad es posible comprobar en función de qué co­n­di­cio­nes técnicas aparecen los primeros problemas de ejecución. Si los re­qui­si­tos de software o de hardware son muy altos, quizá habría que co­n­si­de­rar una reducción de ciertas co­n­di­cio­nes fu­n­da­me­n­ta­les del sistema para no limitar la audiencia.

Con él se prueba cuántos recursos del sistema consume la apli­ca­ción cuando se utiliza co­n­ti­nua­me­n­te. Aquí los de­sa­rro­lla­do­res están in­te­re­sa­dos en saber si la apli­ca­ción funciona de forma fluida o se generan fallos cuando se utiliza sin descanso, si la batería se gasta en exceso o si el di­s­po­si­ti­vo se re­ca­lie­n­ta una vez tra­n­s­cu­rri­do cierto tiempo. Igual que en el de co­m­pa­ti­bi­li­dad, en este test también se evalúa el re­n­di­mie­n­to de la apli­ca­ción bajo de­te­r­mi­na­das co­n­di­cio­nes, por ejemplo, cómo afecta a la ejecución de la apli­ca­ción el que la memoria no disponga de mucho espacio libre o que la batería esté casi agotada. En de­fi­ni­ti­va, el test de re­n­di­mie­n­to mide en qué medida de­te­r­mi­na­das si­tua­cio­nes influyen de manera negativa en el co­m­po­r­ta­mie­n­to de la apli­ca­ción.

En el campo de las pruebas de calidad de software, cuando de lo que se trata es de someter a uno o a varios co­m­po­ne­n­tes a una carga elevada se habla de pruebas de carga (load testing) o de estrés (stre­s­s­te­st). Un ejemplo sería la prueba de estrés de un servidor, en la cual se evalúa el co­m­po­r­ta­mie­n­to de una apli­ca­ción en el caso de un elevado número de accesos a su servidor. En el caso de una apli­ca­ción cuyas funciones requieren una conexión a Internet activa, la prueba de carga de la red ha de ide­n­ti­fi­car los efectos de una conexión débil en el fu­n­cio­na­mie­n­to de la apli­ca­ción. Las pruebas de estrés, por su parte, tienen el objetivo de mostrar cuánta carga soportan ciertos co­m­po­ne­n­tes antes de mostrar li­mi­ta­cio­nes en sus aptitudes.

Estas pruebas no tienen que ser llevadas a cabo ma­nua­l­me­n­te en todos los casos. En muchos aspectos, las he­rra­mie­n­tas de testing de apli­ca­cio­nes móviles facilitan el trabajo eno­r­me­me­n­te. Dado que hasta ahora nos hemos ocupado del de­sa­rro­llo de apli­ca­cio­nes nativas para sistemas Android e iOS, hemos se­le­c­cio­na­do he­rra­mie­n­tas para estas pla­ta­fo­r­mas.

Appium es un programa de código abierto para la au­to­ma­ti­za­ción de pruebas in­de­pe­n­die­n­te de pla­ta­fo­r­ma. Di­s­po­ni­ble de forma gratuita, esta he­rra­mie­n­ta no solo permite probar apli­ca­cio­nes nativas para Android o iOS, sino que también soporta la au­to­ma­ti­za­ción de pruebas de apli­ca­cio­nes híbridas y web para ambas pla­ta­fo­r­mas. En Appium se utiliza la misma interfaz de pro­gra­ma­ción tanto para iOS como para Android, de tal forma que permite re­uti­li­zar el código escrito. Las pruebas rea­li­za­das con esta he­rra­mie­n­ta se pueden llevar a cabo en aparatos físicos, en emu­la­do­res y en si­mu­la­do­res. Se trata de un software muy útil para realizar pruebas de app testing au­to­ma­ti­za­das, aunque requiere un cierto grado de co­no­ci­mie­n­tos en de­sa­rro­llo de software.

En la página web de TestFairy los de­sa­rro­lla­do­res pueden colgar su apli­ca­ción e invitar a personas a que la prueben, para lo cual solo tendrán que de­s­ca­r­gar­la y uti­li­zar­la. Esta es una pla­ta­fo­r­ma que, de alguna manera, permite a los equipos de de­sa­rro­llo gestionar su propio cro­w­d­te­s­ti­ng. La he­rra­mie­n­ta incluye una función para notificar errores y permite crear una toma de vídeo mientras se usa la apli­ca­ción. TestFairy está di­s­po­ni­ble como versión gratuita y también como versión pro­fe­sio­nal de pago.

Ube­r­te­s­te­rs es una pla­ta­fo­r­ma de soporte para realizar la prueba de la versión beta de las apli­ca­cio­nes. Además de mantener el control total sobre las pruebas y de obtener informes exhau­s­ti­vos, la he­rra­mie­n­ta de app testing permite trabajar en equipo, detectar errores del programa de forma re­la­ti­va­me­n­te sencilla, crear y probar versiones de prueba di­fe­re­n­tes de una apli­ca­ción y llevar a cabo cro­w­d­te­sts en la forma de, por ejemplo, tests de usa­bi­li­dad y de funciones. Ube­r­te­s­te­rs está di­s­po­ni­ble en diversos paquetes, cada uno con una paleta diferente de funciones, el más sencillo gratuito.

El público de una apli­ca­ción aumenta, sin duda alguna, cuando se diseña para que también sea operativa en muchos te­r­mi­na­les antiguos, pero adaptarse a un gran número de di­s­po­si­ti­vos es posible dentro de unos límites. Aquellas apli­ca­cio­nes muy exigentes en cuanto a potencia, por ejemplo, cuyas funciones necesitan un pro­ce­sa­dor más potente o mucha memoria, podrían no poder ser adaptadas a un hardware más antiguo. Y si una apli­ca­ción requiere una conexión excelente a Internet, no se debería intentar adaptarla a cualquier precio a un escenario en el cual se dispone de una conexión débil.

Muchas apli­ca­cio­nes requieren, se­n­ci­lla­me­n­te, unas co­n­di­cio­nes técnicas de­te­r­mi­na­das. Las hay que necesitan un tamaño de pantalla es­pe­cí­fi­co para poder ser eje­cu­ta­das, mientras que otras, como la apli­ca­ción de YouTube, solo funcionan cuando se puede recurrir a una velocidad de tra­n­s­fe­re­n­cia de datos lo su­fi­cie­n­te­me­n­te ágil, y aun así, se trata de la apli­ca­ción más de­s­ca­r­ga­da. Antes de ajustar y reducir el espectro de funciones de una apli­ca­ción, hay que re­fle­xio­nar, con la vista puesta en el alcance de la apli­ca­ción, acerca de si con ellos se reduce su fu­n­cio­na­li­dad más de lo deseado.