Acerca del Beta-Testing

De WikiCAAD, la enciclopedia aventurera.

Esta es la traducción temporal de Jhames para un artículo que escribió Emily Short en el año 2003 más o menos, y que solía estar en su página web. Posteriormete le solicitaron que lo volviera a subir, lo cual hizo con algunas correcciones menores.

Contenido

Versión en Español

Lo que viene a continuación, son algunas sugerencias basadas en mi propia experiencia de betatesting, tanto del lado del probador como del autor. No todo los consejos que se citan serán universalmente aplicables, por supuesto. Aplícalos según tu propio criterio.

El Lado del Probador

Regla 1ª: No liberar la beta que te dan para testear

Esto debería ser obvio, pero lo menciono porque este es el aspecto más importante de la confianza en el betatester. También, lo es no comentar el juego que se está probando en público antes de que sea liberado. Y por supuesto no mencionar, los errores que se encuentren en la versión preliminar, a menos que se tenga el permiso explícito del autor.

Establecer un formulario de retroalimentación

Si el autor no aclara este punto, y no es un autor con el que se haya trabajado anteriormente, por lo general es conveniente preguntar que tipo de retroalimentación le gustaría recibir. Hay dos cosas que aclarar, la forma y el contenido.

Contenido

Algunas personas sólo quieren informes sobre errores de programación en el funcionamiento del juego; otros quieren una crítica al por mayor de la experiencia de jugar el juego entera. Los primeros aparecen con frecuencia sobre todo cuando el autor quiere un rebetatesting de una nueva versión de un juego que ya ha sido liberado- por ejemplo para participar en un concurso que ha sido convocado un año más tarde. Hay buenas razones para testear otra vez antes de liberar de nuevo el juego, asegurarse que ningún nuevo error de programación se ha colado sigilosamente mientras los viejos estaban siendo arreglados. En esta situación, sin embargo, es demasiado tarde para hacer comentarios sobre la trama o cosas así que podrían ser realmente útiles. En otros contextos, sin embargo, los autores pueden agradecer la retroalimentación en los aspectos que no atañen a errores de programación del juego. Tengo comentarios del pasado sobre la dificultad de rompecabezas y pistas; sobre la eficacia de mi diseño del Interfaz del Ussuario (IU); sobre verbos adicionales que serían agradables tener, o más comentarios adicionales que harían que el juego tuviese más carne en el asador;

Forma

Algunos autores quieren recibir transcripciones de la experiencia del juego entera, mientras otros quieren sólo un mensaje que resuma los errores de programación encontrados. Si yo soy betatester de un juego, juego con "transcripción activada" - tanto si el autor ha solicitado transcripciones como la forma de retroalimentación - y luego tengo la transcripción para referirme a determinadas cosas. Con frecuencia, envío la transcripción anotada junto con unos párrafos de resumen que contienen mis sentimientos totales sobre el juego y cualquier cosa que pienso que sea lo más importante para cambiarse o mejorar. (También añado unas líneas del estímulo sobre las partes del juego que me han gustado, pero este no es un aspecto esencial del trabajo del betatester. La tarea principal es conseguir que el juego se encuentre de forma de jugable; mantener al autor feliz no es a veces absolutamente compatible con aquella tarea.)

Cuando digo que anoto una transcripción, lo que quiero decir es que tecleo mis comentarios directamente en el juego cuando juego, por lo general introduciendo (aquí la consistencia es la clave) asteriscos o paréntesis, tales como: 

> * Espacio ausente en el segundo párrafo.
> * Dejé caer el cubo sin propiedades, pero todavía sigue en mi inventario.

(TADS y algunas generaciones de Inform actuales aseguran que esta anotación de ningún modo haga que juego corra un turno tras un comando que comienza con *.) Típicamente leo la transcripción entera rapidamente al menos una vez, pero a veces, más tarde cuando quiero examinar errores de programación específicos encuentro que la buscabilidad es muy importante.

Este es el comportamiento estandar del betatester (si es que puede decirse que algo es estándar en esta comunidad). Algunos de mis testers se vuelve muy habladores con estos comentarios, y también consigo cosas como ésta: 

> * Yay!
> * ¿Esperar, qué??
> * ARGH
> * Pensé que el Marqués era más viejo que esto.
> * Rowr.

...etc. Ésta algo parecido a como si el tester tuviese una conversación contínua conmigo sobre el juego cuando él o ella lo están jugando.

Sigue tu propio estilo

