Seguramente habréis leído o visto las plataformas objetivo a publicar nuestra app, hacer estudios de mercado de target o incluso discutir Ubuntu como sistema operativo para desarrollar y programar. No obstante, hoy veremos la importancia de herramientas para detectar errores, bugs u otros funcionamientos erróneos de nuestra aplicación como, por ejemplo, UATs (User Acceptance Testing).
Desarrollo de apps: los test de usuario
¿Pero de qué trata las UATs? Son unos exámenes exhaustivos que deben pasar las aplicaciones antes de ser lanzada una actualización nueva, o en el caso de que no hayáis publicado aún, antes de subirla a la store correspondiente. Es una técnica que no sólo sirve para desarrollo móvil, si no también para el resto del software, es decir, que no está reducido a Android e iOS, lo podéis usar para web, por ejemplo.
Para ello es necesario un gran conocimiento de la app por la parte de programación, pero a su vez es interesante que quien hace el examen no sepa como han sido realizadas las funcionalidades. Esto os sonará un poco extraño: ¿cómo es posible que algún miembro del equipo no sepa como funciona su propia aplicación? En el mundo de la programación ocurre algo muy particular, y es que, al igual que es una profesión (casi un arte, para que negarlo) que se olvida con una facilidad brutal, nunca debéis permitir que sea el mismo programador quien haga los test en busca de bugs o malos procesos. Inconscientemente conocerá su producto y le hará evitar “liarla”. Es por ello que siempre os debéis buscar gente ajena al desarrollo. Aunque sea el diseñador, tranquilamente, porqué, si bien te ha hecho los colores y los botones, no sabe que lógica hay detrás de todo ello.
¿Cómo se realiza y documentan las UATs?
1.Todas las pantallas son importantes. Hay que documentar hasta lo que ocurre después de presionar el icono de la app mientras esperamos que se ejecute.
2.Preparar una hoja de cálculo. Os puede servir cualquier software. La más utilizada es LibreOffice, ya que es gratuito y no tendréis que complicaros la vida para descargarlo (buscar licencias sin pagar, por ejemplo).
3.Insertar tantas páginas adicionales como sea necesario. Pensad que vais a hacer un seguimiento completo de todo el funcionamiento de la app. Por lo que es recomendable generar una página nueva por cada pantalla que el usuario final vaya a ver. Por ejemplo: una app que tiene pantalla principal, listado de productos, descripción y opciones. La hoja de cálculo de las UATs tendría cuatro páginas en total, cada una a su sección correspondiente.
4.Anotar en cada celda todo lo que se supone que debe ocurrir. Hay que insistir en el “se supone que”, ya que las UATs no son para monitorizar lo que sucede, si no lo que debería suceder. Por eso son tan útiles y van tan bien para encontrar bugs o malos funcionamientos. En cada celda escribís la funcionalidad que en teoría debería estar implementada, y a su lado qué acción la lanza. La acción que la lanza es, por ejemplo, el “presionar el icono de la aplicación en el escritorio del terminal”. La tercera columna la reserváis para anotar las observaciones en el caso de que las cosas no salgan según lo previsto, algo demasiado habitual en nuestro oficio…
Estas serían cuatro recomendaciones a la hora de hacer estas pruebas. Pero la pregunta que nos interesa es en qué momento se hacen. Pues bien, la mala noticia es que las UATs no terminan nunca. Cada vez que se implemente una característica nueva, cada vez que se quiera lanzar una versión más moderna, hay que realizar test. De hecho hay que realizarlos incluso si no se ha modificado nada de lo que anteriormente funcionaba, ya que a la hora de detectar errores se debe dar por supuesto que cualquier cosa puede fallar, y nunca se debe dar por sentado que un nuevo módulo en nuestra aplicación no rompe el trabajo ya hecho.
