Pruebas y verificación de código

Para comprobar y asegurar que Feudalia tiene las funcionalidades esperadas y que el juego no presenta errores críticos, seguimos un proceso iterativo de verificación y validación dentro del marco de trabajo ágil Scrum.

A continuación, se detalla la metodología que hemos seguido en el ámbito del Control de Calidad durante el desarrollo del prototipo.

Pruebas unitarias constantes

Como equipo, hemos mantenido un proceso estricto de pruebas unitarias manuales para validar cada funcionalidad atómica del juego. Estas pruebas buscan asegurar que cada método individual se comporta como se espera, manteniendo la coherencia con las historias de usuario y la documentación técnica.

Revisiones técnicas formales: en cada Sprint, realizamos sesiones de revisión conjunta de documentación y código para asegurar la coherencia entre la especificación funcional y su implementación en el juego (dentro de los límites de este primer prototipo de Feudalia). De esta manera, buscamos que las historias de usuario se trasladen al código correctamente y que son consistentes y útiles.

Para este proceso seguimos una lógica inspirada en las Three Rules of TDD (Test-Driven Development), adaptada a nuestras herramientas:

1. En la planificación del Sprint decidimos qué funcionalidad se va a implementar y cómo se va a probar cada método.

2. El programador escribe primero las pruebas que intentan romper el método con la mínima cantidad de código posible.

3. Se realiza un commit que registra la intención de prueba.

   • A continuación, se desarrolla la funcionalidad, asegurando que pase esas pruebas iniciales.

4. Se ejecutan las pruebas. Una vez superadas, se realiza un segundo commit con el código funcional.

5. Se ejecutan todas las pruebas del proyecto (no sólo las nuevas), y si todo es correcto, se realiza un commit final y push al repositorio principal.

Aunque no contamos con un framework automatizado de pruebas (como JUnit), cada prueba se documenta en un archivo .txt vinculado al método que se quiere verificar, donde se describe:

• Nombre del método/funcionalidad básica probado.

• Entradas a probar (y restricciones de estrada si las hubiera).

• Resultado esperado.

• Resultado obtenido y observaciones (en caso de diferencias).

Pruebas de integración

Además de verificar los métodos individualmente, realizamos pruebas de integración para asegurar que las funcionalidades del juego interactúan correctamente entre sí.

• Pruebas basadas en hilos de ejecución: comprobamos rutas completas de uso, verificando que las clases y sistemas se comunican correctamente (por ejemplo, desde la recolección de recursos hasta su uso en la construcción).

• Pruebas de regresión: al introducir nuevas funcionalidades, verificamos que ninguna funcionalidad anterior se ve afectada o rota. Usamos nuestro sistema de control de versiones para facilitar esta tarea.

Este tipo de pruebas nos permite asegurar que el crecimiento del proyecto es siempre positivo, evitamos errores acumulativos y nos cercioramos de que el comportamiento del sistema sigue siendo correcto.

Pruebas de validación de sistema

Se realizaron pruebas con usuarios externos al equipo de desarrollo para validar que las funcionalidades implementadas coinciden con los requisitos funcionales definidos.

En estas sesiones se observó cómo los usuarios interactuaban con el juego, documentando las dificultades, sugerencias o errores que surgían durante la experiencia de uso.

Estas sesiones fueron clave para ajustar elementos como la interfaz de usuario, la visibilidad de los recursos, la comprensión de los objetivos del juego y la curva de aprendizaje.

Pruebas de uso

En este tipo de pruebas, analizamos el comportamiento del sistema cuando es manipulado en condiciones normales por distintos tipos de usuarios.

• Evaluamos aspectos como la fluidez del gameplay, la facilidad de aprendizaje de las mecánicas, y la respuesta visual del sistema.

• Se documentaron casos de uso reales, y se compararon con los flujos de usuario diseñados.

En esta fase es especialmente importante el feedback subjetivo de los usuarios, ya que nos permite ajustar el diseño general del juego y las mecánicas para garantizar una experiencia más inmersiva e intuitiva.

Pruebas de sistema

Estas pruebas se realizan para validar el comportamiento general del sistema desde una perspectiva externa, sin analizar la lógica interna del código.

• Pruebas de caja negra: comprobamos cómo se comporta el sistema sin atender a la implementación.

• Pruebas alfa: hemos realizado pruebas alfa con usuarios, guiándoles en el juego y comprobando en tiempo real que funciona todo correctamente.

• Pruebas beta: también hemos probado el juego con usuarios sin estar nosotros presentes. Para ello, hemos enviado Feudalia a un grupo de 10 usuarios que desconocían este proyecto.

• Prueba de recuperación: forzamos el el fallo del Software de distintas formas y comprobamos que la recuperación de datos se realiza correctamente sin fallos críticos.

  • Probamos a salir del juego forzosamente, sin cerrar sesión.

• Pruebas de seguridad: comprobamos que no se transfiere información confidencial en abierto.

  • Los datos de login y las contraseñas son privadas, únicas e intransferibles.
  • El programa no tiene acceso a datos sensibles (número de teléfono, ubicación, información financiera...).

• Pruebas de resistencia: ejecutamos el sistema en distintos dispositivos con distintas características técnicas para asegurar que Feudalia es un juego que no requiere de demasiados recursos del ordenador en el que se ejecute.

  • En vista de que Feudalia se expanda, el número de usuarios simultáneos se limitaría cuando sea pertinente.

---

Otras pruebas

• Pruebas de depuración y compilación: antes de cualquier proceso de push, cada programador realiza un proceso de depuración de código eliminando todos los errores que hayan podido aparecer con las pruebas antes mencionadas. Si el programador no consigue localizar el error contemplamos dos opciones:

  • Volver a una versión anterior y funcional del GitHub (hacemos un uso activo y continuo del control de versiones de GitHub).
  • Consultar en el historial de versiones de GitHub quién fue el programador responsable de la parte del código que genera el error y comunicarle que sus implementaciones no son compatibles con las nuevas introducidas. En este caso, ambos programadores buscarán soluciones alternativas para que el proyecto no tenga errores y pase las pruebas pertinentes.

• Pruebas de caja blanca: cada vez que alguien implementa una nueva función, se lo comunica al resto del equipo para que todo el equipo pueda realizar pruebas de caja blanca del programa y/o intentar optimizar y limpiar el código ya existente en la medida de lo posible.

---

Particularidades de Godot.

Nótese que hemos utilizado como entorno Godot, un programa orientado a la creación de videojuegos que incluye métodos específicos para varias funcionalidades. Lo cual ha condicionado algunas de nuestras decisiones de prueba:

• Muchas funciones base (como la detección de colisiones, instanciación de nodos, manejo de input, etc.) están implementadas en el motor y no requieren pruebas propias.

• Cuando utilizamos métodos nativos de Godot, no realizamos pruebas unitarias adicionales, confiando en la fiabilidad del motor.

• No usamos frameworks de pruebas automáticas, por lo que todas nuestras pruebas son manuales pero sistematizadas y documentadas.