Software Quality Assurance Plan (SQAP)

1. Propósito

El propósito de este Plan de Aseguramiento de Calidad del Software (SQAP) es establecer los procedimientos, estándares y responsabilidades necesarios para garantizar que nuestro videojuego Feudalia cumpla con los requisitos funcionales, de rendimiento y de diseño establecidos. Este plan asegura la entrega de un producto estable y con altos niveles de fiabilidad, rendimiento y usabilidad dentro del plazo de desarrollo de 3 meses, manteniendo la sencillez e intuitividad necesarias para el público objetivo, y adhiriéndose a las restricciones técnicas (motor gráfico y lenguaje) y de contenido (PEGI 12).

En suma, el SQAP busca:

• Asegurar la coherencia y estabilidad del código.
• Garantizar que las interfaces gráficas sean funcionales, claras y cumplan los requisitos técnicos y estéticos acordados.
• Reducir errores mediante revisiones sistemáticas y pruebas continuas.
• Documentar adecuadamente cada etapa del desarrollo.
• Más

2. Documentos de Referencia

(Falta añadir enlaces y escribir alguno de los documentos. Poner en formato de tabla con ID de documento)

ID de Documento	Título	Descripción / Propósito	Vínculo al Documento Wiki
REQ-001	Descripción General del Proyecto	Define el propósito, género (RTS / Gestión / Rol), público objetivo y funciones principales (Vista de ciudad, Multijugador, Combate centralizado).	Ver Documento
DES-001	Documento de Diseño de Juego (GDD)	Especificaciones detalladas de la jugabilidad, mecánicas de recursos y sistema de combate de ataque/defensa.	Ver Documento
PLN-001	Cronograma de Desarrollo	Planificación de 4 meses con fecha de lanzamiento objetivo el 12 de diciembre de 2025.	-
STD-001	Estándares de Codificación de Código Abierto	Guías de estilo y convenciones para el lenguaje de programación y el motor gráfico seleccionados.	Ver Documento
POL-001	Pautas de Contenido PEGI 12	Criterios para asegurar que el contenido se adhiere a la clasificación de edad establecida.	Ver Documento

3. Gestión

3.1. Organización y Responsabilidades

• Líder de QA: supervisar las pruebas, mantener registros y aprobar versiones estables.
• Programadores: seguir estándares de codificación, ejecutar pruebas unitarias y corregir errores.
• Diseñadores: validar la coherencia visual y la usabilidad.
• Gestor de proyecto: aprobar los hitos de calidad y coordinar el ciclo de revisiones.

3.2. Independencia de SQA

La función de SQA recae principalmente en el Scrum Master y en la revisión por pares obligatoria. La independencia se garantiza mediante:

• Revisión Cruzada: Ningún desarrollador puede aprobar su propio código para la rama principal (main).
• Informes Públicos: El sistema de GitHub Issues permite al equipo auditar de forma transparente el estado y la resolución de los problemas de calidad.

4. Documentación

4.1. Documentación de Desarrollo

• GDD (Game Design Document) : Ver Documento
• SRS (Software Requirements Specification) Ver Documento
• Plan de pruebas Ver Documento
• Código Fuente

4.2. Documentación del Usuario

• README y Guía de Contribución Ver Documento
• Manual de Juego/Usuario

5. Estándares, Prácticas, Convenciones y Métricas (Sección 5 del SQAP) - (Corresponde a 4.5)

5.1. Estándares y Convenciones

Codificación C#:

• Estandar de codificación
• Uso de comentarios XML para documentación de métodos públicos.
• Principio de Responsabilidad Única (SRP): Cada clase o nodo Godot debe tener una sola responsabilidad bien definida.

Prácticas de Calidad:

• Uso obligatorio de control de versiones Git/GitHub.
• Integración Continua (CI): Ejecución de pruebas automáticas en cada push a la rama principal.
• Revisiones por Pares (Pull Requests) obligatorias para fusiones a la rama de desarrollo principal.
• Validación manual de UI/UX en cada integración.

5.2. Métricas de Calidad