Lo que realmente hagas mientras pruebas un juego, depende principalmente de tí. Como he mencionado en otra parte, algunos de mis probadores juegan como si experimentaran el juego como jugadores regulares - lo cuales útil, y les da una clase de perspectiva al juego de jugador regular. También he tenido o he oído de testers que

  • Prueban cada dirección posible de cada localidad posible, incluso si allí se supone que no hay ninguna salida.
  • Cierran cada puerta detrás de ellos cuando pasan por un área, y/o por otra parte experimentan con restaurar cosas a sus condiciones iniciales.
  • Despiadadamente repiten todas las acciones RELACIONADAS CON LOS PSIs - mostrándoles los objetos dos veces, preguntándoles las mismas preguntas otra vez, etcétera, para ver si hay errores de dos veces o sólo una vez.
  • Intentar atacar, romper, cortar, quemar, o destruir por otra parte todos los objetos importantes para ver si ellos se relacionaron apropiadamente y si es posible perder artículos críticos en el juego.
  • PONER TODOS los objetos en cada contenedor para ver si las capacidades y los tamaños son manejados con inteligencia.
  • Utilizar cualquier nuevo verbo especial que yo había escrito en los objetos más inverosímiles - escenario, otros personajes, jugador, etc.
  • Desensamblar el fichero del juego a fin de encontrar cosas que deberían haber sido accesibles, pero no lo son.
  • Poner el monitor o pantalla ajustado diferentes tamaños para ver como se comporta la Interfaz del Usuario en tamaños diferentes y proporciones de aspecto.

Las pruebas de un juego a menudo implican deliberadamente tratar de romperlo. Cuando usted juega a un juego, usted puede conseguir un sentido de donde el código probablemente será el más complicado. Algo que implica un gatillo de complot importante, cualquier simulación compleja, cualquier verbo añadido o lengua: éstos son cosas que pueden usar la investigación especial. Pero por último, usted debería hacer lo que le gusta probando. Esto es la parte del trabajo del autor para encontrar varios probadores de la beta y, de ser posible, conseguir a varios probadores de temperamentos diferentes. Nadie el probador hará o pensará en todo - tan haga lo que usted hace todo lo posible, y confianza que alguien más agarrará en que usted no piensa.

Envía informes a trozos

A menos que el juego que estés probando sea corto o el autor haya dejado claro que tiene una preferencia diferente, a menudo tiene sentido enviar tus informes en serie en lugar de un fichero enorme. Puede que sólo tengas unas horas al día para concentrarte en el juego; el autor preferirá probablemente conseguir el detalle del informe inmediatamente, de modo que pueda comenzar a arreglar los erroes de programación, y también porque permanecer a la espera en la expectativa de retroalimentación produce unos nervios difíciles de controlar. También, un correo electrónico enorme que contenga cientos de errores desalienta mucho más que cinco correos electrónicos cada uno con treinta o cuarenta. En mis juegos más grandes he corregido miles de errores.

El procedimiento de operaciones general para mis testers es por lo general que ellos jueguen a mi juego hasta que hayan trabajado en algunas transcripciones y se hayan atascado o hayan llegado a un punto de ruptura de la trama principal. Entonces, ellos me envían los archivos, y hacen cualquier pregunta sobre los puzzles que tienen que solucionar rompecabezas que los están desalentando. Nunca envío walkthroughs (soluciones paso a paso) a mis betatesters de antemano, porque averiguar como se relacionan con los rompecabezas, y si están frustrados, es parte de lo que uso en el proceso de pruebas.

Asumiendo que el autor esté interesado, comparte tus reacciones

Siempre me gusta saber como se sienten mis probadores con el juego. A veces ellos tienen quejas específicas sobre el modo en que he arreglado las ventanas, o sobre mi escritura, o sobre el modo en que un rompecabezas tiene pistas. A veces ellos sólo tienen impresiones vagas - un sentimiento de que el juego es demasiado apresurado o demasiado flojo, o que la narrativa es demasiado confusa. Incluso esa clase de información es útil, sobre todo tomada en combinación con la reacción de otros betatesters: esto da al autor una idea de como será, probablemente, recibido el juego, y puede permitirle diagnosticar el problema, incluso si no sabe que es exactamente lo que está mal.

Si vas a dejar de probar, avisa al autor

