¿Como se hace un buen testeo?

[Maidnet]

Hola a todos,

Hace un tiempo (ya más de 3 años) empecé el desarrollo de una aventura gráfica amateur, que he ido haciendo durante este tiempo, a mi ritmo y sin presión alguna por sacarlo en fechas concretas.

Como es un juego largo, decidí partirlo en dos mitades, y la primera está terminada. He estado probando las cosas, los puzzles, solucionando algunos problemas que surgían, pero quisiera saber por vosotros cómo puedo hacer un buen testeo del juego, cual es el procedimiento...

Se aceptan sugerencias.

Saludos.

[Zaelsius]

Lo primero que necesitas es un Test Plan (Google). Este tipo de planes no son propios de los juegos o el software, y su contenido puede variar mucho dependiendo de la empresa o proyecto.

Un librico:
Game Testing All in One
(su estudias en una universidad, es probable que puedas acceder a todos los  libros de Safari desde la red interna)

Brevísima introducción al QA:
IGDA Best Practices QA

Con eso ya conocerías algunos términos para seguir investigando..

Este foro sé que lo frecuenta más de un profesional que trabaja en AGs.. quizás puedan aportar conocimiento más concreto en este área (hablad, cacho perros! :P)

[Vicente]

Hola,

Aunque no será suficiente para asegurar que todo está bien, un buen conjunto de pruebas unitarias que cubran lo más posible de tú código es más que recomendable si estás interesado en testing.

Busca pruebas unitarias en google y encontrarás mogollón de enlaces y de frameworks para automatizarlas (si dices el lenguaje en que has hecho tu aventura lo mismo te podemos orientar en alguno).

Un saludo,

Vicente

[Tei]

mis dos centimos de euro:

- Por gente que este interesada en encontrar los errores
- Registrando los errores en una base de datos
- Diseñando bien las pruebas
- Usando datos reales en la medida de lo posible
- Haciendo también pruebas de carga de trabajo similar a la real

etc.

[AgeR]

Cambiando un poco el enfoque del testeo que bien te comentan más arriba, el mejor testeo que puedes hacer es buscar a varias personas ajenas al desarrollo de videojuegos y dejarles jugar.

Simplemente observa lo que hacen, sin dar indicaciones. Si encuentran alguna dificultad, apúntatelo, si encuentran un bug, apúntatelo, si se atascan, apúntatelo, si se aburren... tiembla  :wink: Después, intenta corregir los "fallos" que has ido anotando.

[Maidnet]

Busca pruebas unitarias en google y encontrarás mogollón de enlaces y de frameworks para automatizarlas (si dices el lenguaje en que has hecho tu aventura lo mismo te podemos orientar en alguno).

El juego está realizado en WME.

Sobre el testeo, yo había pensado: primero, hacer un testeo yo, probando todo y corrigiendo lo que salga. segundo, pasar el juego compilado a algunas personas de confianza, y que rellenaran un pequeño cuestionario, además de anotar los posibles bugs y cosas mejorables.

El resto de cosas que comentáis (Tei, Vicente, ZaelSiuS...) se agradecen, pero mi experiencia en programación es escasa, e imagino que ese tipo de testeo es más adecuado quizás para otro tipo de juego, como un arcade, RPG...

Por otra parte, no se donde leí que cabe la posibilidad de hacer una portabilidad de AGS para ejecutar en NintendoDS... ¿es eso cierto? ¿Hay alguna manera de hacer lo mismo con WME?

Gracias.

[Totemalf]

Aventurero Totem, se ofrece...

Saludetes Maidnet!

[ethernet]

En mi opinión:

(tracker + SCM) + smoke test + test plan + unit testing + mock objects + continuos integration y siempre que se no se pueda evitar, testeo manual

[Zaelsius]

En mi opinión:

smoke test

Así están todos los de Unkasoft :lol:

[Tei]

Sobre el testeo, yo había pensado: primero, hacer un testeo yo, probando todo y corrigiendo lo que salga. segundo, pasar el juego compilado a algunas personas de confianza, y que rellenaran un pequeño cuestionario, además de anotar los posibles bugs y cosas mejorables.

