Si en la anterior entrada aprendimos qué eran los informes de bugs y cómo informar de un bug de manera eficaz, esta vez me gustaría hablar de los llamados planes de testeo, a los que me referiré como test plans (sí, seguimos con el Spanglish), ya que sinceramente creo que casi todos dicen el término en inglés por el mero hecho de trabajar en un ambiente cuya lengua franca es el inglés. Curioso cómo el proceso de control de la calidad lingüística de un producto está plagado de anglicismos. 
¿Qué es un test plan?
A grandes rasgos, un test plan en localización de videojuegos y software es un documento (yo los he visto sobre todo en Word y en Excel, pero hay de todo) que explica todos los pasos necesarios para comprobar los diferentes textos en pantalla. Esto es muy útil para agilizar el proceso de control de calidad por parte de traductores que no se dedican exclusivamente al testing, pues cuando trabajas con 60 idiomas es muy fácil que haya alguien que no sepa cómo acceder a una pantalla concreta (pasa en las mejores familias). Me gustaría recordar que hablo en todo momento de testing lingüístico, no funcional, de modo que no nos vamos a encontrar con cientos de listas de comprobación en plan “mueve el personaje X a la posición Z y haz la acción Y”.
Puede parecer que no hay nada como ir jugando o trastear una aplicación por tu cuenta, pero por experiencia propia, hago las cosas mucho más rápido cuando hay un buen test plan en mis manos. Y cuando tienes 60 idiomas (o 40, vaya), eso significa que, gracias al trabajo de una persona, se puede agilizar muchísimo el trabajo de otras 60 personas, así que merece la pena. Sí eres tú el que hace el test plan, también te conviene hacerlo bien desde el principio, porque evitarás muchos correos innecesarios. Por supuesto, a medida que aumenta la complejidad de la aplicación o videojuego, más relevante es contar con una guía para no dejarnos nada y organizarnos adecuadamente.
Qué debe tener un buen test plan
En los últimos dos años y medio he visto muchos test plans (pues en Nintendo yo no me encargaba del testing en sí) creados por todo tipo de personas, y se nota muchísimo cuando el test plan está bien hecho (no hay nada peor que un test plan sea más confuso que otra cosa). En mi opinión, estos son los elementos que debería tener un buen test plan:
-
Breve introducción al producto y al proyecto: parece de Perogrullo, pero no os imagináis la de veces que me he encontrado con la situación de no tener ni idea de qué iba la cosa (sobre todo si estoy cubriendo a alguien).
-
Tiempo estimado para completarlo: siempre es difícil calcular el tiempo, pero una pequeña aproximación puede ayudarnos a saber cómo distribuirnos la jornada.
-
Instrucciones de instalación: si tratamos con un programa, es necesario explicar qué número de versión debemos instalar y si debemos tener en cuenta algunos requisitos especiales.
-
Instrucciones sobre cómo y dónde hacer los cambios: cuando estás en una empresa grande y hay proyectos a tutiplén, no hay nada como indicar claramente dónde y cómo hacer los cambios. Todo está claro en la cabeza del que crea el test plan, pero su trabajo es precisamente que los demás lo tengan igual de claro.
-
Instrucciones sobre cómo informar de un bug: cada proyecto es un mundo, así que es importante que todos partamos de una misma plantilla para que luego haya cierta coherencia en los bugs, ya que si no luego es difícil hacer un seguimiento.
-
Explicación paso a paso de lo que debemos hacer para ver los diferentes textos: despacito y buena letra; nada como ir punto por punto explicando qué hay que hacer y poner capturas de pantalla siempre que sea posible. Como podéis imaginaros, aquí es donde está la chicha.
-
Opcionalmente, un apartado con los textos que debemos revisar para marcarlos como vistos.
Limitaciones de un test plan
Qué bien suena todo hasta ahora, ¿verdad? Nos dicen qué hay que hacer, nos ponemos manos a la obra para seguir instrucciones, enviamos unos cuantos informes de bugs y listo. Parece fácil, ¿no? Pues, como quizás ya te imaginabas, no es así de sencillo. Y mejor así, que si no, no hay chicha y el trabajo puede resultar aburrido.
No hay que olvidar que hoy en día el testing (y la traducción, vaya) se realiza mientras el juego o software se está desarrollando, por lo que las funcionalidades y los textos cambian de un día para otro, así que es fácil que el test plan quede obsoleto rápidamente. Asimismo, un test plan asume que el usuario va a realizar una serie de acciones en un determinado orden, pero ¿qué pasa cuando no es así? Que se puede liar parda. Esto es más un problema de testing funcional que de testing lingüístico, pero vaya, que debemos tener mucho cuidado con dónde salen algunos textos que se vuelven a utilizar en varios sitios o mensajes con variables. Mi consejo es seguir el test plan a la vez que se prueban todo tipo de cosas inesperadas para ver si se produce algo extraño.
El debug: con trampa y con cartón
Así que el test plan te dice que tienes que comprobar qué sale en una aplicación cuando estás en Londres para ver si la moneda sale en GBP, ¿eh? Mmmm, ¿cómo lo hacemos? Fácil: con el debug. El debug es básicamente una serie de opciones añadidas por los desarrolladores para comprobar ciertas partes de un programa o videojuego que costaría bastante reproducir en condiciones normales. Por ejemplo, en un juego como Animal Crossing, donde según el día y lo que hayas hecho hasta entonces te puede salir un texto u otro, es casi imposible seguir un test plan sin la ayuda de un debug. Entre otras genialidades del debug están el poder elegir la fase, engañar al sistema sobre tu ubicación si se trata de un programa, tener vidas infinitas… No obstante, el uso del debug se prohíbe muchas veces a los testers (que no los traductores) cuando ya se está en fases medianamente avanzadas de testing, pues la gracia es reproducirlo todo como si se tratara de la versión final.
Como anécdota, no es la primera vez que he visto que una “ayudita” de estas ha terminado convirtiéndose en una funcionalidad, como en un juego de estrategia en el que se podía aumentar la velocidad con una combinación de botones. Sí, ¡el (de)bug se convirtió en feature, señores! 
¡Eso es todo, amigos! + Vida extra
Hasta aquí el especial “testing de videojuegos y software”. 
Por supuesto, se trata de una introducción, y no hay nada como trabajar dentro de una empresa para ver cómo funciona todo (y comprobar, por desgracia, que veces ni siquiera hay test plans o que todo falla estrepitosamente). Si os interesa ampliar el tema, os recomiendo dos libros que están bastante bien:
-
Game QA & Testing: el libro es caro, pero es una delicia de leer, ya que está lleno de imágenes y hay muchas entrevistas. A mí me gustó mucho, aunque evidentemente se centra en testing de funcionalidad sobre todo, ya que es el testeo más habitual. Hace unos años hice una reseña.
-
Game Testing All in One: este libro es ya para hardcore testers, porque describe unas movidas que flipas de automatización de pruebas y demás que no veas. El tío que lo ha escrito sabe mucho, y el primer capítulo sobre las dos reglas que debe seguir un tester no tiene desperdicio. No he llegado a terminarlo, pero si te quieres dedicar a esto profesionalmente, es un libro que tener muy en cuenta.
Si quieres que trate algún otro tema relacionado o quieres comentar algo, no tienes más que decírmelo en los comentarios. ¡Gracias!
Pero al menos, si luego algo sale mal, que no sea por que no lo habíamos dicho…
Últimos comentarios