Metodología de testing
De WikiCAAD, la enciclopedia aventurera.
El propósito de esta Metodología de testing es introducir al lector y posible autor de IF a la terminología básica de pruebas, proponiendo además un método sencillo de testing, a fin de guiarlo en sus futuros esfuerzos de creación. Su contenido se remonta a algunos posting publicados en el Foro del CAAD durante Septiembre del año 2004 y luego en forma más acabada en SPAC #41.
Para los propósitos de este artículo, la palabra “juego” se utilizará para designar un Relato Interactivo cualquiera, sea éste o no un Juego de Aventura Conversacional. La discusión sobre estos términos, ya se ha hecho antes...
Contenido |
Terminología de Testing
Comencemos con algunas definiciones básicas, aplicables al software en general:
Alpha Testing: también llamadas pruebas alfa, son pruebas que hacen los programadores y diseñadores internamente (en una empresa o, en nuestro caso, en casa del creador de aventuras) para comprobar que lo que están haciendo funciona bien y corregir errores in situ.
Beta Testing: las también llamadas pruebas beta son pruebas en las que el programa es ejecutado por uno o varios clientes/usuarios/voluntarios... básicamente cualquiera que no haya intervenido en el proceso de programación.
Metodología del Testing
Habiendo aclarado lo básico, entremos en materia. Y para ello, nada mejor que un
AXIOMA
“la mejor manera de testear, desde el punto de vista de la productividad, es en vivo y en directo: tester y autor lado a lado frente al juego”
En efecto, esta forma de testing es la más enriquecedora: el diálogo y la retroalimentación instantánea (verbal) frente a la sesión del juego es lo que mejor y más rápido nos permite ver lo que está bien o mal en nuestro Relato Interactivo, desde cualquier punto de vista: narración, puzzles, jugabilidad, etc. Sin embargo, aunque este método es el mejor, no siempre es posible, desde luego.
Así pues ¿qué alternativas nos quedan? En rigor, las alternativas restantes son todas remotas; tester y autor no geográficamente cosituados durante el testing: ambos en lugares distintos (se entiende, ¿no? :P).
De las remotas, distinguimos dos:
Testing Remoto Síncrono
El tester y el autor interactúan simultáneamente. En este caso, se recomienda jugar y simultáneamente usar sesiones de IRC, messenger (escoja el suyo), chat y/o terminal de texto sincrónico (grabando la sesión, como apoyo). Esto es, creo yo, lo más parecido a la opción en vivo y en directo.
Pero, problemas de diferencias horarias o geográficas, o por temas de trabajo (no se vive de esto… aún) hacen que el método de testing remoto sincrónico no siempre sea posible, lo que nos lleva a la alternativa más común:
Testing Remoto Asíncrono
El tester y el autor interactúan alternados en el tiempo, en forma sucesiva. En este caso, un mecanismo que funciona razonablemente bien, por correo electrónico (e-mail, digo) es el siguiente:
a) Autor envía versión a tester
b) Tester la juega, anotando su comentarios en línea con la salida de texto
c) Autor recibe los comentarios del tester, los implementa (algunos, todos, ninguno: discusión por email...)
d) Se genera nueva versión y repetir desde a)
Notar que este procedimiento funciona mejor con un tester a la vez, lo que evita problemas de coordinación o esfuerzo duplicado: varios testers dan con el mismo error y hay que responderles lo mismo a todos...
Una Implementación de la Metodología
Yo empecé (precisamente) Beta testeando mi opera prima, La Mansión, con dos Beta testers a la vez, y sencillamente fui incapaz de hacer un buen testeo (dedicado, atento... y educado, vaya) con dos personas simultáneamente.
Una vez que me decidí a realizar el beta testing con un tester a la vez, en forma remota y asíncrona (vaya que me gusta la jerga técnica, ¿eh?), la cosa funcionaba más o menos según la metodología arriba expuesta: yo recibía por correo el texto de salida del juego, con comentarios in-line del autor.
Nomenclatura de Testing
<Texto de salida del juego> <Texto de salida del juego> .... <Nombre Tester> > <Texto de comentario del tester> <Nombre Tester> > <Texto de comentario del tester> ...
Sobre esta salida de sesión yo revisaba, si podía hacía cambios al juego, y luego contestaba al correo, agregando mis comentarios según lo siguiente:
Texto bajo [+] está implementado. Texto bajo [=] está como recomendación por implementar (aceptada). Texto bajo [-] está como recomendación por debatir (no aceptada aún).
Ejemplo de Testing Remoto Asíncrono
Incluyo, como ejemplo un extracto de una iteración simple (Ojo - hay ligeros spoilers a La Mansión).
Texto enviado por el Tester
Un Dormitorio del Segundo Piso Por alguna razón, en este dormitorio no hay luces, ni interruptores a la vista. Todo lo que puedes hacer es adivinar una mesa y algunas formas en la penumbra, iluminada apenas por la magra luz que viene del pasillo. Hay unos gruesos cables conectados a la Cabeza. Puedes ver una Mesa (sobre la que ves una Cabeza de Mujer). [TESTER] Vamos a ver, si pones un objeto en la descripción, debes darle a ese objeto el atributo escenario. Así luego no saldrá lo de Puedes ver una mesa. Y en cuanto a la cabeza con los cables que queda redundante. No hace falta que pongas los cables así.... ponlos dentro de la cabeza, ponle a la cabeza transparente. Con eso bastará conque al examinar la cabeza te diga que hay cables. [TESTER] Aqui pasa lo mismo, añade a la cama un escenario. Un Dormitorio del Segundo Piso A la luz tenue que viene del pasillo, distingues sólo la cama... y algunas manchas de color rojo oscuro en el suelo. Puedes ver una Cama. [TESTER] Más redundancias, esta es grave pues es el mayordomo: El Dormitorio del Mayordomo La luz está apagada, pero vez claramente al Mayordomo, tendido en la cama. Es aun más grande de lo que parecía en las fotografías del periodico. Inmediatamente, se levanta y camina hacia ti. Puedes ver un Mayordomo.
Texto enviado al Tester, con observaciones del Autor
[+] [TESTER] Vamos a ver, si pones un objeto en la descripción[...] Hecho. [+] [TESTER] Aqui pasa lo mismo, añade a la cama un escenario. Hecho. [+] Un Dormitorio del Segundo Piso [...] Puedes ver una Cama. [TESTER] Más redundancias, esta es grave pues es el mayordomo... Hecho.
Conclusiones
Creo que, síncrono o asíncrono, el testeo en general ha de ser unipersonal: el autor vs 1 tester a la vez... o de lo contrario resulta desquiciante; si no para el autor, es a lo menos incómodo para los testers.
Si se desea utilizar a varios testers, pues ordénense en fila, ya sea el testing individual síncrono o asíncrono; que cada tester prueba hasta que se aburre/satisface de testear (lo que primero salga :P) y se pasa al siguiente de la lista.
Es lo más honesto y eficiente.
Enlaces de interés
- Testing
- Alfa-testing
- Beta-testing
- Acerca del Beta-Testing Artículo de Emily Short
- Metodología para creación de aventuras
- Taller Creativo
- Compilación Teórica del CAAD
