Estrategia de pruebas

Descripción de la aplicación

Habitica es un gestor de tareas que nos permite cumplir nuestros objetivos diarios posteando actividades, utilizando un sistema de premios o recompensa y posteando habitos que interfieran en nuestra forma de vivir.

La arquitectura de esta aplicación es toma como base el lenguaje Kotlin, el cual se ejecuta sobre la máquina virtual de JAVA, el proyecto está construido con Gradle como administrador de paquetes incluyendo Android-tools. La aplicación sigue la arquitectura de cliente-servidor, donde el servidor utiliza el framework Express.js corriendo en Node.js y el cliente es la aplicación nativa.

Contexto de ejecución del proceso de pruebas

Para nuestro segundo sprint se cuenta con 3 Ingenieros y 4 horas semanales cada uno, los recursos a nivel general son simuladores Android del sitio web Genymotion de los cuales hemos tomado 3 para hacer una matriz de dispositivos, en el anterior sprint tuvimos un inconveniente con uno de los simuladores por la versión de android, por lo cual hemos decidido utilizar un simulador con versión de android mas reciente.

Las maquinas disponibles para las pruebas son:

Especificaciones
Dell Intel Core i7, RAM 16GB, 64 bit, Windows
MACBook Intel Core i9, RAM 16GB, macOS Catalina
Asus Intel Core i7, RAM 8GB, 64 bit, Windows

Matriz de dispositivos
Google Nexus 6, Android 8.0 API 26, 64 bit, 1440*2560
Huawei P30 Pro, Android 9.0 API 28, 1080*2340
Samsung A10, Android 9.0 API 28, 720*1520

Objetivos del proceso de pruebas

• Detectar defectos de la aplicación a través de pruebas BDT.
• Ejecutar pruebas utilizando una matriz de dispositivos.
• Identificar la efectividad de las pruebas corriendo las mismas sobre al menos 2 mutaciones de la aplicación.
• Identificar los defectos inyectados y determinar a qué tipo de mutación pertenecen y si fueron halladas por nuestro set de pruebas.
• Realización de pruebas de experiencia de usuario.

Funcionalidades a probar

• Login
• Registro
• Editar avatar
• Cambio de lenguaje de la aplicación
• Visualizar tarea
• Habitos
• Tareas pendientes
• Tarea diarias
• Recompensas
• Realizar busqueda de tareas
• Crear equipo
• Invitar amigos a un equipo
• Editar equipo
• Invitar a una mision
• Visualizar miembros del equipo
• Enviar mensajes a miembros del equipo

Tipos y niveles de pruebas

Las pruebas a realizar son pruebas a nivel sistema de tipo BDT sobre 15 funcionalidades de la aplicación móvil utilizando la herramienta calabash. Para esta iteración hemos decidido implementar las mismas pruebas pero sobre mutantes de la aplicación base. Esto se realiza con el objetivo de asegurar la efectividad de nuestras pruebas de acuerdo a los defectos encontrados sobre nuestra aplicación base. Para simular pruebas de regresión vamos a correr las mismas pruebas sobre 2 mutantes de la aplicación base y documentar los errores encontrados en los mismos.

Resultados

Al correr un set de pruebas de las 15 funcionalidades, hemos encontrado 6 errores sobre la aplicación base, los cuales estan formalmente reportados en https://grupo5.backlog.com/ y se encontraron también como parte de pruebas manuales, en algunos casos cuentan con el script de pruebas adecuado, en otros casos por la complejidad del script, se ha optado por dejar el reporte y levantar un script adecuado para nuestro siguiente sprint.

Por otra parte al ejecutar nuestros scripts en diferentes modelos tenemos las siguientes observaciones:

En el samsung se corrió el mismo test de pruebas pero ocasionalmente por la distribución en pantalla los scripts fallaban, es probable que se incurra en flaky test si hacemos uso de retardos ya que era la forma que se encontraba para que el script corriera en ciertas pantallas, por otro lado el tema de la ubicación del click dio problemas por la distribución de pantallas en ciertas vistas. Por otra parte hemos trabajo con las 2 herramientas para crear las mutaciones de la aplicación, por un lado Mdroid y por el otro MutAPK, a continuación compartimos los resultados de las pruebas con ambas herramientas.

