Plan_pruebas_vinilos v3 - MISW-4203-2023/Vinilos GitHub Wiki
Estrategia de Pruebas
1. Aplicación Bajo Pruebas
1.1. Nombre Aplicación: Vinilos (Android App)
1.2. Versión: 1.0.0
1.3. Descripción: Vinilos es una aplicación móvil diseñada exclusivamente para dispositivos Android. Esta innovadora app está diseñada para satisfacer las necesidades de los coleccionistas de música, permitiendo a los amantes de la música mantener un registro completo de sus colecciones. Con Vinilos, puedes consultar y registrar datos relacionados con álbumes, colecciones y artistas.
1.4. Funcionalidades Core:
- Consultar catálogo de álbumes
- Consultar la información detallada de un álbum
- Consultar el listado de artistas
- Consultar la información detallada de un artista
- Consultar listado de coleccionista
- Consultar la información detallada de coleccionista
- Crear un álbum
- Agregar Artistas a favoritos
1.5. Diagrama de Arquitectura:
1.6. Diagrama de Contexto:
1.7. Modelo de GUI:
2. Contexto de la estrategia de pruebas
2.1. Objetivos:
-
Evaluar el cumplimiento de los atributos de calidad de las funcionalidades core sobre la interfaz de usuario mediante la implementación de pruebas manuales, pruebas automatizadas e2e y pruebas unitarias.
-
Validar el correcto funcionamiento de la aplicación para las funcionalidades core.
-
Identificar y documentar errores sobre las funcionalidades core del sistema.
-
Documentar las funcionalidades core de la aplicación.
-
Establecer métricas específicas para evaluar el rendimiento, identificar posibles cuellos de botella y optimizar el sistema para ofrecer una experiencia de usuario óptima.
-
Asegurar un rendimiento eficiente de la aplicación bajo diversas cargas esenciales. Esto implica la realización de pruebas de carga para evaluar la capacidad de respuesta del sistema, identificar y resolver posibles cuellos de botella, y comparar los resultados con métricas de rendimiento predefinidas para garantizar el cumplimiento de los estándares.
-
Garantizar una experiencia inclusiva para todos los usuarios al realizar pruebas específicas de accesibilidad. Esto implica la evaluación conforme a pautas reconocidas, identificación y corrección de barreras de acceso, y la colaboración con usuarios con discapacidades para obtener retroalimentación directa y realizar ajustes necesarios.
2.2. Duración de la iteración de pruebas:
La duración del sprint será de dos semanas a partir del lunes 20 de noviembre al viernes 1 de diciembre, dedicando una intensidad de 32 horas por sprint.
| # | Actividad | Responsable | Objetivos | Fecha Inicio | Fecha Entrega | Horas Personas |
|---|---|---|---|---|---|---|
| 1 | Realizar pruebas manuales sobre la interfaz. | Tester 1 | 1,2 | 06/11/23 | 17/11/23 | 1 |
| 2 | Desarrollar las pruebas unitarias para el repository y el view Model | Tester 2, Tester 3, Tester 4 | 1,2 | 20/11/23 | 1/12/23 | 2,5,5 |
| 3 | Desarrollar las pruebas automatizadas E2E sobre la navegación de las pantallas. | -Tester 2 | 1,2 | 20/11/23 | 1/12/23 | 4 |
| 4 | Desarrollar las pruebas automatizadas E2E sobre la interfaz de las pantallas. | Tester 1 | 1,2 | 20/11/23 | 1/12/23 | 4 |
| 5 | Documentar y analisar el desempeño en memoria, cpu y red de la aplicación. | Tester 2, Tester 3, Tester 4 | 1,2,6 | 20/11/23 | 1/12/23 | 4 |
| 6 | Documentar y Desarrollar las pruebas de accesibilidad de la aplicación | Tester 1 | 1,2,7 | 20/11/23 | 1/12/23 | 4 |
| 7 | Desarrollar plan de pruebas automatizadas con Monkey test | Tester 1, Tester 2 | 1,2 | 20/11/23 | 1/12/23 | 2,2 |
| 8 | Documentar las incidencias encontradas en la aplicación | Tester 1, Tester 3 | 3 | 20/11/23 | 1/12/23 | 1,3 |
| 97 | Documentar las incidencias encontradas en la aplicación | Tester 4 | 4 | 20/11/23 | 1/12/23 | 3 |
**2.3. Presupuesto de pruebas: **
2.3.1. Recursos Humanos Se espera contar con 4 ingenieros o profesional a fin al desarrollo de software con una experiencia entre 1 y 2 año en la ejecución de pruebas automatizadas.
- 4 ingenieros automatizadores (32 Horas/persona)
El valor de un ingeniero tester automatizador es de $15.110 hora*
2.3.2. Recursos Computacionales
- Recursos de Software:
- Android Studio Giraffe | 2022.3.1 Patch 2
- Android SDK 9.0 y 12.0
- Windows 10 y 11
- Java
- Docker
- App pruebas accesibilidad
- Talkback
- Recursos de Hardware:
**Computadores **
- Equipo 1: Computador portatil con Win 11 Pro. 32gb de Ram, Core i9.
- Equipo 2: MacBook Pro, Chip M2 Max, 64 GB RAM, macOs Sonoma V14.0
- Equipo 3: Computador portatil con Win 10, 16 Ram, core i5
- Equipo 4: Portátil con Win 11, 16gb de Ram, Core i7
Dispositivos Móviles
- Emulador: Pixel_3a_API_33_x86_64
- Emulador: Pixel_5_API_33
- Dispositivo Fisico: Android versión 13, versión de One UI 5.1
2.4. TNT (Técnicas, Niveles y Tipos) de pruebas:
| Nivel | Tipo | Técnica | Objetivo |
|---|---|---|---|
| Sistema | Funcionales | Manuales | 1,2 |
| Sistema | Funcionales | Pruebas Unitarias | 1,2 |
| Sistema | Funcionales | Automatizadas E2E (Expresso y Monkey test) | 1,2 |
| Sistema | Funcionales | Pruebas Accesibilidad (Talkback y App. Pruebas de accesibilidad) | 1,2,6,7 |
2.5. Distribución de Esfuerzo
Teniendo en cuenta que los objetivos van a dirigidos a verificar el funcionamiento la aplicación, hemos decidido usar el patrón pirámide de automatización, específicamente en esta iteración nos centraremos en las pruebas automatizadas e2e por medio de expreso, además de las pruebas unitarias, por último, dedicaremos un poco menos de esfuerzo en las pruebas manuales.
Es importante recordar que este patrón sugiere que se debería dedicar más esfuerzo a las pruebas automatizadas y a los niveles de mayor granularidad, dado que a medida que uno sube de nivel de granularidad las pruebas son más costosas y demoradas.
| # | Actividad | Responsable | Objetivos | Fecha Inicio | Fecha Entrega | Horas |
|---|---|---|---|---|---|---|
| Pruebas manuales | Realizar pruebas manuales sobre la interfaz. | Tester 1 | 1,2 | 20/11/23 | 1/12/23 | 1 |
| Pruebas unitarias | Desarrollar las pruebas unitarias para el repository y el view Model | Tester 2, Tester 3, Tester 4 | 1,2 | 20/11/23 | 1/12/23 | 12 |
| Pruebas automatizadas E2E | Desarrollar las pruebas automatizadas E2E sobre la navegación de las pantallas. | -Tester 2 | 1,2 | 20/11/23 | 1/12/23 | 6 |
| Desarrollar las pruebas automatizadas E2E sobre la interfaz de las pantallas. | Tester 1 | 1,2 | 20/11/23 | 1/12/23 | 6 | |
| Desarrollar plan de pruebas automatizadas con Monkey test | Tester 1, Tester 2 | 1,2 | 20/11/23 | 1/12/23 | 4 | |
| Pruebas accesibilidad | Desarrollar las pruebas de accesibilidad (Talkback y App. Pruebas de accesibilidad) | -Tester 1 | 1,2,7 | 20/11/23 | 1/12/23 | 6 |
3. Analisis de Desempeño
Para nuestra validación de desempeño de la aplicación se hizo uso de Profiler que es una herramienta integrada en Android Studio que permite analizar el rendimiento de la aplicación en términos de uso de CPU, memoria, red y otros recursos.
-
CPU Profiler: permite analizar el uso de la CPU por parte de la aplicación. Se puede ver el tiempo que se gasta en cada método y función, lo que ayuda a identificar cuellos de botella y optimizar el rendimiento.
-
Memory Profiler: ayuda a analizar el uso de la memoria en la aplicación. Se puede identificar las asignaciones de memoria, los objetos no utilizados y otros problemas de gestión de memoria.
-
Network Profiler: Permite analizar el tráfico de red de la aplicación. Se puede ver las solicitudes HTTP, el tiempo de respuesta y otros detalles relacionados con la red.
-
GPU Profiler: ayuda a analizar el rendimiento gráfico de la aplicación. Se puede identificar problemas relacionados con la renderización y la GPU.
-
Energy Profiler: Muestra información sobre el consumo de energía de la aplicación, lo que es crucial para aplicaciones móviles que deben ser eficientes en términos de energía.
4. Revisión de Accesibilidad
Implementamos TalkBack, una funcionalidad de lectura de pantalla para personas con discapacidad visual. Además, utilizamos una aplicación de pruebas de accesibilidad (AccessibilityScanner) para evaluar exhaustivamente la interfaz de usuario. Esta combinación de herramientas nos permitió identificar y abordar posibles barreras de accesibilidad, asegurando que nuestra aplicación sea inclusiva y accesible para todos los usuarios, cumpliendo así con los estándares de usabilidad y facilitando una experiencia positiva para cada usuario, independientemente de sus capacidades.