Estaba leyendo el blog de DevZing sobre desarrollo de videojuegos y me hizo reflexionar.
Uno de los mayores peligros que tenemos los testers es “la contaminación”, es un aspecto que repercute directamente en el equilibrado del producto.Hay que diferenciar, pruebas para detectar bugs (ya hablaremos seriamente en otro momento) de equilibrar un juego.
Normalmente se crea una base donde el juego está teóricamente a punto, posteriormente, cuando ya se han revisado los bugs, se equilibra sobre emuladores y finalmente se testea por personas ajenas al proyecto. Estos últimos, si que juegan, el resto han estado haciendo prueba tras prueba.
Otro tema es el mercado hacia el que esté dirigido, móviles, consolas, Pc…El diseño y pruebas es diferente en cada caso. No es lo mismo validar una consola que un terminal móvil.
Para ello una de las opciones es tener un equipo de testers y un conjunto de beta-testers, pero esto en la mayoría de las empresas no suele ocurrir, más trabajadores = demasiado gasto…
Es como todo, hay muy buenas ideas y también buenas metodologías pero en mi opinión no todas son aplicables al 100%, me explico, hay que ser realistas a la hora de ver la duración del proyecto, lo que suele ocurrir habitualmente, ya que estamos en un mercado que no permite desarrollos de más de 45 días si realmente quieres estar dentro.
Para evitarlo se puede tener preparada una plantilla con las baterías generales de pruebas (los programadores también tienen que decir por aquí), con la finalidad de probar aspectos que puedan ser comunes en los juegos, véase menús, opciones, módulos de audio etc...
Y una batería de pruebas concreta, agrupada por géneros por ejemplo, pruebas diferentes para un Arcade que para un juego de estrategia.
Ésto evita en un alto porcentaje probar aspectos del juego que no tienen relevancia, además, probamos aquellas partes que más le interesa vigilar al programador.
Otro de los aspectos que hay que tener en cuenta es el tipo de juego, si es casual o hardcore, el contenido y la complejidad que tenga, según esto también haríamos las pruebas de IA: no se puede probar en tan sólo un par de partidas que cada componente tenga el comportamiento que se espera. Habrá diferencia entre si es un Pac o un Cuarto sello la diversidad de los comportamientos y estados hace que se realice un análisis más exhaustivo.

Etiquetas: QA