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

• Crear worker para ejecutar los scripts de Calabash
• Generar scripts para nuevas funcionalidades.
• Detectar nuevos defectos de la aplicación a través de pruebas BDT.
• Ejecutar pruebas utilizando una matriz de dispositivos.
• Insertar mutantes utilizando la herramienta mutAPK.
• Generación de reportes sobre las pruebas realizadas.
• Pruebas del app sin conexión.

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
• Editar tareas
• Eliminar tareas
• Crear equipo
• Invitar amigos a un equipo
• Editar equipo
• Invitar a una mision
• Visualizar miembros del equipo
• Enviar mensajes a miembros del equipo
• Crear un desafío
• Unirse a un desafío
• Editar un desafío
• Elegir un ganador para un desafío
• Terminar un desafío
• Abandonar misión
• Eliminar equipo

Tipos y niveles de pruebas

Las pruebas a realizar son pruebas a nivel sistema de tipo BDT sobre 25 funcionalidades de la aplicación móvil utilizando la herramienta calabash. Para esta iteración hemos decidido implementar nuevas pruebas para intentar detectar más defectos sobre la aplicación, adentrandonos en otras características.

Resultados

Al correr un set de pruebas de las 25 funcionalidades, hemos encontrado 18 nuevos 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 el escenario para posiblemente poder reproducirlo ya que son errores no recurrentes. Cada reporte cuenta con su imagen adjunta que indica en que parte del proceso se puedo encontrar la inconsistencia.

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 nuevamente fallaban con la instrucción de dar click orientado a ciertas partes de la pantalla, 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 otra parte hemos trabajado con nuestro worker para correr unos scripts basicos y las pruebas ha sido satisfactorias, aunque lo tenemos orientado a prueba por script, aun no se asocia un pull de scripts, finalmente tambien es necesario antes de ejecutar el worker validar que exista un emulador corriendo o que este conectado un dispositivo asociado al PC. Despues de realizar mas scripts quedamos con algunos interrogantes como, ¿Existen mas alternativas a los click por zona o a ubicar el elemento por su nombre en el DOM?, ¿Que se debe hacer cuando en los scripts se piden llenar listas dinamicas y no logramos ubicar el elemento en el DOM como un textbox sencillo, habria que crear step definition para llenarlo?.

Se realizaron pruebas de la aplicación con conexión a red de manera itermitente, lo cual fue el detonante para encontrar mas del 80% de los errores que se documentaron.

Por ultimo queremos hacer mención a la implementación de generación de datos por medio ruby para el script de creación de usuario el cual ha sido satisfactorio ya que el script quedo 100% reutilizable.

Click aqui para descargar directamente el video.

MutAPK

Teniendo en cuenta que el tutor realizó una modificación sobre la herramienta mutAPK, fué posible generar los mutantes para la aplicación móvil de habítica ya que en el pasado sprint no se había podido por errores que quedaron documentados en el siguiente LINK-Sprint 4.

Para este caso se generaron 10 mutantes por medio de la siguiente instrucción:

java -jar .\target\MutAPK-0.0.1.jar .\com.habitrpg.android.habitica.apk com.habitrpg.android.habitica .\mutants\ .\extra\ .\ true 10

En la siguiente imagen se aprecian los resultados:

Para la configuración de los operadores de mutación escogimos 4 los cuales tenian que ser de tipo AST para que funcionaran con esta herramienta:

Operadores de mutación
2 = DifferentActivityIntentDefinition
4 = InvalidKeyIntentPutExtra
6 = NullIntent
7 = NullValueIntentPutExtra

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

Cantidad de mutantes generados:

Tipo de mutante	Cantidad de mutantes
DifferentActivityIntentDefinition	1
InvalidKeyIntentPutExtra	1
NullIntent	1
NullValueIntentPutExtra	7

Enlaces para ver un ejemplo de mutante generado para cada operador:

DifferentActivityIntentDefinition

InvalidKeyIntentPutExtra

NullIntent

NullValueIntentPutExtra

Finalmente de los mutantes, lo de tipo NullValueIntentPutExtra no generaron un APK y de los 3 restantes, hubo uno que se considero como no nacido, ya que al intentar ejecutar el app, la aplicación se reinicia y los 2 restantes mantienen vivos sus defectos, ya que no fueron detectados.

Repositorio con scripts

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

• BDT