Estrategia de Pruebas 2 - haroldVirguez/VINYLS-MOBILE GitHub Wiki

📊 Estrategia de Pruebas Spinify – Sprint 2

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: 4.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

👉 Diagrama de Componentes

👉Diagrama de Contexto

👉 Modelo de Datos

👉 Modelo de GUI


2. Contexto de la Estrategia de Pruebas

2.1. Actualización general

Durante el Sprint 2, el equipo ampliará la cobertura de pruebas para incluir nuevas historias de usuario, validación de micro-optimizaciones y análisis de desempeño.
El enfoque principal será consolidar la calidad del producto antes del release final, garantizando estabilidad y rendimiento.

2.2. Cambios previstos frente al Sprint 1

  • Cobertura funcional extendida:
    Se incorporarán las HU03 (Consultar listado de artistas), HU07 (Crear álbum) y HU08 (Asociar tracks con álbum), las cuales serán validadas mediante pruebas manuales, unitarias y E2E.

  • Pruebas de rendimiento y perfilamiento:
    Se realizarán mediciones de tiempo de carga, uso de memoria y fluidez de navegación, utilizando el perfilador de Android Studio.
    Los resultados se documentarán en la wiki junto con las micro-optimizaciones aplicadas.

  • Consolidación de pruebas automatizadas:
    Se ampliarán los escenarios E2E con Kraken, abarcando flujos entre los módulos de álbumes, artistas y coleccionistas.
    Se verificarán nuevos casos de estabilidad y manejo de errores en la navegación continua.

  • Validación de release y APK:
    Se ejecutarán pruebas de instalación y funcionamiento sobre el APK, comprobando su compatibilidad desde Android L (5.0) en adelante.


2.3. Objetivos

Los siguientes objetivos guiarán la estrategia de pruebas del Sprint 2, enfocada en validar la integración de los nuevos módulos de artistas y álbumes, así como en medir el rendimiento y la estabilidad general de la aplicación.

ID Objetivo
OBJ01 Validar las funcionalidades implementadas correspondientes a las Historias de Usuario HU03 (Consultar listado de artistas), HU07 (Crear álbum) y HU08 (Asociar tracks con álbum), asegurando que cumplan los criterios de aceptación definidos.
OBJ02 Detectar errores funcionales y de interfaz mediante pruebas manuales, automatizadas de interfaz y E2E, 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 y clasificación del tipo de defecto.
OBJ04 Asegurar la estabilidad de la aplicación en dispositivos físicos y emuladores Android con versiones iguales o superiores a Android Lollipop.
OBJ05 Validar la lógica de negocio y el manejo de datos mediante pruebas unitarias en las capas ViewModel y Repository, garantizando la consistencia de los resultados esperados sin depender de la interfaz de usuario.
OBJ06 Evaluar el rendimiento de la aplicación en escenarios reales midiendo consumo de CPU, memoria y tiempos de respuesta.
OBJ07 Verificar la estabilidad del release final en dispositivos físicos y emuladores.
OBJ08 Validar la interacción entre los módulos de álbumes, artistas y tracks, asegurando la correcta creación y asociación dentro de la aplicación.
OBJ09 Documentar los resultados del perfilamiento y registrar 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 2 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
  • 2 días: Diseño y ejecución de pruebas E2E automatizadas.
  • 2 días 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

El equipo de pruebas estará conformado por:

  • 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

Cada ingeniero contará con su propio entorno de desarrollo y pruebas, incluyendo equipos físicos y emuladores configurados con Android Studio.

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 para la Contratación de Servicios/Personal

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) de Pruebas

TNT ID Técnica Nivel Tipo Objetivo(s) Justificación
TNT01 Prueba manual exploratoria Sistema Funcional, regresión OBJ01, OBJ02, OBJ08 Permitirá asegurar que las nuevas historias (HU03–HU07–HU08) funcionen correctamente y no afecten las funcionalidades existentes.
TNT02 Pruebas unitarias ampliadas Componente Caja blanca OBJ05, OBJ08 Incrementará la cobertura en los ViewModels y Repositories de artistas y álbumes.
TNT03 Pruebas E2E con Kraken Sistema E2E, flujo completo OBJ01, OBJ02, OBJ03, OBJ04, OBJ07, OBJ08 Simulará la interacción integral del usuario entre los módulos de artistas y álbumes, comprobando la estabilidad del flujo de creación y asociación de tracks.
TNT04 Pruebas de desempeño y perfilamiento Sistema No funcional, rendimiento OBJ06, OBJ09 Permitirá identificar posibles cuellos de botella y oportunidades de optimización en la interfaz y el consumo de recursos.

2.7. Distribución de Esfuerzo y Responsabilidades – Sprint 2

El esfuerzo de pruebas se concentrará en los últimos 5 días del Sprint 2, manteniendo la planificación anterior pero incluyendo validaciones de rendimiento y estabilidad.
La estrategia seguirá priorizando la automatización, pero ahora incorporará pruebas de perfilamiento, regresión funcional y verificación del release final.

Actividad Responsable principal Duración estimada Herramienta Objetivo asociado
Pruebas manuales exploratorias sobre HU03–HU07–HU08 Jonatan Hernández 1 día Dispositivo físico / Emulador OBJ01, OBJ02, OBJ08
Pruebas unitarias ampliadas (ViewModel y Repository de artistas y coleccionistas) Harold Virgüez 1 día JUnit OBJ05, OBJ08
Pruebas E2E completas y regresión (Kraken) Fernando Parra 2 días Kraken OBJ02, OBJ03, OBJ04, OBJ07, OBJ08
Pruebas de rendimiento y perfilamiento Daniel Serna 1 día Android Profiler / ADB / GitHub Wiki OBJ06, OBJ09
Documentación final de resultados y issues Todo el equipo 1 día GitHub / Wiki / Markdown OBJ03, OBJ09

Resumen del cronograma de trabajo:

  • Día 1: Pruebas manuales y unitarias (Daniel, Harold).
  • Días 2-3: Pruebas automatizadas de interfaz y E2E (Jonatan, Fernando).
  • Días 4: Perfilamiento y análisis de rendimiento (Daniel, Fernando).
  • Día 5: Documentación final, consolidación de resultados y registro de issues.

3. Conclusión

La estrategia de pruebas del Sprint 2 ampliará el alcance de validación funcional y de calidad, integrando aspectos de rendimiento, estabilidad y documentación técnica.