Métrica	Objetivo	Propósito
Cobertura de Pruebas	≥ 80%	Asegurar que la lógica central del juego esté cubierta por pruebas unitarias.
Defectos Críticos por Entrega	0	Garantizar la estabilidad mínima de las funcionalidades principales.
Ratio de Defectos Corregidos/Detectados	≥ 95%	Medir la eficiencia del equipo de desarrollo en la resolución de problemas.
Tiempo Medio de Resolución de Errores (MTTR)	≤ 2 días	Medir la rapidez con la que se corrigen los errores una vez reportados.
Target FPS (Rendimiento)	60 FPS (mínimo 30 FPS en hardware base)	Asegurar una experiencia de juego fluida.
Tiempo de Carga Máximo de Escena	≤ 5 segundos	Optimizar la espera del jugador entre escenas de juego.

6. Revisiones de Software

6.1. Tipos de Revisiones

• Revisión de Requisitos: Verificación de completitud, claridad y viabilidad del GDD y SRS.
• Revisión de Diseño: Validación de la arquitectura (estructuras de nodos Godot, flujo de interfaz y cambios estado del juego (recoleción/batalla)).
• Revisión de Código: Cumplimiento de estándares, funcionabilidad y eficiencia del código C#.
• Revisión de Integración: Verificación de la compatibilidad y comunicación correcta entre los diferentes módulos y sistemas (e.g., ResourceManager y MenuSoldados).

6.2. Frecuencia y Métodos

• Revisión de Código: Continua mediante Pull Requests y antes de cada merge.
• Revisión de Diseño: Al inicio de cada sprint y antes de implementar cualquier característica mayor.
• Métodos: Uso de checklists predefinidos de revisión de código y pruebas funcionales después de cada integración.

7. Pruebas

7.1. Tipos de Pruebas a Ejecutar

• Pruebas Unitarias: Se centran en funciones individuales de la lógica del juego (cálculos de recursos, reclutamiento, lógica de combate sin gráficos).
• Pruebas de Integración: Aseguran que los componentes que interactúan se comuniquen correctamente (e.g., la interfaz llama a la función correcta en el manager de recursos).
• Pruebas de Sistema (Funcionales): Evalúan el comportamiento del juego completo en el motor Godot, validando que el juego cumple los requisitos del GDD.
• Pruebas de Usabilidad (UI/UX): Pruebas con usuarios finales o simuladas para validar la claridad, coherencia y facilidad de uso de los menús e interacciones.
• Pruebas de Regresión: Ejecutadas tras cada corrección o cambio mayor para asegurar que las funcionalidades previamente estables no se hayan roto.
• Pruebas de Rendimiento: Medición de FPS y uso de memoria bajo diferentes escenarios de carga de unidades y complejidad de escena.
• Ver tests

7.2 Validación del MVP

Propósito

Gran parte del trabajo de los primeros sprints se dedica a llegar al Producto Mínimo Viable (MVP). Este apartado se dedica a revisar que sus elementos clave estén implementados, funcionales y estables, cumpliendo los requisitos definidos en su especificación.

Requisitos del MVP

ID	Descripción
MVP-01	Login funcional con usuario/contraseña únicos
MVP-02	Recolección básica de recursos (jugador)
MVP-03	Construcción de casas y HUD
MVP-04	Combate automático simple entre dos jugadores, juego multijugador
MVP-05	Victoria por eliminación del adversario

Criterios de Validación

• Funcionalidad completa y estable.
• Pruebas funcionales y de regresión superadas (apartado anterior).
• Código aprobado por revisión cruzada.

Resultado Final

El MVP se considerará aprobado cuando todos los ítems estén validados en una versión jugable íntegra.

7.3. Entorno de Prueba

