Estrategia de Pruebas - haroldVirguez/VINYLS-MOBILE GitHub Wiki
📊 Estrategia de Pruebas Spinify – Sprint 1
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: 1.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. Objetivos
| ID | Objetivo |
|---|---|
| OBJ01 | Validar las funcionalidades implementadas correspondientes a las Historias de Usuario HU01 (Consultar catálogo de álbumes) y HU02 (Consultar detalle de á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. |
2.2. Duración de la Iteración de Pruebas
La iteración de pruebas para el Sprint 1 tendrá una duración de 5 días, correspondientes a los últimos días del mismo ciclo de desarrollo del sprint.
Durante este periodo se realizarán las siguientes actividades:
- 2 días: Implementación y ejecución de pruebas manuales
- 2 días: Diseño y ejecución de pruebas E2E automatizadas.
- 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.3. Presupuesto de Pruebas
2.3.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.3.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.3.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.4. TNT (Técnicas, Niveles y Tipos) de Pruebas
A continuación, se describen las técnicas, niveles y tipos de pruebas seleccionados para la estrategia de Spinify.
Estas técnicas se aplicarán sobre las funcionalidades implementadas (HU01 y HU02) y están alineadas con los objetivos definidos en la sección 2.1.
| TNT ID | Técnica | Nivel | Tipos | Objetivo(s) | Justificación |
|---|---|---|---|---|---|
| TNT01 | Prueba manual funcional | Sistema | Enfoque positivo, Caja negra, Exploración | OBJ01, OBJ02 | Evalúa el flujo principal de las historias HU01 y HU02, verificando que las vistas carguen correctamente los datos provenientes del backend y que la interfaz responda de acuerdo con los criterios de aceptación. |
| TNT02 | Pruebas unitarias | Componente | Enfoque positivo, Caja blanca, Funcional | OBJ01, OBJ05 | Se aplican sobre los métodos de la capa ViewModel y Repository para validar la lógica de negocio, transformación de datos y manejo de errores sin depender de la interfaz. |
| TNT03 | Pruebas automatizadas de interfaz (Espresso) | Sistema | Enfoque positivo, Funcional, Caja negra, UI | OBJ01, OBJ02, OBJ05 | Valida automáticamente la correcta comunicación entre la View y el ViewModel, asegurando que la información de los álbumes y sus detalles se renderice correctamente en la interfaz. |
| TNT04 | Pruebas E2E automatizadas (Kraken) | Sistema | Enfoque mixto, Funcional, Caja negra, E2E | OBJ01, OBJ02, OBJ03, OBJ04 | Simula el comportamiento del usuario desde el inicio hasta el detalle de un álbum, comprobando que las capas View, ViewModel y Model funcionen de forma integrada y estable tanto en dispositivos físicos como virtuales. |
2.5. Distribución de Esfuerzo y Responsabilidades
El esfuerzo de pruebas se concentra en los últimos 5 días del Sprint 1, distribuyéndose entre los cuatro integrantes responsables de su ejecución y documentación.
La estrategia prioriza la automatización, complementada con pruebas manuales iniciales y validaciones unitarias sobre la lógica de negocio.
| Actividad | Responsable principal | Duración estimada | Herramienta | Objetivo asociado |
|---|---|---|---|---|
| Pruebas manuales sobre HU01 y HU02 | Daniel Serna | 2 días | Dispositivo físico / Emulador | OBJ01, OBJ02 |
| Pruebas unitarias en ViewModel y Repository | Harold Virgüez | 2 días | JUnit / Mockito | OBJ01, OBJ05 |
| Pruebas automatizadas de interfaz (Espresso) | Jonatan Hernández | 2 días | Android Studio / Espresso | OBJ01, OBJ02, OBJ05 |
| Pruebas E2E automatizadas (Kraken) | Fernando Parra | 2 días | Kraken | OBJ01, OBJ02, OBJ03, OBJ04 |
| Documentación y validación final | Todo el equipo | 1 día | GitHub / Wiki | OBJ03, OBJ04 |
Resumen:
- Días 1–2: pruebas manuales y unitarias (Daniel, Harold)
- Días 3–4: pruebas automatizadas (Jonatan, Fernando)
- Día 5: documentación y cierre colaborativo del equipo