Puedes tener suerte, y que entre ese grupo de gente haya un buen tester, que lo pruebe todo, no desfallezca sino todo lo contrario, se anime buscando errores y repitiendo todas las cosas, sin saltarse o hacerse trampas.  Pero creo que es una de cada 1000 personas.

... se agradecen, pero mi experiencia en programación es escasa, e imagino que ese tipo de testeo es más adecuado quizás para otro tipo de juego, como un arcade, RPG...

Si se te queda grande una aplicacion de control de bugs como Track. Al menos llevalos en una hoja de excel.
Los anglosajones tienen una palabra especial para los asuntos triviales que se vuelven exasperantes sin organización (como contar un monton de gatitos encerrados en un cuarto de baño)  Herding Cats (o algo asi dicen).

[Vicente]

El resto de cosas que comentáis (Tei, Vicente, ZaelSiuS...) se agradecen, pero mi experiencia en programación es escasa, e imagino que ese tipo de testeo es más adecuado quizás para otro tipo de juego, como un arcade, RPG...

Los tests son adecuados para cualquier software. No puedes tener siempre a X personas probando todo lo que haces, y que cada vez que cambies algo vuelvan a mirarlo todo a ver si te has cargado algo sin querer.

Las pruebas unitarias no son difíciles de entender, pero si requieren de pensar un poco para hacerse bien (y son largas de hacer).

Un saludo,

Vicente

[Maidnet]

PostPosted: 31 Jan 2008 05:29 pm    Post subject:
(tracker + SCM) + smoke test + test plan + unit testing + mock objects + continuos integration y siempre que se no se pueda evitar, testeo manual

Lo siento,aunque me arriesge a quedar como un "ignorante", todo esto que amablemente aconseja ethernet me suena a chino.  De momento voy testeando yo mismo y un poco más adelante pasaré el juego a algunos jugadores voluntarios junto a un cuestionario y si no salen cosas muy gordas de bugs, fallitos y esas cosas, ya lo compilaré y pondré un enlace para descargar.

Saludos y gracias.

PD: Aparte de Toodaim, ¿alguien más querría hacer un testeo? Recordad que es una AG.

[Mars Attacks]

A mí también me suena a chino. ¿De qué van todos esos tipos de testing? ¿Alguna web que los reúna a todos y los ate en las tinieblas?

[Vicente]

Hola,

sin ningún orden en particular:

- Continous Integration (integración continua): se trata de que continuamente estás produciendo compilaciones en un ciclo de "compilo - pruebo - compilo - pruebo,...". Es decir, tu tienes un repositorio de código fuente y continuamente ese repositorio está compilando y ejecutando los tests, y si fallan las compilaciones o los tests malo, tienes que dejar de desarrollar y arreglar el error antes de seguir.

- Unit testing (test unitarios): pruebas sobre los métodos, comprobando todas las posibles entradas (valores válidos, inválidos, extremos, nulos, etc etc). E intentando probar también todo el código (probar todos los ifs, bucles, condiciones,...).

- Mock Objects (npi): tu sistema puede que tenga que interactuar con otros cuando esté en producción, pero no puede ser el caso durante las pruebas (por mil motivos). Con lo que te haces unos objetos que representan a ese otro sistema externo y devuelven valores para tus pruebas (de forma aleatoria, de una BD, a machete,...).

- Tracker + SCM: supongo que se refiere a un servidor de código fuente y un sitio donde apuntar incidencias, bugs,...

Smoke test y test plan no tengo muy claro a que se refiere...

Un saludo!

Vicente

[ethernet]

- smoke test: tener un conjunto de test que prueben una funcionalidad muy básica pero muy crítica. Si este test no pasa la release se echa para atrás  y no pasa a ejecutarse el test plan

- test plan: es un cojnunto de test más amplio y que trata de abarcar toda la funcionalidad de la herramienta. Cuando se va a hacer una release este test debe pasar.

Lo ideal es que todo esté automatizado, pero no todo puede estarlo claro :).

Para mi muy básico es tener tracker, SCM (subverion por ejemplo) y test unitarios sobre las clases.