No es de nada infrecuente para un tester encontrarse muy ocupado durante un tiempo e incapaz de terminar de probar un juego. Si estás probando, lo haces bajo tu propia voluntad, y no hay ninguna vergüenza unida al hecho de dejarlo - porque estés ocupado, o porque el juego no es de tu gusto. (Si realmente te disgusta un juego, con poca probabilidad serás un buen testeren cualquier caso: demasiado del proceso requiere buena voluntad por tu parte. Es cosa de encontrar un trabajo con errores, pero intrigante - que puedas trabajar con el. Si no piensa que te gustará alguna vez esto sin embargo, aunque esté bien planteado, sin embargo, deberías pensar en dejarlo de lado y trabajar en otra cosa.)

Si realmente lo dejas, deberías hacer saber al autor que has decidido no continuar, de modo que pueda encontrar un tester sustituto. Simplemente el cese de enviar informes puede dejar al autor en una posición de expectativa incómoda.

El Lado del Autor

Pónte en contacto con el probador de la beta y aclara tus peticiones

En particular, es una idea buena mencionar unos o todos los puntos siguientes, si ellos son importantes para tí:

Margen de tiempo

Menciona cuando planeas liberar el juego (y de este modo el margen de tiempo que se dispone), si trabajas en algo que tenga que salir en un tiempo específico. Esto no garantiza que tu probador sea capaz de terminar el juego en el tiempo que indicas, pero significa realmente que tienes una posibilidad para contestarle y decirle que su agenda no va a encajar con lo que tienes planeado.

Formato

Dile si necesitas sus informes en un formato específico. Con este no quiero decir nada realmente complicado - no hay por lo general ninguna razón para arreglar las anotaciones en una forma especial - pero puede ser a veces útil pedir a los probadores que te envíen sus transcripciones del juego. De hecho, esto es con frecuencia muy valioso, por lo que recomiendo a todo el mundo que lo haga. No sólo hace posible reproducir errores que ocurren en condiciones meticulosas o raras, también significa que puedes ver cosas que el probador de la beta realmente no podría relatar como errores de programación: sitios donde el fraseo no funciona, donde el probador tenía obviamente el problema, donde intentó algo que le gustaría poner en práctica. Trato de poner en práctica respuestas, tanto como es razonable, para que mis probadores lo intenten: cualquier objeto o partes de objetos que no tienen descripciones, ningún verbo que es sugerido por la narrativa, etcétera. El Último Punto de una de mis aventuras viene de una acción que un probador de beta trató de realizar, y pensé que era bastante graciosa como para ponerla en práctica.

Verbos especiales

Algunos autores añaden verbos especiales a sus juegos para hacer la anotación más fácil, y/o verter el estado de juego a la transcripción después de que un error haya ocurrido. Si usas algo como ésto, deberías obviamente darle pistas al probador de la beta acerca de ellos.

Cualquier corrección importante

A veces comienzo a probar las fases que se abren de un juego antes de que la fase final sea completada. Hay dos motivos por qué hago ésto: uno es por hacer las que las cosas vayan más rápido si trabajo contra una fecha límite de concurso o algo similar; el otro es que a veces la retroalimentación del tester requiere cambios estructurales que son más fáciles de poner en práctica si el juego no está completamente terminado. Técnicamente hablando, es un "pre-betatesting ", y esto requiere entendimiento extra y cooperación de los betatester - de este modo siempre trato de avisarlos en qué se están moviendo. Si hay algún trozo del juego que está inacabado, hago saber al tester que esto es así; también trato de poner un final en el juego después del rompecabezas final (actualmente resoluble), para indicar al teste que ha llegado tan lejos como se puede ir.

Haz todo lo posible para preprobar el juego

Trata de no enviar a tus probadores algo cuyos errores sean obvios para tí, incluso en un juego trivial. Incluso si envías un juego que no está completo en cada aspecto, las partes que sobre las que preguntes a tus tester que jueguen deberían ser jugables: los rompecabezas deberían estar (por lo que tu sepas) completos y con pistas bien informadas, la prosa debería ser (con lo mejor de tu capacidad) carente de errores ortográficos, etcétera. Te equivocará en muchas cosas, naturalmente, pero deberías intentarlo; no hay ninguna razón para pedirle a tus testers que te digan cosas que ya sabes, y estarás malgastando su tiempo y su paciencia.

