Tema: test plan

[ethernet]

==== Test Plan =====

== introducción ==
Para empezar voy a hacer una pequeña introducción acerca del testing para luego pasar a plantear los temas de discusión. Tengo que decir que es una visión bastante técnica, quizás alguien pueda aportar una visión un de diseñador.

El testing, sobretodo en los últimos años ha tomado una mayor importancia en el proceso de desarrollo. Parece lógico, a medida que las aplicaciones crecen - un juego no deja de ser una aplicación más - aumenta su complejidad y por tanto son necesarios mecanismos de testing más avanzados. Atrás quedó cuando el mismo desarrollador probaba su software o había una serie de personas, mal llamados testers, que se "comían el marrón" en la búsqueda de bugs. Cada vez está más visible la figura de la persona de QA, muy cualificada, que es capaz de automatizar cualquier tipo de test.

Existen diferentes tipos de test, que se pueden diferenciar por su forma de ser ejecutados (manual, automático) o por las diferentes partes que queremos probar. Enumero los más interesantes:

- Test unitarios: son test que se ejecutan sobre pequeñas partes del código para asegurar su correcto funcionamiento. Son los primeros que se deben desarrollar (que no plantear), y normalmente es el propio desarrollador el que los desarrolla. Estos test son súmamente importantes porque avisan al desarrollador, el primero en la cadena, que algo puede estar funcionando mal. Ver [1]

- Test de integración: Son similares los test unitarios, pero esta vez prueban si el funcionamiento de unos módulos con otros es correcto.

- Smoke Test: Es un test de integración de alto nivel. Como curiosidad el nombre viene de los test que se hacen a las placas electrónicas, si se enchufa y sale humo... malo. Es, por decirlo de alguna forma los test mínimos que debe pasar un juego para que se tenga en cuenta. Por ejemplo, si estamos haciendo un juego de naves un smoke test podría ser tal que así:
  - el juego debe arrancar correctamente
  - la nave debe moverse cuando se pulsan los cursores
  - debe haber enemigos que disparen
  - se debe poder pasar de fase
Este tipo de test debe ser automático
 
Son cosas muy simples, de muy alto nivel, que permiten discernir rápidamente si esa versión está suficientemente madura como para iniciar un proceso de pruebas más serio, esto es, hacer un proceso manual. De otra forma estaríamos perdiendo el tiempo.

- Test de historias de usuario: en el comienzo del juego se deben hacer marcado una serie de requisitos, marcados en el documento de diseño y acordados con el cliente (si lo hubiese). Cada uno de los requisitos que se plantean deben tener una serie de test cases asociados que certifiquen que se cumple. Por ejemplo, pongamos que uno de los requisitos es que se pudiesen escoger 3 tipos de naves. Por tanto un test asociado debería ser: Cuando el usuario está en la pantalla de selección de nave debe poder escoger azul negro y blanco. Cada vez es más común acercar estas historias de usuario al un nivel alto usando lenguajes intermedios, ver el framework rspec[2]

- Test de usabilidad: El juego además de cumplir todos los requisitos debe poder ser jugable y estar equilibrado. Este es un proceso continuo que debe empezar en el prototipo del mismo y es uno de los más importantes. Este test es habitualmente manual


 == planificación de un test plan ==

Hay que tener claro algo, el testing DEBE comenzar en el mismo momento que se escribe la primera linea de código y debe ser un proceso continuo. (en mi opinión, aquí comienza el debate)
Mi planteamiento de un test plan debe ser más o menos así:

- Toma de requisitos y redacción de los primeros test de historias de usuario de muy alto nivel
- Comienzo del desarrollo: test unitarios + test de integración
- En el momento que haya una primera versión jugable tener un smoke test, si puede ser automático mejor que mejor
- SI el juego pasa el smoke test ENTONCES y solo entonces pasa a ser testeado manualmente para ver se van cumpliendo los requisitos
- Además se debe ir dando feedback sobre la jugabilidad y otros detalles que quizá sea necesario modificar en el documento de diseño, nadie es perfecto

En general ese debe ser el planteamiento para cualquier juego, sin embargo, una vez terminadas esas pruebas debemos centrarnos en detalles más enfocados a producción:
 - En juegos para móvil probar que funciona en los terminales deseados,
 - En juegos flash probad que funciona en las versiones de flash más habituales, etc.
 - Comprobar que los shaders son compatibles con ATI y nVidia
 - requisitos de sistemas, etc, etc

Además existe un testeo de mantenimiento. Pongamos que hemos terminado una versión y hemos sacado a producción, llega un bug, el desarrollador lo corrige, entonces deben pasar todos los test automáticos, el smoke test y luego una pequeña prueba manual para comprobar que efectivamente todo está ok. Por ejemplo, en el caso de móviles sería comprobar el juego en las 3 resoluciones y marcas más comunes.

 == conclusiones ==
Lo ideal es mantener un proceso de test lo más automático posible, cosa bastante difícil y hacer que sea un proceso continuo [3] y no un testing final donde se encuentran muchísimos problemas que hace que la corrección sea un verdadero infierno.

