Estrategia de Pruebas 3 - haroldVirguez/VINYLS-MOBILE GitHub Wiki
📊 Estrategia de Pruebas Spinify – Sprint 3
MISW4203 – Ingeniería de Software Móvil
👥 Integrantes Equipo 3
- Daniel Serna
- Jonatan Hernández
- Harold Virgüez
- Fernando Parra
1. Aplicación Bajo Pruebas
1.1. Nombre de la Aplicación: Spinify
1.2. Versión: 5.0
1.3. Descripción
Spinify es una aplicación móvil que permite a los usuarios explorar y gestionar información sobre el mundo musical de forma organizada y atractiva.
La plataforma está dirigida tanto a visitantes, interesados en descubrir artistas y álbumes, como a coleccionistas registrados, que pueden enriquecer el catálogo y compartir sus gustos musicales.
Los usuarios visitantes pueden navegar por un catálogo interactivo de álbumes, consultar su información detallada, acceder al listado de artistas y conocer sus perfiles con biografía, obras y reconocimientos.
Además, tienen la posibilidad de explorar el listado de coleccionistas, visualizando sus preferencias y estilos musicales.
Por su parte, los coleccionistas pueden crear y administrar contenido dentro del sistema: registrar nuevos álbumes, asociar tracks a cada uno, comentar obras musicales, definir sus artistas favoritos, y gestionar su propia colección agregando álbumes para exhibir o intercambiar.
También pueden actualizar la información de los artistas, agregar músicos a bandas, crear y asociar premios y reconocimientos otorgados por distintas organizaciones.
Spinify integra estas funcionalidades dentro de una interfaz moderna que facilita la búsqueda, filtrado y visualización de álbumes, artistas y coleccionistas, ofreciendo una experiencia centrada en la exploración musical y la participación de los usuarios.
1.4. Funcionalidades Core
🎵 Álbum
- Catálogo de álbumes: Permite a los usuarios navegar por un catálogo visual e interactivo de álbumes, con opciones de búsqueda y filtrado.
- Detalle de álbum: Muestra información completa de un álbum: nombre, carátula, descripción, fecha de lanzamiento, género, editorial, artista y lista de tracks.
- Creación de álbumes: Permite a los coleccionistas agregar nuevos álbumes al catálogo con sus datos correspondientes.
- Comentarios de álbumes: Permite a los usuarios escribir opiniones o reseñas sobre los álbumes.
- Asociación de tracks: Posibilita agregar o editar las canciones que conforman un álbum.
👩🎤 Artistas
- Listado de artistas: Presenta todos los artistas registrados, con opciones para seleccionar y consultar sus perfiles individuales.
- Detalle de artista: Despliega la biografía, fotografía, fechas relevantes (nacimiento o formación) y premios asociados a un artista.
- Gestión de artistas favoritos: Los coleccionistas pueden seleccionar y mostrar sus artistas favoritos dentro de su perfil.
- Asociación de álbumes a artistas: Facilita la relación entre álbumes y artistas, asegurando que cada obra esté correctamente atribuida.
- Asociación de músicos a bandas: Permite actualizar la composición de una banda, agregando o editando los músicos que la integran.
💽 Coleccionistas
- Listado de coleccionistas: Permite visualizar los perfiles públicos de coleccionistas registrados en la aplicación.
- Detalle de coleccionista: Muestra información del coleccionista, incluyendo sus artistas favoritos y álbumes asociados.
- Gestión de colección personal: Los coleccionistas pueden agregar álbumes a su colección para exhibir, vender o intercambiar.
🏆 Premios
- Creación de premios: Los coleccionistas pueden registrar nuevos premios o reconocimientos otorgados en el sistema.
- Asociación de premios a artistas: Permite vincular premios creados con los artistas correspondientes.
1.5. Arquitectura
2. Contexto de la Estrategia de Pruebas
2.1. Actualización general
La estrategia de pruebas del Sprint 3 incorpora:
- Validación completa de HU04, HU05 y HU06
- Pruebas de reconocimiento (exploración sistemática y aleatoria / Monkey)
- Pruebas E2E para los nuevos flujos
- Validación de accesibilidad con AccessibilityScanner
- Nuevas pruebas de rendimiento en vistas de artista y coleccionista
2.2. Cambios frente al Sprint 2
- Nuevas historias de usuario añadidas al plan: HU04, HU05, HU06
- Pruebas de reconocimiento obligatorias (sistemáticas y aleatorias)
- Inclusión formal de validación de accesibilidad
- Extensión del perfilamiento a nuevas pantallas y flujos
- Expansión de pruebas E2E con Kraken
2.3. Objetivos
| ID | Objetivo |
|---|---|
| OBJ01 | Validar las funcionalidades implementadas correspondientes a las Historias de Usuario HU03, HU07 y HU08, y ahora también HU04 (Detalle de artista), HU05 (Listado de coleccionistas) y HU06 (Detalle de coleccionista), asegurando que todas cumplan los criterios de aceptación definidos. |
| OBJ02 | Detectar errores funcionales y de interfaz mediante pruebas manuales, automatizadas de interfaz, E2E y pruebas de reconocimiento (exploración sistemática y aleatoria), garantizando la correcta interacción entre la View, el ViewModel y el consumo del servicio remoto. |
| OBJ03 | Registrar y documentar los hallazgos encontrados durante las pruebas, incluyendo evidencias, pasos de reproducción, defectos detectados, hallazgos de accesibilidad y problemas encontrados mediante pruebas de reconocimiento. |
| OBJ04 | Asegurar la estabilidad de la aplicación en dispositivos físicos y emuladores Android con versiones iguales o superiores a Android Lollipop, incluyendo flujos ampliados de artistas y coleccionistas. |
| OBJ05 | Validar la lógica de negocio y el manejo de datos mediante pruebas unitarias en las capas ViewModel y Repository, incluyendo las nuevas funcionalidades de artista y coleccionistas, garantizando la consistencia sin depender de la UI. |
| OBJ06 | Evaluar el rendimiento de la aplicación en escenarios reales midiendo consumo de CPU, memoria, tiempos de carga y desempeño en el acceso a detalle de artista y coleccionista. |
| OBJ07 | Verificar la estabilidad del release final en dispositivos físicos y emuladores, incluyendo validación post–E2E y pruebas de reconocimiento. |
| OBJ08 | Validar la interacción entre los módulos de álbumes, artistas, tracks y ahora coleccionistas, asegurando la correcta navegación, asociación y visualización entre todas las partes del sistema. |
| OBJ09 | Documentar los resultados del perfilamiento, accesibilidad y pruebas de reconocimiento, registrando los hallazgos como issues en el repositorio. |
2.4. Duración de la Iteración de Pruebas
La iteración de pruebas para el Sprint 3 tendrá una duración de 6 días, correspondientes a los últimos días del mismo ciclo de desarrollo del sprint. Durante este periodo se realizarán las siguientes actividades:
- 1 día: Implementación y ejecución de pruebas manuales
- 1 día: Diseño y ejecución de pruebas E2E Kraken.
- 1 día: Diseño y ejecución de pruebas Reconocimiento.
- 1 día: Ejecución de pruebas Accesibilidad.
- 1 día Perfilamiento y análisis de rendimiento.
- 1 día: Documentación y consolidación de resultados.
El tiempo total estimado es de 20 horas de trabajo distribuido entre los cuatro integrantes encargados de las pruebas.
2.5. Presupuesto de Pruebas
2.5.1. Recursos Humanos
- 1 Ingeniero senior
- 2 Ingenieros mid
- 1 Ingeniero junior
Se tendrá una dedicación aproximada de 8 horas semanales cada uno. Cada ingeniero será responsable de ejecutar, documentar y reportar los resultados de las pruebas asignadas.
Perfil del equipo:
- Conocimiento en Android (Kotlin, MVVM, Retrofit) y consumo de APIs REST.
- Experiencia básica en herramientas de prueba como Espresso y Kraken.
- Familiaridad con GitHub, Kanban, y gestión de issues para seguimiento de defectos.
2.5.2. Recursos Computacionales
Equipos disponibles:
| Equipo | Procesador / Chip | Núcleos | Memoria RAM | Almacenamiento | Sistema Operativo |
|---|---|---|---|---|---|
| LG Gram | Intel® Core™ i7-1360P (13th Gen) | 12 núcleos | 16 GB | 512 GB SSD | Windows 11 |
| MacBook Pro 14" | Apple M4 | 10 núcleos | 16 GB | 512 GB SSD | macOS Sonoma |
| MacBook Pro 14" | Apple M4 Pro | 14 núcleos | 24 GB | 512 GB SSD | macOS Sonoma |
| MacBook Pro 14" | Apple M3 Pro | 12 núcleos | 36 GB | 512 GB SSD | macOS Sonoma |
Entorno de ejecución:
| Dispositivo | Versión | Nombre Comercial | API Level | Resolución | Físico | Virtual |
|---|---|---|---|---|---|---|
| Pixel Original | 12.0 | Android 12 | 31 | 1080 × 1920 | ✅ | |
| Motorola Moto G6 Plus | 9.0 | Pie | 28 | 1080 × 2160 | ✅ |
- Conexión al backend NestJS para obtención de datos reales
- Repositorio GitHub con control de versiones y documentación
2.5.3. Recursos Económicos
No se contempla la contratación de personal ni la adquisición de servicios externos.
El equipo actual asumirá las tareas de planeación, ejecución y documentación de las pruebas dentro de las horas asignadas al Sprint.
El presupuesto total de pruebas se limita al uso de recursos internos del equipo y herramientas gratuitas del ecosistema Android (Android Studio, Kraken, Espresso, GitHub Actions).
2.6. TNT (Técnicas, Niveles y Tipos) – Sprint 3
| TNT ID | Técnica | Nivel | Tipo | Objetivo(s) | Justificación |
|---|---|---|---|---|---|
| TNT01 | Prueba manual exploratoria | Sistema | Funcional | OBJ01, OBJ02, OBJ08 | Validar HU04–HU05–HU06 y asegurar funcionamiento de flujos completos. |
| TNT02 | Pruebas unitarias | Componente | Caja blanca | OBJ05 | Valida consistencia en lógica de negocio. |
| TNT03 | Pruebas E2E con Kraken | Sistema | E2E | OBJ02, OBJ04, OBJ07 | Garantizar interacción integrada entre módulos. |
| TNT04 | Pruebas de desempeño y perfilamiento | Sistema | No funcional | OBJ06, OBJ09 | Detectar cuellos de botella en vistas nuevas. |
| TNT05 | Pruebas de reconocimiento sistemáticas | Sistema | Reconocimiento | OBJ02, OBJ03, OBJ07 | Recorrido estructurado detectando estados no previstos. |
| TNT06 | Pruebas de reconocimiento aleatorias (Monkey) | Sistema | Reconocimiento | OBJ02, OBJ04 | Validar robustez ante interacciones inesperadas. |
| TNT07 | Pruebas de accesibilidad (AccessibilityScanner) | Sistema | Accesibilidad | OBJ03, OBJ09 | Identificar problemas de contraste, legibilidad y etiquetas. |
2.7. Distribución de Esfuerzo y Responsabilidades – Sprint 3
Para el Sprint 3, el esfuerzo de pruebas se distribuye en 6 días, alineado con las actividades definidas para esta iteración:
pruebas manuales, E2E, reconocimiento, accesibilidad, perfilamiento y documentación.
Cada día se asigna de forma clara a una actividad principal para asegurar foco, cobertura completa y coherencia con los objetivos del sprint.
| Actividad | Responsable principal | Duración estimada | Herramienta(s) | Objetivo asociado |
|---|---|---|---|---|
| Ejecución de pruebas manuales (HU04, HU05, HU06) | Jonatan Hernández | 1 día | Dispositivo físico / Emulador | OBJ01, OBJ02, OBJ08 |
| Pruebas E2E Kraken para flujos de artistas y coleccionistas | Fernando Parra | 1 día | Kraken / Appium | OBJ02, OBJ04, OBJ07, OBJ08 |
| Pruebas de reconocimiento (sistemáticas + Monkey) | Todo el equipo | 1 día | Monkey / Recorridos guiados | OBJ02, OBJ03, OBJ07 |
| Validación de accesibilidad | Fernando Parra | 1 día | AccessibilityScanner | OBJ03, OBJ09 |
| Pruebas de perfilamiento y rendimiento | Daniel Serna | 1 día | Android Profiler / ADB | OBJ06, OBJ09 |
| Documentación, consolidación y registro de issues | Todo el equipo | 1 día | GitHub / Wiki / Markdown | OBJ03, OBJ09 |
Resumen del cronograma de trabajo:
- Día 1: Pruebas manuales (Jonatan)
- Día 2: Pruebas E2E con Kraken (Fernando)
- Día 3: Pruebas de reconocimiento (Todo el equipo)
- Día 4: Validación de accesibilidad (Fernando)
- Día 5: Perfilamiento y análisis de rendimiento (Daniel)
- Día 6: Documentación final + issues (Todo el equipo)
3. Conclusión
La estrategia de pruebas del Sprint 3 amplía la cobertura funcional, incorpora pruebas de reconocimiento y accesibilidad por primera vez, y fortalece la validación de rendimiento y estabilidad de Spinify.