Con esto en mente, hay un par de cosas bastante triviales que puedes querer comprobar por tí mismo antes del envío.

  • Si lo tuyo no es la ortografía, vuelca tu texto del juego a un archivo y compruébalo ortográficamente. Tus probadores todavía pueden ver cosas que el verificador de ortografía pasó por alto, pero esto bajará al menos el número de cosas triviales en las que ellos tienen que concentrarse.
  • Controla tus respuestas por defecto, las que has tomado prestadas de la biblioteca existente. (Inform las pone en English.h.) Ver si hay cualquiera que sea totalmente inadecuada para tu juego. Igualmente, si usas Inform y normalmente usas la ortografía americana, asegúrate y pon la contante DIALECT_US de modo que la biblioteca sea consecuente con ello.
  • Si has añadido nuevos verbos con nueva funcionalidad, considera si hay algún sinónimo razonable que no has explicado. También, asegúrate que has explicado los casos de problema: ¿tiene sentido la rutina de verbo cuándo aplicado a un objeto es intocable? ¿fuera de alcance? ¿vivo? ¿paisaje no movible? ¿el personaje de jugador en sì mismo?
  • ¿Si has añadido nueva gramática, es consecuente con la vieja materia? Un problema que he visto - más de una vez - ocurre cuando el autor ha añadido gramática para manejar un complemento indirecto (> GOLPEA HOMBRE CON PALO, por ejemplo) pero no ha cambiado la respuesta por defecto a > GOLPEA HOMBRE. De modo que solamente golpear al hombre con el palo puede ser la única solución de un rompecabezas, pero >GOLPEA HOMBRE aparecerá como “La Violencia no es la solución.” Con severo engaño.
  • Por supuesto no vas a conseguirlo cubrir todas las posibilidades. Sin embargo, éstos son sitios donde es en particular fácil generar errores. Cuanto menos tengan que luchar los tester en su camino con errores simples, más tiempo y energía tendrán que dedicarse a los complicados.

(También puedes estar interesado en mis comentarios más recientes de la preparación de un juego para pruebas.)

Haz preguntas

Una vez que recibas tu informe, siéntete libre de ponerte en contacto con el probador de la beta sobre algo que no entiendas: las circunstancias bajo las cuales tu juego hizo que cascase el intérprete, la razón por la que no le gusta su principal PSI, etcétera. Si se aburrió, averiguar donde lo hizo. Intenta evitar ser defensivo o justificar tus decisiones en esta etapa: puedes tener una buena razón para hacer cosas de la manera que las hiciste, pero en la mayor parte de casos al menos encuentro que es realmente contraproducente convencer al probador de la beta que tientes razón. Lo que quiero es encontrar algo que soluciones los problemas que el probador de la beta experimente sin arruinar mi concepto original.

Original en Inglés

The following are some suggestions based on my own experience of beta-testing, both from the tester’s side and from the author’s. Not all of the advice it contains will be universally applicable, of course. Pick as you will.

The Tester's Side

Rule 1: Do not release the beta you’re given

This should be obvious, but I mention it because it is the most important aspect of the beta-tester’s trust. Also, do not discuss the game you’re testing in public before it is released. And do not, ever, mention the bugs you encountered in the pre-release version, unless you have the author’s explicit permission.

Establish a form for feedback

If the author doesn’t make this clear, and it’s not an author I’ve worked with before, I usually ask what kind of feedback he would like to receive. There are two things to settle on, form and content.

Content

Some people only want reports on bugs in the function of the game; others want a wholesale critique of the entire gameplay experience. The former comes up especially frequently when the author is re-beta-testing a new version of a game that has already been released — say a competition game that he has reworked a year later. There’s good reason to test again before re-releasing the game, to make sure that no new bugs have crept in while the old ones were being fixed. In this situation, though, it’s too late for remarks about the plot and so on to be really useful. In other contexts, however, authors may welcome feedback on the non-bug aspects of the game. I have in the past gotten comments about puzzle difficulty and cluing; about the efficacy of my UI design; about additional verbs that would be nice to have, or additional comments that might flesh the game out more;

Form

Some authors want to receive transcripts of your entire play experience, while others want just a message summarizing the bugs you found. If I’m beta-testing a game, I play with scripting on — whether or not the author has requested transcripts as the form of his feedback — and then I have the transcript to refer back to. Frequently, I send the annotated transcript along with a few paragraphs of summary that contain my overall feelings about the game and any things I think are most important to change or improve. (I also try for a few lines of encouragement about the parts of the game I did like, but this is not an essential aspect of the beta-testing job. The chief task is to get the game into playable shape; keeping the author happy is sometimes not perfectly compatible with that task.)