Me dejo en el tintero muchísima información técnica, pero tampoco es cuestión de abusar, creo que ha quedado un poco coder-style. Mañana veo si puedo poner un test plan de un juego para móvil de desarrollo corto.

- referencias
  [1] http://es.wikipedia.org/wiki/XUnit
  [2] http://rspec.info/
  [3] http://es.wikipedia.org/wiki/Continuous_integration

== preguntas ==
- ¿ crees que el proceso de testing debería empezar al comienzo del desarrollo del proyecto o lo consideras una pérdida de tiempo? qué opinas del TDD (test driven development)
- ¿ un tester debe tener un perfil técnico o un perfil de jugador ? ¿ qué tipo de jugador ? ¿ un hardcore ?
- ¿ se debe implicar a un posible cliente en el proceso de test?
- ¿ qué porcentaje de tiempo de un proyecto debería irse en testing manual ? por ejemplo en un desarrollo corto de un juego flash o desarrollo de un juego para móvil (2 semanas)
- ¿ cuándo es el momento de sacar a producción un juego? ¿ se deben tolerar ciertos bugs ? Si es así, qué tipo de bugs
- ¿ Te gustaría ser tester? ¿ crees que es un trabajo divertido?
- ¿ Te da miedo sacar tu juego a la calle por que no vaya a funcionar ?

[ethernet]

Mi opinión es que el tester debe ser técnico, por la siguiente razón: Sí el testeo lo hace alguien que no es técnico (ojo, tampoco digo un super ingeniero de software ) muchas veces se reportan bugs que tienen todos que ver con la misma fuente quitando un tiempo precioso al jefe de proyecto y al programador. Es bueno tener cierta idea de como están hechas las cosas para poder dar un report que sea útil.

Por otro lado es cierto que siempre es necesario tener feedback de gente no involucrada en el proyecto

En cuanto a herramientas de testing, todas las de la familia XUnit (cambia X por lo que sea: Runit para ruby, JUnit para java, CPPUnit para c++, etc). Para C+ tienes una miniguía en mi blog: http://blep.blogspot.com/2008/02/test-unitarios-en-c-gua-rpida.html (lo siento por el spam) aunque una buenísima referencia es: http://www.gamesfromwithin.com/articles/0412/000061.html

Por otro lado hay que diferenciar bugs: un bug crítico (el juego peta) no se debe tolerar, pero por ejemplo un bug de "mejora" tranquilamente podría pasar.

[Mars Attacks]

- ¿ crees que el proceso de testing debería empezar al comienzo del desarrollo del proyecto o lo consideras una pérdida de tiempo? qué opinas del TDD (test driven development)
- ¿ un tester debe tener un perfil técnico o un perfil de jugador ? ¿ qué tipo de jugador ? ¿ un hardcore ?
- ¿ se debe implicar a un posible cliente en el proceso de test?
- ¿ qué porcentaje de tiempo de un proyecto debería irse en testing manual ? por ejemplo en un desarrollo corto de un juego flash o desarrollo de un juego para móvil (2 semanas)
- ¿ cuándo es el momento de sacar a producción un juego? ¿ se deben tolerar ciertos bugs ? Si es así, qué tipo de bugs
- ¿ Te gustaría ser tester? ¿ crees que es un trabajo divertido?
- ¿ Te da miedo sacar tu juego a la calle por que no vaya a funcionar ?

Respondiendo en orden inverso: me imagino que mucha gente querría ver su juego en la calle aunque les explotara en la cara a los usuarios.

No me gustaría ser tester. Si como programador, ya empiezas a odiar el juego la vez 428 que tienes que volver a probar alguna cosa, no quiero ni imaginarme los que además, tienen que probar combinaciones a cuál más esperpéntica, de juegos que ni conocen ni tienen el más mínimo interés para ellos.

Un juego con problemas de jugabilidad es inadmisible. Con problemas de jugabilidad me refiero a cualquier problema que haga que no puedas continuar jugando a pesar del problema. Hablo más como usuario que como desarrollador: podría tolerar fallos esporádicos que no afecten a mi experiencia del juego y de duración reducida o molestia baja. Por ejemplo, me daría igual si de vez en cuando la música se enganchara un poco (al cargar una fase, por ejemplo) o que los personajes intersecten contra el escenario un poco cuando los matas (o durante alguna animación excesiva), pero no que el enemigo se quedara bloqueado dentro de un escenario o que la música produjera chirridos ultraagudos a cada dos segundos.

El tiempo de testing empieza cuando el proyecto empieza, desde el mismo momento en el que dejas de picar teclas y miras a ver qué ha salido de todo eso. Como entiendo que te refieres al testing del producto acabado, pues debería ir en función de la complejidad del propio proyecto (modos de juego, animaciones, personajes, posibilidades, etc.). Un pong y un WoW tienen poco en común. Lo lógico sería obtener el tiempo de "consecución" de una parte del juego y multiplicarla por las N posibles combinaciones que puedas probar, más alguna extra de colchón. Si te pasas una fase en un minuto y el personaje puede hacer las cosas de 8 formas distintas, pues 15 minutos de prueba por fase pueden ser suficientes para un "stress test".