Mdroid

Para hacer uso de esta herramienta descargamos el codigo fuente de Habitica y corrimos las instrucciones necesarias para la mutación, de la cual se nos han generado solo 2 mutaciones, para la primera mutación el código no logro compilar como se comparte en la siguiente imagen:

Puede ser considerado como Nacido muerto, en segundo lugar tenemos una mutación que no logro un cambio considerable en la aplicación, por lo cual la aplicación corrió sin problemas, finalmente despues de un par de horas de analizar todo el contexto, hemos visto que es poco probable un correcto funcionamiento con Mdroid, ya que el código esta 90% en Kotlin, y las mutaciones son factibles sobre Java, por ello estas pruebas de mutación con Mdroid no han sido del todo exitosas.

A continuación el resultado de las pruebas que vienen con el proyecto base, lo ideal hubiera sido levantar el mismo set de pruebas sobre los mutantes para conocer que se detectaba en primera instancia antes de ejecutar los scripts.

MutAPK

La implementación de las mutaciones con esta herramienta en teoría es mucho mas sencilla, pero lamentablemente tuvimos de principio problemas para ejecutarla ya que el .jar version 1.0.0 tiene problemas, se logro ejecutar con el .jar versión 0.0.1 en el cual logro levantar la herramienta correctamente, pero para habitica Móvil los mutantes no se crearon, los carpetas salieron vacías, finalmente se decidió llevar un ejercicio de mutación con la aplicación My expenses el cual relacionaremos a continuación, finalmente cabe acotar que no levantamos scripts de pruebas para my expenses ya que nuestro grupo ha trabajado con habitica Movil y web por ser solo de 3 integrantes y nos ha parecido mas eficaz invertir el tiempo en mejorar y hacer crecer lo que tenemos tanto en scripts como en desarrollo de la herramienta de pruebas.

Mutación con My expenses

Para el desarrollo del ejercicio se generaron 50 mutantes por medio de la siguiente instrucción: java -jar .\target\MutAPK-0.0.1.jar .\my-expenses-3-0-3-1.apk org.totschnig.myexpenses .\mutants\ .\extra\ .\ true 50, en la siguiente imagen se aprecian los resultados del ejercicio:

Utilizamos los siguientes 5 operadores de mutación:

Operadores de mutación
1 = ActivityNotDefined
2 = DifferentActivityIntentDefinition
3 = InvalidActivityName
4 = InvalidKeyIntentPutExtra
5 = InvalidLabel

Los 50 mutantes fueron generados correctamente y se compilaron bien debido ya que generó el apk firmado y sin firmar para cada mutante.

No logramos subir los mutantes al repositorio por el peso del material generado, sin embargo si en las entregas posteriores es requerida, podemos seleccionar la información mas indispensable para compartirla.

Resultados experiencia de usuario

Durante nuestra experiencia vimos ausencia de simplicidad en la aplicación, aunque con bastante creatividad y diversidad, con mucho colorido pero da la impresión que no fuera un diseño tan profesional.

Su navegabilidad y facilidad para encontrar contenido no es tan sencilla como para lo que sirve realmente la aplicación. Lo que se quiere decir, es que la aplicación no hace un gran aporte a la persona que la usa como para ser tan compleja en su navegabilidad.

No es tan fácil aprender a usar el software, porque su usabilidad requiere un contexto de uso y un objetivo que el usuario quiere alcanzar, y en nuestro caso no le vemos el 100% de utilidad. En este sentido, si es para llevar solo un esquema de tareas pudiera ser facil de principio, si fuera solo eso, pero cuenta con demasiadas caraterísticas adicionales que es muy probable que más del 70% de los usuarios no utilice.

Nuestra sesión de pruebas fue corta, podria decirse que remota y sin moderador por lo que se pudo obtener información cuantitativa de tiempos de uso (tiempo por tarea, porcentaje de terminación de tareas), y alineamiento de reacciones (faciales, corporalez, voz) con tareas, funcionalidades y pantallas específicas.

A continuación esta el material recolectado, el video toma aproximadamente 7 minutos y nos da una gran impresión de la usabilidad de la aplicación.

Click aquí para descargar todo el video.

Repositorio con scripts

https://github.com/NATHA1096/testing-scripts.

• BDT