- Guía de pruebas de Agents Please: Organiza las pruebas en torno a las funciones, la progresión, la estabilidad y los riesgos que afectan a los jugadores.
- Casos de prueba: Empieza con comprobaciones repetibles para menús, misiones, combate, recompensas y progresión de la cuenta.
- Informes de errores: Registra los pasos, los resultados esperados, los resultados reales, la gravedad y las pruebas de apoyo.
- Pasadas de regresión: Vuelve a comprobar las funciones corregidas después de parches, cambios de equilibrio y actualizaciones de contenido.
- Objetivo de lanzamiento: Prioriza los bloqueos que impidan progresar, provoquen pérdida de datos o hagan que los sistemas principales no sean fiables.
Guía de pruebas de Agents Please: qué probar primero
La mejor guía de pruebas de Agents Please comienza con un alcance de pruebas claro. No intentes comprobar todas las interacciones posibles al mismo tiempo. Divide la experiencia en áreas que afecten a la progresión, al juego momento a momento, a la estabilidad de la cuenta y a la facilidad de uso general de la interfaz.
En una primera pasada, céntrate en los recorridos que probablemente seguirá un jugador. Un jugador nuevo debería poder iniciar la experiencia, entender el primer objetivo, completar una actividad inicial, recibir la recompensa esperada y continuar progresando sin confusión ni interrupciones.
Prueba primero las funciones que determinan si los jugadores pueden comenzar, progresar, guardar su avance, reclamar recompensas y recuperarse de errores comunes antes de revisar detalles opcionales.
Progresión principal
- Iniciar una sesión nueva
- Completar un objetivo
- Recibir crédito de progresión
- Confirmar el siguiente desbloqueo
Acceso a funciones
- Abrir cada menú principal
- Comprobar los estados bloqueado y desbloqueado
- Confirmar las etiquetas de navegación
- Verificar los controles para volver y cerrar
Comprobaciones de estabilidad
- Cargar contenido activo
- Transicionar entre áreas
- Recuperarse después de una interrupción
- Confirmar que el progreso permanece intacto
Un plan de pruebas útil separa las pruebas de humo de las comprobaciones más profundas. Las pruebas de humo responden si la versión actual es utilizable. Después, una pasada completa examina casos límite, acciones repetidas, entradas inusuales e interacciones entre sistemas.
| Área de prueba | Primera comprobación | Condición de aprobación | Prioridad |
|---|---|---|---|
| Flujo de inicio | Iniciar la experiencia y llegar a la primera pantalla controlable | No aparece ningún error bloqueante ni reinicio inesperado | Crítica |
| Progresión | Completar un objetivo inicial | El progreso se actualiza correctamente | Crítica |
| Recompensas | Reclamar o recibir una recompensa | La recompensa aparece en la ubicación correcta | Alta |
| Menús | Abrir, cerrar y navegar por los menús principales | Los controles responden de forma coherente | Alta |
| Guardado | Salir y volver después de progresar | El progreso válido se conserva | Crítica |
Mantén la primera sesión breve y repetible. Un recorrido de prueba de humo de cinco minutos es más fácil de ejecutar después de cada actualización que una lista de comprobación extensa que los testers evitan porque requiere demasiado tiempo.
Crea casos de prueba fiables
Un caso de prueba sólido explica qué hacer y qué debería ocurrir. Evita instrucciones vagas como “comprueba la misión” o “mira si funcionan las recompensas”. En su lugar, define el estado inicial, la acción y el resultado esperado.
Usa la misma estructura para cada función:
- ID de prueba: Un identificador breve como
PROG-001. - Configuración: Estado requerido de la cuenta, función desbloqueada o ubicación inicial.
- Pasos: Acciones escritas en el orden en que las realiza el tester.
- Resultado esperado: Comportamiento observable que define el éxito.
- Resultado real: Lo que ocurrió durante la prueba.
- Estado: Aprobado, fallido, bloqueado o necesita repetición.
Otra persona debería poder aprobar una prueba sin tener que adivinar. Sustituye “la recompensa funciona” por “la recompensa aparece en el inventario y el estado de finalización se actualiza”.
Elige un estado inicial
Registra las condiciones necesarias antes de realizar la prueba. Incluye el perfil seleccionado, el contenido desbloqueado, los recursos disponibles y cualquier estado requerido de la misión o la función.
Realiza una acción clara
Usa una secuencia de acciones concreta. Si la prueba abarca varios sistemas, divídela en casos separados para que el origen de un fallo quede claro.
Compara el resultado
Comprueba el resultado visible frente al comportamiento esperado. Verifica tanto la respuesta inmediata como el estado relacionado de progresión, inventario o menú.
Recopila pruebas
Guarda una captura de pantalla, grabación, registro u observación escrita cuando el resultado difiera de lo esperado. Las pruebas ayudan a reproducir el problema más adelante.
Restablece y repite
Vuelve al estado original cuando sea posible. Repite los casos importantes después de un reinicio limpio para distinguir los errores constantes de las condiciones temporales.
Usa una matriz de pruebas compacta para evitar probar demasiado las funciones sencillas mientras no cubres lo suficiente las de alto riesgo.
| Tipo de función | Caso normal | Caso límite | Caso de recuperación |
|---|---|---|---|
| Objetivo | Completar la tarea con normalidad | Salir y volver antes de completarla | Reiniciar después de una interrupción |
| Recompensa | Reclamar la recompensa esperada | Reclamarla con capacidad limitada | Volver a abrir la función después de reconectarse |
| Menú | Abrir y seleccionar una opción | Cambiar de pestaña rápidamente | Cerrar y volver a abrir después de un error |
| Combate o acción | Usar la habilidad prevista | Repetir la entrada durante el enfriamiento | Recuperarse después de ser derrotado o fallar una acción |
| Progresión | Desbloquear el siguiente estado | Alcanzar exactamente el requisito | Recargar después de que se produzca el desbloqueo |
Para obtener resultados repetibles, prueba el mismo caso varias veces cuando implique tiempos, transiciones, condiciones de red o estados de interfaz que cambien rápidamente. Un solo intento exitoso no demuestra estabilidad.
Comprobaciones de juego, interacción y progresión
Probar sistemas interactivos requiere algo más que confirmar que una acción produce un efecto visual. Comprueba si la acción cambia el estado correcto y si los sistemas relacionados responden adecuadamente.
Por ejemplo, cuando se completa un objetivo, verifica el marcador del objetivo, el rastreador de progreso, la notificación de recompensa, el inventario y la siguiente actividad disponible. Una función puede parecer operativa y, sin embargo, no conceder crédito ni actualizar la progresión del jugador.
Los errores más dañinos no siempre son cierres inesperados. Las recompensas ausentes, los indicadores de finalización incorrectos, los objetos duplicados y la pérdida de progreso pueden socavar la confianza del jugador sin producir un error evidente.
Prueba el contenido interactivo en tres niveles:
- Respuesta de entrada: ¿La acción responde al control o selección previstos?
- Resultado del sistema: ¿Se produce el cambio de estado correcto?
- Comportamiento posterior: ¿Los menús, las recompensas, los objetivos y el contenido posterior reconocen ese cambio?
| Punto de comprobación | Qué verificar | Patrón de fallo habitual |
|---|---|---|
| Entrada | Los botones, selecciones y atajos responden | La entrada se ignora o activa la acción equivocada |
| Feedback | Aparece una animación, texto, sonido o notificación | La acción tiene éxito sin una confirmación clara |
| Cambio de estado | Se actualiza el objetivo, recurso o desbloqueo | Se reproduce el efecto visual, pero los datos no se actualizan |
| Restricciones | El contenido bloqueado sigue sin estar disponible | Los requisitos se omiten o se muestran incorrectamente |
| Acción repetida | Las entradas repetidas se comportan de forma segura | Se duplican las recompensas o las interacciones se bloquean |
| Transición | La siguiente pantalla o área carga correctamente | Bloqueo parcial, interfaz ausente o carga interminable |
Presta especial atención a las condiciones límite. Prueba acciones justo al principio y al final de los temporizadores, los límites de recursos, la capacidad del inventario, los umbrales de objetivos y los requisitos de desbloqueo. Estas condiciones suelen revelar problemas de redondeo, visualización o sincronización de estados.
Si la experiencia incluye combate u otras interacciones en tiempo real, varía el ritmo de las pruebas. Comprueba entradas deliberadas, entradas rápidas, acciones interrumpidas, cambios de objetivo y la recuperación después de un intento fallido. El objetivo no es demostrar que funciona una única secuencia ideal, sino confirmar que el comportamiento normal del jugador sigue siendo comprensible y recuperable.
Informes de errores, gravedad y clasificación
Un informe de errores debe ayudar a otra persona a reproducir el problema sin necesidad de una explicación en directo. Escríbelo como un registro factual y no como una queja general.
Incluye la secuencia exacta que produjo el problema, el resultado esperado, el resultado real y si el problema ocurrió una vez o de forma repetida. Menciona el entorno de prueba cuando pueda afectar al resultado, como la versión de la compilación, el tipo de dispositivo, el modo de pantalla, el estado de la conexión o la progresión de la cuenta.
Un recorrido de reproducción conciso, un comportamiento esperado claro y pruebas fiables suelen ser más valiosos que una larga descripción de lo frustrante que resulta el problema.
Usa la gravedad para priorizar el impacto en el jugador, no el tamaño visual del defecto.
| Gravedad | Definición | Ejemplo |
|---|---|---|
| Bloqueante | Impide iniciar, progresar o acceder a la experiencia a una parte importante de los jugadores | La experiencia no puede llegar a la sesión principal |
| Crítica | Provoca pérdida de datos, progresión rota o un fallo grave del sistema principal | El progreso completado desaparece al volver |
| Alta | Interrumpe gravemente una función principal, aunque puede existir una solución alternativa | No se puede reclamar una recompensa necesaria |
| Media | Defecto perceptible con impacto limitado o una solución alternativa fiable | El estado de un menú se muestra incorrectamente al volver a abrirlo |
| Baja | Problema cosmético o de usabilidad menor | Una etiqueta está desalineada, pero sigue siendo legible |
Un orden de clasificación útil es:
- ¿Puede el jugador iniciar o continuar?
- ¿Puede el jugador guardar o conservar el progreso?
- ¿Puede el jugador completar la actividad principal?
- ¿Puede el jugador recibir las recompensas esperadas?
- ¿Existe una solución alternativa segura?
- ¿El problema afecta a un estado o a muchos estados?
Evita combinar defectos no relacionados en un solo informe. “El menú es lento, falta la recompensa y el texto del objetivo es incorrecto” debería convertirse en informes separados, a menos que una causa confirmada produzca los tres síntomas.
Al volver a probar una corrección, reproduce primero el caso original. Después, prueba variaciones cercanas. Si se corrigió un problema de recompensas para un objetivo, comprueba otro objetivo con una ruta de recompensa similar. Este es el comienzo de las pruebas de regresión.
Pruebas de regresión y lista de comprobación de lanzamiento
Las pruebas de regresión confirman que un cambio no ha dañado una función existente. Deben ser específicas y no aleatorias. Empieza por los sistemas afectados directamente por la actualización y, después, comprueba las rutas de progresión e interfaz relacionadas con ellos.
Una pasada de lanzamiento práctica puede utilizar tres grupos:
- Conjunto de pruebas de humo: Comprobaciones rápidas que se ejecutan en cada compilación disponible.
- Conjunto de funciones: Comprobaciones detalladas de los sistemas modificados recientemente.
- Conjunto de regresión: Casos fallidos anteriormente y rutas de alto riesgo para el jugador.
Cuando se corrige un defecto, conserva sus pasos de reproducción como un caso de regresión permanente. Esto evita que el mismo fallo vuelva a aparecer sin ser detectado en una actualización posterior.
| Pasada de lanzamiento | Alcance recomendado | Objetivo |
|---|---|---|
| Humo | Inicio, comienzo, progresión, recompensa, salida y regreso | Confirmar que la versión es utilizable |
| Funciones | Mecánicas, menús, contenido o recompensas modificados | Verificar que la actualización funciona según lo diseñado |
| Regresión | Errores corregidos y sistemas relacionados | Detectar fallos repetidos |
| Exploratoria | Comportamiento del jugador sin guion | Descubrir problemas que los casos planificados no cubren |
| Revisión final | Bloqueos, errores críticos y limitaciones conocidas | Decidir si el riesgo del lanzamiento es aceptable |
Lista de comprobación de pruebas de lanzamiento:
- Completar el recorrido de prueba de humo del inicio y la primera sesión
- Verificar un objetivo de progresión y su recompensa
- Repetir las pruebas de todos los problemas de gravedad alta corregidos
- Comprobar los menús principales, las transiciones y el comportamiento de recuperación
- Registrar los riesgos sin resolver con notas de reproducción claras
Las pruebas exploratorias son especialmente valiosas después de aprobar los casos con guion. Intenta cambiar el orden de las acciones, salir de las pantallas antes de tiempo, pulsar los botones repetidamente, volver a áreas anteriores y continuar después de las advertencias. Estos comportamientos se parecen a la actividad real de los jugadores y pueden revelar problemas de estado que un recorrido de prueba limpio nunca alcanza.
Termina con un resumen de riesgos. Enumera la versión probada, los conjuntos completados, los casos fallidos, los casos bloqueados y los problemas de alto impacto sin resolver. Una decisión de lanzamiento resulta más clara cuando las pruebas se organizan en torno al impacto en el jugador, en lugar de basarse en un único porcentaje de aprobación.
Q: ¿Qué debería cubrir primero la guía de pruebas de Agents Please?
Empieza por el inicio, la progresión de la primera sesión, la finalización de objetivos, las recompensas, el guardado, los menús principales y la recuperación después de interrupciones. Estas rutas influyen más en la capacidad de los jugadores para continuar.
Q: ¿Cómo debería redactar un informe de errores de Agents Please?
Incluye el entorno de prueba, el estado inicial, los pasos numerados de reproducción, el resultado esperado, el resultado real, la frecuencia, la gravedad y pruebas de apoyo, como capturas de pantalla o grabaciones.
Q: ¿Cuál es la diferencia entre las pruebas de humo y las pruebas de regresión?
Las pruebas de humo comprueban si una versión es utilizable a un nivel básico. Las pruebas de regresión revisan funciones existentes y errores corregidos para confirmar que un cambio nuevo no ha reintroducido problemas.
Q: ¿Cuándo debe marcarse un error como crítico?
Usa la gravedad crítica para problemas que provoquen una pérdida significativa de progreso, impidan completar contenido principal, rompan sistemas esenciales o dejen a los jugadores sin una forma fiable de recuperarse.
Un proceso de QA disciplinado no exige probar todas las posibilidades antes de cada actualización. Exige comprobar los riesgos adecuados de forma coherente, registrar los resultados con claridad y ampliar la cobertura cuando aparezcan nuevos fallos. Usa esta guía como base para un plan de pruebas repetible de Agents Please y, después, ajústalo a las funciones y rutas de progresión más importantes para tu comunidad.