Resultados estrategia sprint2
Se deja evidencia de la ejecución de las pruebas funcionales de las Historias de usuario HU03 (Listar Artistas), HU05 (Listar coleccionistas) y HU08 (Asociar tracks a un album) en un dispositivo físico, instalando la aplicación desde el APK generado en el release v2.0.
Enlace al vídeo
-
Para estas pruebas se utilizo la plataforma de servicios en la nube Firebase. En la cual se introdujo el APK de la versión 2 de la aplicación.
-
Se escogio como dispositivo un Nexus 5 de caracteristicas virtuales con nivel de API 22
-
A continuación se encuentra el link del video de los pasos realizados por las pruebas ROBO
Enlace al vídeo
En el video se puede apreciar una cantidad significante de eventos que validan el correcto funcionamiento de la app. Sobretodo para las HU de interes de los sprint 1 y 2.
-
También se pueden resumir los estados o pasos realizados en las pruebas con el siguiente diagrama:
-
Las pruebas arrojaron resultados favorables y sin issues significativos. Se realizaron en total 262 acciones y se visitaron 27 pantallas en total. Lo anterior se puede corroborar en el siguiente link, el cual contiene todos los registros de los eventos realizados: Enlace los registros
-
Las estadisticas de rendimiento en dispositivos virtuales no son compatibles con Test lab. Por lo anterior, y para conocer mas a detalle sobre éstas metricas, remitirse a la sección de pruebas de perfilamiento realizados en Android-Studio.
-
Se encontraron 10 problemas menores relacionados al atributo de accesibilidad de la aplicación. Mas especificamente relacionados a contraste bajo y etiquetas de contenido.
Se realizan las pruebas E2E con Espresso con resultados satisfactorios, para las HU03 (Lista de artistas), HU05 (Lista de colecionistas) y HU08 (Asociar un track a un álbum), obteniendo las siguientes evidencias sobre la ejecución en el IDE.
Enlace al vídeo
- Se procedió a observar distintos eventos en la aplicación en 3 dispositivos diferentes para detectar posibles areas de mejoras u optimizaciones a se realizadas.
- Los dispositivos utilizados fueron:
| Dispositivo | API |
|---|---|
| Emulador de Android | API 30 |
| Xiaomi K20 Pro | API 28 |
| SM-G610M | API 24 |
| Mi 10T | API 26 |
- Posteriormente se observaron los resultados y se compararon las gráficas proporcionadas por el Profiler.
Los eventos probados por Historias de Usuario fueron los siguientes:
| HU | Descripción | Observaciones |
|---|---|---|
| 01 | Se ingresa a la vista de Álbumes cargando la lista del RecycleView | No se observa un aumento considerable en en uso de CPU o algún posible leak de memoria. Sin Embargo, se observa que el scroll de items en la lista no funciona de manera adecuada. |
| 01-AD1 | Se ingresa a la vista de Álbumes cargando una lista de mas álbumes con imágenes de alta resolución | No se observa un aumento considerable en en uso de CPU o algún posible leak de memoria. Pero aumenta considerablemente el uso de Red en la aplicación y se observan picos de uso en los cambios de pestañas. |
| 02 | Se ingresa al detalle de Álbumes cargando sus componentes. Ej. Lista de Canciones | No se observa un aumento considerable en en uso de CPU o algún posible leak de memoria. Se observa también cierto retraso al navegar por el ScrollView. En este caso se observa un aumento en el uso de RAM y RED. |
| 03 | Se ingresa a la vista de Artistas | No se observa un aumento considerable en en uso de CPU o algún posible leak de memoria. |
| 05 | Se ingresa a la vista de listado de Coleccionistas | No se observa un aumento considerable en en uso de CPU o algún posible leak de memoria. Se observa un aumento en la actividad de CPU y Red al cambiar entre pestañas debido a la carga de datos. |
| 08 | Se ingresa evento para asociar track con álbum | No se observa un aumento considerable en en uso de CPU o algún posible leak de memoria. |
Nota #1 : Se observa una relación en el aumento de uso de Energía en el dispositivo proporcional al número de peticiones web ejecutadas en los eventos. Y se decide optimizar el consumo del API que tiene la aplicación.
La aplicación se ve penalizada en aspectos como la Memoria y Red cuando las listas de items tienden a ser grandes en cualquiera de las vistas. Por lo que se considera necesario en general las siguientes acciones para mejorar el comportamiento:
- Reducir la cantidad de peticiones aplicando una táctica de caching que se realizan sobre todo entre cambios de pestañas.
- Optimizar el uso de imágenes en las listas en tamaño y también en la librería Picasso.
- Aplicar Corrutinas en las listas donde se prevee tener una grand cantidad de Items como Coleccionistas y Álbumes.
- Fixes en el Uso de los Scrollview que se encuentran anidados ya que con pocos items la lista no scrollea de manera correcta y se sospecha que esto también puede causar problemas de rendimiento con una lista mas grande.
- El issue de optimización para carga de imágenes se pospondrá al siguiente sprint ya que aún no se tiene control sobre el tipo de imágenes que se ingresan a la aplicación y sera implementado en las HU del 3er sprint.
Ver anexo con imagenes del perfilamiento: https://uniandes-my.sharepoint.com/:w:/g/personal/ef_luna442_uniandes_edu_co/ERWAwZIjVOBKqnP8JHDTb84Blwv4eeSmMj9aEU-CHaauwA