Parte: 16 — Producción, publicación, monetización y LiveOps · Fuente: Google Testing Blog y prácticas de la Game Developers Conference sobre QA ⏱️ Duración estimada: 80 min · Nivel: Intermedio
El control de calidad (QA) no es "jugar hasta que algo se rompa": es una disciplina con método, artefactos y trazabilidad. En esta clase separamos dos actividades que a menudo se confunden —el testing automatizado (código que verifica código) y el QA manual/exploratorio (personas que ejercen el juego con criterio)— y montamos el circuito que conecta ambas con el equipo de desarrollo.
Al terminar sabrás escribir un plan de pruebas para una funcionalidad concreta, redactar un reporte de bug que otra persona pueda reproducir sin preguntarte nada, y triar una lista de defectos asignando severidad y prioridad. Estos tres artefactos son la columna vertebral de cualquier producción, desde un juego de una persona hasta un estudio con cientos.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | QA vs. testing automatizado | Cubren riesgos distintos; ninguno reemplaza al otro. |
| 2 | Plan de pruebas | Convierte "probar" en algo repetible y medible. |
| 3 | Testing exploratorio | Encuentra lo que ningún caso escrito previó. |
| 4 | Anatomía de un reporte de bug | Un bug irreproducible es un bug que no se arregla. |
| 5 | Severidad vs. prioridad | Evita arreglar lo trivial antes que lo grave. |
| 6 | Triaje de defectos | Ordena el trabajo cuando los bugs superan al tiempo. |
| 7 | Bug tracker y estados | Da trazabilidad de "reportado" a "cerrado". |
| 8 | Pruebas de regresión | Impide que un arreglo rompa algo que funcionaba. |
No necesitas herramientas de pago. Un bug tracker puede ser desde una hoja de cálculo bien estructurada hasta GitHub Issues (https://docs.github.com/issues), Trello, Jira o Linear. Para este laboratorio bastan GitHub Issues o una tabla en Markdown. Ten a mano el juego que vienes construyendo en el curso (o cualquier build jugable) para tener defectos reales que reportar.
Familiarízate con el vocabulario estándar leyendo el glosario de severidad/prioridad de cualquier tracker y una guía de bug reporting: https://www.atlassian.com/software/jira/guides/getting-started/best-practices. Prepara además una plantilla de reporte reutilizable (la construiremos abajo) para no improvisar el formato cada vez.
Producirás tres entregables: una plantilla de reporte de bug, un plan de pruebas de una funcionalidad y una lista triada de bugs.
plantilla-bug.md con esta estructura y consérvalo como base para todos tus reportes:Título: [resumen en una línea, verbo + qué falla]
ID: BUG-000
Severidad: Bloqueante | Mayor | Menor | Cosmético
Prioridad: P0 | P1 | P2 | P3
Entorno: build/versión, plataforma, resolución, dispositivo
Precondiciones: estado necesario antes de empezar
Pasos para reproducir:
1. ...
2. ...
3. ...
Resultado esperado: ...
Resultado obtenido: ...
Frecuencia: siempre | intermitente (X de Y intentos)
Evidencia: captura, vídeo, log
Notas: workaround conocido, hipótesis de causa
| ID | Caso | Precondición | Pasos | Resultado esperado |
| CP-01 | Recoger 1 moneda | Jugador con 0 puntos | Tocar la moneda | Puntaje = valor de la moneda; moneda desaparece |
| CP-02 | Recoger todas | Nivel con 5 monedas | Recogerlas | Puntaje = suma; contador a 0 |
| CP-03 | Moneda ya recogida | Moneda tomada | Volver a pasar | No suma de nuevo |
| CP-04 | Recoger al morir | Vida = 0 en el frame | Tocar moneda | No suma tras game over |
| CP-05 | Persistencia | Cambio de nivel | Pasar de nivel | Puntaje se conserva |
| CP-06 | Límite superior | Puntaje cercano al máximo | Recoger monedas | Sin overflow ni número negativo |
Ejecuta el plan sobre tu juego. Marca cada caso como Pass / Fail. Por cada Fail, abre un reporte usando la plantilla del paso 1.
Triaje. Reúne una lista de 8–10 bugs (los que encontraste más los de esta lista de ejemplo) y asigna severidad y prioridad a cada uno. Justifica en una frase por qué la prioridad puede no coincidir con la severidad (ej.: un crash en una pantalla que nadie visita puede ser Bloqueante de severidad pero P2 de prioridad).
Ordena la lista triada por prioridad y entrega las tres piezas: plantilla, plan de pruebas ejecutado y lista triada.
Toma una funcionalidad de tu juego, escribe un plan de pruebas de mínimo 8 casos, ejecútalo, abre reportes para todos los fallos con la plantilla y entrega una lista triada con severidad, prioridad y una suite de regresión de 5 casos marcada.
Criterio de aceptación: cada reporte de bug puede reproducirse por una persona ajena siguiendo solo los pasos escritos; cada caso del plan tiene resultado esperado inequívoco y veredicto Pass/Fail; y la lista triada está ordenada por prioridad con al menos un caso donde severidad y prioridad difieren, justificado.
| Síntoma | Causa y arreglo |
|---|---|
| Nadie logra reproducir el bug reportado | Faltan precondiciones o entorno. Añade versión de build, plataforma y estado exacto previo. |
| Se arreglan cosméticos mientras hay crashes abiertos | Se confunde severidad con prioridad. Triar por prioridad de negocio, no por lo fácil. |
| Cada arreglo rompe algo distinto | No hay suite de regresión. Define casos fijos que se ejecuten en cada build. |
| El plan de pruebas "pasa" pero el juego falla en manos de usuarios | Solo hay casos felices. Agrega casos límite, negativos y exploratorios. |
| El tracker está lleno de bugs "Nuevo" desde hace meses | No hay triaje periódico. Agenda una sesión de triaje recurrente. |
❓ ¿El testing automatizado reemplaza al QA manual? No. Automatiza lo repetible y verificable; el juicio humano sobre diversión, feel y casos imprevistos es insustituible.
❓ ¿Severidad y prioridad no son lo mismo? No. Severidad mide el daño técnico; prioridad mide la urgencia de arreglarlo. Un crash raro puede ser severo pero de baja prioridad.
❓ ¿Cuántos casos debe tener un plan de pruebas? Los suficientes para cubrir camino feliz, límites, negativos y regresión de esa funcionalidad; la cantidad la fija el riesgo, no un número mágico.
❓ ¿Qué hago con bugs intermitentes? Regístralos igual, anota la frecuencia (X de Y intentos) y toda variable de entorno; el patrón de reproducción suele emerger de esos datos.
Clase 273 - Presupuesto, contratos y aspectos legales