When I say that I annotate a transcript, what I mean is that I type my comments directly into the game as I play, usually prefaced (consistency is the key here) with asterisks or brackets, like so: 

>* Missing space in the second paragraph.
>* I dropped the featureless cube but it's still in my inventory.

(TADS and some generations of Inform actually provide for this annotation so that no game time will elapse after a turn that starts with *.) Typically I read the entire transcript through at least once, but sometimes later when I want to review specific bugs I find the searchability important.

This is pretty standard beta-tester behavior (inasmuch as anything can be said to be standard in this community). Some of my testers get quite chatty with these comments, and I also get things like this: 

>* Yay!
>* Wait, what??
>* ARGH
>* I thought the Marquis was older than that.
>* Rowr.

…etc. It’s sort of as though the tester is having a running conversation with me about the game as he or she plays.

Follow your own style

What you actually do while testing is largely up to you. As I mention elsewhere, some of my testers play as though they were experiencing the game as regular players — which is useful, and gives them a regular-player sort of perspective on the game. I have also had or heard of testers who

  • Tried every possible direction from every possible room, even if there wasn’t supposed to be an exit there.
  • Closed every door behind them when passing through an area, and/or otherwise experimented with restoring things to their initial conditions.
  • Ruthlessly repeated all NPC-related actions — showing them things twice, asking them the same questions over again, and so on, to see whether critical triggers fired twice or only once.
  • Tried to attack, break, cut, burn, or otherwise destroy all important objects to see whether they interacted appropriately and whether it was possible to lose game-critical items.
  • PUT ALL into each container item to see whether capacities and sizes were handled intelligently.
  • Ran around using any special new verbs I’d written on the most implausible objects — scenery, other characters, the player, etc.
  • Disassembled the gamefile in order to find things that should have been accessible, but weren’t.
  • Set their monitor or screen size to different settings to see how a graphical UI behaved at different sizes and aspect ratios.

Testing a game often involves deliberately trying to break it. As you play a game, you may get a sense of where the code is likely to be most complicated. Anything that involves an important plot trigger, any complex simulation, any added verbs or language: these are things that can use special investigation. But ultimately, you should do what you like when testing. It is part of the author’s job to find several beta-testers and, if possible, to get several testers of different temperaments. No one tester will do or think of everything — so do what you do best, and trust that someone else will catch whatever you don’t think of.

Send reports in chunks

Unless the game you’re testing is a short one or the author has made it clear he has a different preference, it often makes sense to send your reports serially rather than in one big batch. You may only have a few hours at a time to concentrate on a game; the author would probably prefer to get that feedback immediately, so that he can start fixing those bugs, and also because waiting in limbo for feedback is nerve-wracking. Also, a huge email containing hundreds of bugs is much more daunting than five emails each with thirty or forty. In my larger games I have fixed thousands of bugs.

The general operating procedure for my testers has usually been that they will play my game until they’ve worked up a few transcripts and have gotten stuck or come to a major plot break-point. Then they send me the files, and ask any questions they have about how to solve puzzles that are daunting them. I never send walkthroughs to my testers in advance, because finding out how they interact with the puzzles, and whether they get frustrated, is part of what I use the testing process for.

Assuming the author is interested, share your reactions

I always like to know how my testers feel about a game. Sometimes they have specific complaints about the way I’ve arranged the windows, or about my writing, or about the way a puzzle is clued. Sometimes they only have vaguer impressions — a sense that the gameplay is too rushed or too slack, or that the narrative is too confusing. Even that kind of information is useful, especially taken in combination with the feedback from other testers: it gives the author an idea of how the game is likely to be received, and may allow her to diagnose the problem, even if you don’t know what exactly is wrong.

If you have to stop, let the author know

It’s not at all infrequent for a tester to find herself swamped for time and unable to finish testing a game. If you’re testing, you’re doing so at your own option, and there’s no shame attached to quitting — either because you’re busy, or because the game is not to your taste. (If you really dislike a game, you’re unlikely to be a good tester for it anyway: too much of the process requires goodwill on your part. It’s one thing to find a work flawed but intriguing — that you can work with. If you don’t think you’ll ever like it however well-executed it is, though, you should think about putting it aside and working on something else.)

If you do quit, you should let the author know that you’ve decided not to go on so that he can find a replacement tester. Simply ceasing to send reports may leave the author in an uncomfortable limbo position.

The Author’s Side

Contact the beta-tester and make your requests clear

In particular, it’s a good idea to mention some or all of the following points, if they’re important to you:

Time-frame

Mention when you are planning to release the game (and thus what your time-frame is), if you’re working on something that has to come out at a specific time. This doesn’t guarantee that your tester will be able to finish your game in the time you indicate, but it does mean he has a chance to write back and tell you that his schedule isn’t going to fit that.

Format

Say whether you need your feedback in a specific format. By this I don’t mean anything really complicated — there’s usually no point in arranging annotations in a special form — but it can sometimes be useful to ask that testers send you their transcripts from game play. In fact, this is so frequently valuable that I recommend everyone do it. Not only does it make it possible to reproduce bugs that occur under finicky or rare conditions, but it means that you can see things your beta-tester might not actually report as bugs: places where phrasings didn’t work, where the tester was obviously having trouble, where he tried something that you might like to implement. I try to implement responses, as much as is reasonable, for whatever my testers try: any objects or parts of objects that didn’t have descriptions, any verbs that are suggested by the narrative, and so on. The Last Lousy Point in Savoir-Faire comes from an action that a beta-tester tried to perform, and I thought it was funny enough to implement.

Specialty verbs

Some authors add special verbs to their games to make annotation easier, and/or to dump the game state to transcript after a bug has occurred. If you’re using anything like this, you should obviously clue the beta-tester in about them.

Any important disclaimers

I sometimes begin testing the opening phases of a game before the endgame is complete. There are two reasons why: one is that it makes things go faster if I’m working against a competition deadline or something similar; the other is that sometimes tester feedback necessitates structural changes that are easier to implement if the game is not completely finished. Technically speaking, this is pre-beta-testing, and it requires extra understanding and forebearance from the testers — so I always try to let them know what they’re in for. If there are any bits of the game that are unfinished, I let the tester know that this is the case; I also try to put an ending in the game after the final (currently-solvable) puzzle, to indicate to the tester when he’s gone as far as he can go.

Do your best to pre-test the game

Try not to send your testers something whose bugs are obvious to you even on a trivial playthrough. Even if you’re sending over a game which isn’t complete in every aspect, the parts you’re asking your testers to test should be playable: the puzzles should be (as far as you know) complete and well-clued, the prose should be (to the best of your ability) devoid of typos, and so on. You’ll be wrong about this, naturally, but you should try; there’s no point in asking your testers to tell you things that you already know, and you’ll be wasting their time and patience.

With that in mind, there are a couple of fairly trivial things you may want to check yourself before sending.

  • If you’re not strong on spelling, dump your game text to a file and spellcheck it. Your testers may still turn things up that the spellchecker missed, but it will at least lower the number of trivial things they have to concentrate on.
  • Check over your default responses, the ones you borrowed from the existing library. (Inform puts these in English.h.) See if there are any that leap out at you as totally inappropriate for your game. Likewise, if you use Inform and you normally use American spellings, be sure and set the constant DIALECT_US so that the library will be consistent with you.
  • If you’ve added new verbs with new functionality, consider whether there are any reasonable synonyms you haven’t accounted for. Also, make sure that you’ve accounted for the problem cases: does the verb routine make sense when applied to an object that’s untouchable? out of reach? alive? unmoveable scenery? the player character herself?
  • If you’ve added new grammar, is it consistent with the old stuff? One problem I’ve seen — more than once — occurs when the author has added grammar to handle an indirect object (>HIT MAN WITH STICK, say) but hasn’t changed the default response to >HIT MAN. So hitting the man with the stick may be the only solution to a puzzle, but >HIT MAN will turn up “Violence isn’t the answer to this one.” Severely misleading.
  • Of course you’re not going to get everything. These are places where it’s particularly easy to generate errors, however. The less your testers have to fight their way through simple errors, the more time and energy they’ll have to devote to the trickier ones.

(You may also be interested in my more recent comments on preparing a game for testing.)

Ask questions

Once you receive your report, feel free to contact the beta-tester about anything you don’t understand: the circumstances under which your game crashed the interpreter, the reason he doesn’t like your lead NPC, and so on. If he got bored, find out where he got bored. Try to avoid being defensive or justifying your decisions at this stage: you may have a good reason for doing things the way you did, but in most cases I at least find it’s actually counter-productive to convince the beta-tester that I’m right. What I want is to find something that will fix the problems the beta-tester experienced while not ruining my original concept.

Enlaces de interés

Enlaces externos

Obtenido de "http://wiki.caad.es/Acerca_del_Beta-Testing"
Herramientas personales