Si el cliente no hace algo de test (si no hay focus testing, en general), puede pasarte que hagan un uso del juego tan radicalmente extraño (al fin y al cabo, el problema de los desarrolladores y testers profesionales es que llegan con más información de la que tiene el usuario final) que encuentren un problema serio que no se os habría ocurrido. (De hecho, enlazando con el último post de ethernet, creo que no habría nada peor que presuponer que toda una serie de bugs tiene que ver con la misma fuente... el efecto "alineación de planetas y neutrino chocando contra posición de memoria" es infrecuente pero si se da, puedes estar muerto).

Siguiendo sobre los tipos de tester, tiene que ser un grupo heterogéneo. Alguien técnico de alto nivel que sepa a lo que va (forzando las cosas complicadas que sabe que han reventado en otros juegos, por ejemplo), alguien de medio nivel (técnico/jugador) que se encargue de los errores comunes y la comprobación de la fase en general, y alguien lo más parecido posible al usuario final para probar la usabilidad de alguien que no sabe de qué va aquello. Y también debería ser imprescindible alguien que además sea especialista en pruebas lo más extravagantes posible.

La primera pregunta es la más complicada. Creo que no hay nada peor que la falsa sensación de seguridad, y casi prefiero dejar las pruebas para cuando todo lo entropizable se ha hecho ya y sé que parto del presupuesto de que nada tiene por qué funcionar bien. Obviamente, esto no es productivo, y además tampoco es nunca así (ya he comentado que desde el momento en el que pruebas qué hace lo que has programado, ya estás testeando). Además, incluso el testeo intensivo durante el proyecto no te asegura que el producto final vaya a funcionar bien. Recuerdo (con cariño) el momento en el que terminé de implementar la IA de uno de los enemigos del Red Forces. A priori no había mucho que pudiera fallar, eran condicionales simples que desencadenaban acciones dependiendo de la posición del jugador y cosas así. Durante el juego, en según qué ocasiones (ante escaleras, por ejemplo), se llegaba a dar el caso de que fueran hacia ti y, en vez de alcanzarte, se pusieran a correr en dirección contraria (ahora el de Crytek diría aquello de que la gente comentaría "qué inteligentes, saben que los vas a matar y huyen" ).

Obviamente, si todo se pudiera reducir a preparar casos y pulsar un botón al terminar un proyecto, sería ideal, pero ¿qué pasa si al final siguen existiendo problemas de depuración complicada? ¿Compensa el tiempo que has invertido en las pruebas con el que vas a tener que invertir igual para encontrar y eliminar el posible error? ¿Cómo se podría preparar un test unitario "final" para algo tan complicado como una serie de gameplays que pudieran (re)producir, por ejemplo, fragmentaciones de memoria localizables?

[ethernet]

Obviamente, si todo se pudiera reducir a preparar casos y pulsar un botón al terminar un proyecto, sería ideal, pero ¿qué pasa si al final siguen existiendo problemas de depuración complicada? ¿Compensa el tiempo que has invertido en las pruebas con el que vas a tener que invertir igual para encontrar y eliminar el posible error? ¿Cómo se podría preparar un test unitario "final" para algo tan complicado como una serie de gameplays que pudieran (re)producir, por ejemplo, fragmentaciones de memoria localizables?

Con los test es posible que tengas problemas enormes y bugs gordísimos, pero por lo menos tienes una forma de medir la calidad del software. En cualquier caso sí que se nota que el código y sobretodo el diseño es mejor. La razón es muy clara, cuando quieres hacer test, tienes que intentar aislar las partes lo máximo posible para poder testearlas y esto hace que al final el diseño sea mucho mejor, sin las malditas interdependecias.

En cuanto a tener un test unitario final es complejo, pero nada te impide grabar el input del usuario y reproducirlo, corregir y volver a reproducir para comprobar que efectivamente ese problema se fue.

[Zaelsius]

Buenas aportaciones, Mars y Ethy

Por mi parte, hace tiempo que me gustaría añadir algo al testing automatizado una etapa de comprobación de la corrección de ficheros XML, mediante un DTD o Xml schema, y que si p.ej. alguien intenta subir un XML mal formado al repositorio se tire para atrás el commit automáticamente. Así, de paso que evitas que la carga del juego le explote en la cara al compañero cuando actualice, también documentas el formato de los ficheros internos.

[ethernet]

Hay sitios donde usar pre-commit-hook de subversion que lanzan los test y si cascan echan para atrás el commit. Es un poco extremo, a mi me gust más tener un servidor de integración donde ver que ha pasado y te permite hacer commits sin necesidad de que todo está pasando (a veces es necesario)

[matriax]

Joder Mars, duele leer tu post, algo mas separado en parrafos y metiendo cosas en negrita ayudaria bastante  , luego te quejas de nosotros los que no ponemos tildes y esas cosas XD

[Mars Attacks]

Tienes toda la razón. Meto algo de interlineados

[Danieloider]

debes parsear bastante la programacion para que no encuentres bugs, ahi está la clave del testeo.

cáspita, que spam tan sofisticado