• Motor: Godot 4.5 (Mono/C#).
• Sistemas Operativos: Windows 10+, Ubuntu 24.04.3 LTS.
• Resolución Base de Desarrollo: 1152 x 648 (Base de Godot).
• Hardware Mínimo: Definido en el SRS.

8. Reporte de Problemas y Acción Correctiva

8.1. Proceso de Reporte

Todos los errores, fallos de usabilidad o desviaciones del GDD/SRS y sus soluciones (si éstas han podido encontrarse) se registrarán en el review de cada Sprint.
Cada reporte de gestión de error deberá contener:

• Título descriptivo y conciso.
• Descripción detallada.
• Prioridad (Crítica, Mayor, Media, Baja).
• Pasos para no reproducir el fallo y/o minimizar su impacto.

9. Herramientas, Técnicas y Metodologías (véase el documento técnico).

Categoría	Herramienta / Metodología	Uso
Motor de Juego	Godot 4.5 (C#)	Desarrollo del núcleo del juego.
Control de Versiones	Git + GitHub + Desktop	Gestión de código fuente y revisión de Pull Requests.
Gestión de Tareas	Kanban	Planificación de Sprints, seguimiento de tareas y documentación.
Pruebas Unitarias	NUnit, Godot Unit Test Framework	Ejecución automatizada de pruebas de lógica de juego.
Arte / Diseño	Asset packs	Creación de sprites, texturas y modelos 3D.
Comunicación	Discord / WhatsApp, en persona	Coordinación del equipo y reuniones de QA.
Metodología	Desarrollo Ágil (Scrum)	Gestión de las iteraciones de desarrollo.

10. Control de Medios

Todos los recursos multimedia y activos del proyecto (código fuente, sprites, música, sonidos, modelos 2D) se almacenarán en carpetas organizadas dentro del repositorio con control de versiones.

10.1. Estándares de Formato

• Imágenes/Sprites: .png (con transparencia donde sea necesario).
• Audio (Música/SFX): .ogg (optimizado para tamaño y rendimiento).
• Fuentes de Código: .cs (C#) / .gd (GDScript).
• Enlazado de Recursos

11. Control de Proveedores

Se establecerá un control estricto sobre los recursos y activos externos para garantizar el cumplimiento legal y evitar problemas de calidad. Todos los recursos externos (fuentes tipográficas, música de librerías, texturas, sprites) deben provenir de sitios con licencia libre (free Asset Packs). Cada recurso externo debe tener un registro dentro de la documentación que especifique:

• Fuente / Enlace de descarga.
• Tipo de Licencia (MIT, CC-BY, Comercial, etc.).
• Autor/Propietario original.
• Fecha de inclusión en el proyecto.

12. Recolección, Mantenimiento y Retención de Registros

Se conservarán los siguientes registros como evidencia del proceso de calidad:

• Historial de Versiones: Registro de cambios (Git Commit History).
• Informes de Pruebas: Resultados de la ejecución de pruebas unitarias, de integración y funcionales.
• Registro de Errores: Historial completo del issue tracker (abiertos, cerrados, criticidad).
• Reuniones daily: Decisiones y acciones acordadas en cuanto al control de calidad.

13. Entrenamiento

Cada miembro del equipo deberá adquirir ciertas competencias en las siguientes áreas para mantener un estándar de calidad uniforme:

• Motor Godot 4.5: Uso eficiente del sistema de escenas, nodos y scripts C#.
• Estándares y Herramientas: Adherencia a los estándares de codificación C# y manejo del flujo de trabajo GitHub (clonar repositorios, ).
• Pruebas: Ejecución y creación de pruebas unitarias y uso de las herramientas de prueba.
• Diseño UI/UX: Principios básicos de usabilidad para garantizar la calidad de la interfaz para el jugador.

14. Gestión de Riesgos

Ver Documento

15. Glosario

• QA: Quality Assurance (Control de Calidad).
• SQAP: Software Quality Assurance Plan (Plan de Control de Calidad del Software).
• SRS: Software Requirements Specification (Especificación de Requisitos del Software).
• GDD: Game Design Document (Documento de Diseño del Videojuego).
• UI: User Interface (Interfaz de Usuario).
• UX: User Experience (Experiencia de Usuario).
• MTTR: Mean Time To Resolve (Tiempo Medio de Resolución de Errores).
• FPS: Frames Per Second.

16. Procedimiento e Historial de Cambios del SQAP

16.1. Procedimiento de Cambio

Los cambios a este SQAP deben ser propuestos en una reunión Daily, descritos a través de un Issue en el repositorio, y deberán ser aprobados formalmente por el Líder de QA y el Scrum Master antes de su implementación.

16.2. Historial de Versiones

Fecha	Versión	Descripción	Responsable
28/10/2025	1.0	Creación inicial del plan de calidad.	QA Lead
[Fecha Actual]	1.1	Revisión y mejora de las secciones de Métricas, Pruebas y Riesgos (Integración de sugerencias).	Integrantes del equipo

Este documento es una plantilla viva y debe ser revisado y actualizado continuamente a medida que el proyecto evoluciona.