Encabezado:
| Título del juego y versión | Plataforma más versión | Tipo de error | Area del juego | Breve descripción |
Cuerpo del bug:
| Steps to reproduce |
| Prioridad |
| Reprorate |
| Actual result |
| Expected result |
| Archivos adjuntos |
Introducción
Qué aprenderás sobre el testing de videojuegos
¿Cómo funciona el testing de Black Box en un estudio de videojuegos?
Diferencia entre los 2 QA’s
Testing de Regresión y Testing Exploratorio
Primer quiz
Tipos de Testing
Tipos de Testing: Funcional, Lingüístico y de Localización
Tipos de Testing: Online, Compliance, Usabilidad y Play Test
Ejemplos de casos de pruebas de baterías de testing
Segundo quiz
Reporte de bugs y Tipos de bugs
Qué es un bug y la importancia del reporte de errores
Bug Writing Format
Prioridades de los bugs y prioridad según su ruta
Tipos de bugs: texto, gráfico, funcional, gameplay
Tipos de bugs: Crash, Freezee, Framerate, Audio, Legal
Reto: reporta los bugs
Áreas de un juego y bugs duplicados
RETO: encuentra 10 Bugs en un juego
Test plan
Sistema de Trabajo
Test plan
Organizando nuestro test plan
Continuando el proceso de creación de test Plan y tu primera batería de pruebas
Baterías de pruebas especiales
RETO: 3 cosas que consideras prioritarias antes de empezar a testear
Testing en celulares
Guía Android
Testing en celulares Android
Guía iOS
Testing en consolas
Reto: Test Plan
uTest
uTest: creando tu perfil
uTest: proyectos pagados, reportes de bugs y pagos
Cierre del curso
Charla motivacional
Reto final
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Bug Writing Format
11/33Recursos
Cuando vamos a reportar un error no podemos reportarlo de cualquier manera, esto sería caótico. En esta clase aprenderemos la manera correcta de hacer estos reportes.
Cada empresa tiene su propio formato para reportar bugs. Toma esta clase como una guía pero ten siempre presente que cada estudio o equipo de desarrollo tendrá su propio formato y debemos ser capaces de adaptarnos a ellos. El lenguaje en el que suelen hacerte estos reportes es inglés.
Un bug se compone de dos partes: el encabezado y el cuerpo del bug. El encabezado contiene información como el título del juego y su versión, la plataforma y su versión, el tipo de bug, el área del juego donde se encuentra y una breve descripción del mismo, de alrededor de 5 palabras.
En el cuerpo ampliaremos esta descripción que hemos dado brevemente en el encabezado; también contiene unos steps to reproduce, es decir el paso a paso para encontrarnos con este error; el nivel de prioridad del bug; un repro rate, que se refiere a la frecuencia con la que se observa el error; el actual result, es decir, lo que estamos observando que sucede como consecuencia del bug; expected result es lo que debería hacer el juego si no existiera el bug: y unos archivos adjuntos para soportar este reporte.
Aportes 26
Preguntas 7
Ordenar por:
CS:GO 1.37.3.5/ Ordenador/ Funcional/ Transparencia de texturas
Prioridad: Alta
Reprorate: 10/10
Steps to reproduce: Equipar un Player Model verde, ir al mapa overpass, especificamente en las rejas de monster, agacharse pegado a las rejas.
Actual Result: Algunas texturas del modelo se vuelven transparentes y el jugador se vuelve invisible.
Expected Result: Las texturas deberian ser visibles en cualquier parte del mapa.
Archivos Adjuntos
COMO SE REPORTA UN ERROR?
Debemos separar el bug en 2 partes : encabezado y el cuerpo.
**Encabezado: **
Titulo del juego.- (Se explica por si mismo)
Plataforma y su versión.- Ejemplo: PSP Vita 2.1
Tipo de bug.- Describimos la naturaleza del error. Ejemplo: Error de traducción.
Área del juego.- En que parte lógica o geográfica del juego se ubica el error. Ejemplo: Sala de espera del multijugador
Breve descripción. Describes en 5 palabras o menos de que trata el bug. Ejemplo: Animación incorrecta
Cuerpo del bug:
Pasos para reproducirlo.- Aquí debes describir la condiciones exactas con las que te topaste el error.
Prioridad.- Dependerá de cada estudio los criterios con los que se evalúa la criticidad de un bug. Ejemplo: critico, bloqueador, casi nunca pasa, etc.
Reproducibilidad.- Que tantas veces he logrado reproducir un bug en función al numero de intentos. Ejemplo: 5/10
Resultado actual: Descripción precisa y directa del error que ocurre ahora mismo con la presencia del bug.
Resultado esperado: Lo que se suponía que debía pasar sin no existiera el el bug.
Archivos adjuntos: Documentación que usaremos para apoyar la comprensión del bug: Ejemplos: Imágenes o vídeos donde se aprecie el bug.
Cada estudio tiene su propio BWF, aunque me imagino que deben estar más que estandarizados de acuerdo al formato que paso Ricardo.
En el caso del repro. rate ¿cada empresa tiende a poner el número de intentos? ¿o cómo funciona?
El resultado esperado no deberia de antemano conocer el programador? Saludos
En lo personal lo que yo hago es un archivo en excel donde en el encabezado esta:
- Un id de prueba
- Nombre del tester
- Versión del juego
- Resultado final
- Nombre de la prueba
- Datos de hardware o software extra para la realización de la prueba
Después se muestran los casos de prueba con una descripción del caso, el resultado esperado, el resultado final y si la prueba pasa, falla, no se ejecuta o está suspendida. Cada hoja en el archivo excel corresponde a una prueba específica.
Posteriormente en un informe se escribe todo acerca de errores (bugs) encontrados y son contados con el mayor detalle posible. También en el informe se ponen ideas o sugerencias para mejorar el juego o arreglar bugs.
++Excelente clase ++
ENCABEZADO:
Juego + versión / Plataforma + versión / Tipo de bug Área del juego / Descripción breve
CUERPO:
-Descripción más detallada
-Steps to reproduce (pasos a seguir para reproducir el error paso a paso)
-Prioridad (minor-mayor-critical-blocker)
-Repro rate (cantidad de veces que se puede reproducir el bug en relación al número de intentos)
-Actual result : bug en si (lo que sucede que no debería suceder)
-Expected result (resultado esperado
-Archivos adjuntos (evidencia del error)
Buen día! Me surgió la duda si al reportar se lleva algún tipo de numeración, control o estatus, es decir resuelto, pendiente, en progreso. para tener un control de lo que se a hecho. y si es así cual seria la forma mas ideal para colocarlo en el Bug Writing Format
¿Un Glitch puede ser considerado un Bug Low?
Hay alguna relacion entre Repro Rate y Tipo de prioridad aunque esta no altere la fluidiez del juego? es decir, si una accion tiene 9/10 pero es algo irrelevante, ejemplo descartar un objeto, esto se deberia reportar como prioridad alta? o eso no altera nuestro reporte?
Voy a poner un caso que me pasó:
Cup Head/PC/Gameplay/primer boss/muerte sin continuación
descripción: cuando el jugador muere por la tercera fase del primer boss nunca sale la pantalla de reinicio, el enemigo se sigue moviendo y toca salirse del juego para continuar normal.
Steps to reproduce: ir al primer boss/ llegar a la tercera fase del boss/morir bajo cualquier condición
Prioridad:Critical
Reprorate: 2/10
Actual Result: el jugador muere y no aparece el menú de reiniciar lo que hace que toque salir del juego y reiniciar todo el progreso.
Expected Result: morir y que aparezca el menú de reinicio del nivel.
archivos:
este ha sido una gran clase ❤️
I portante especificar que la prioridad esta enfocado en el nivel de urgencia en que debe ser solucionado el Bug, aqui se confunde un poco con la severidad que es el nivel de impacto en el sistema o negocio el bug. La severidad si la selecciona y asigna el tester mientras que la prioridad la define mas que todo el cliente en un bug triage session generalmente.
En esta clase se podria alinear un poco mas la estructura de un defecto con la del estandar de la IEEE de calidad que tiene ISTQB, podria dar mas valor una estructura agil y alienada con estos estandares.
Explicas muy bien!!
muy buena clase
Muy bien explicado
Que muy claro al ver el Formato real…
Excelente clase.
Usare un ejemplo que me a pasado aunque imagino que es mas por la plataforma que el juego en si
Terraria 1.4.4.6/ PC (Notebook Asus X541S)/ Grafico/Cualquier mundo/Error grafico al moverse
Prioridad: Media/baja
Repro Rate: 10/10
Descripción: Se generar un error grafico al mover en el juego si esta la configuración de video en omitir frame
steps to reproduce:
1 Iniciar el juego
2 Seleccionar personaje
3 Seleccionar mundo
4 Ir a la configuraciones
5 Configurar en omitir frame en el apartado de video
6 Moverse en el juego
Actual result: Se generar error Grafico/iluminación al moverse en el juego
Expected result: No debe haber fallas graficas al moverse en el juego
Archivos Adjuntos:
Ejemplo de reporte de un bug
* **ID del bug:** CP001
* **Título del juego y versión:** "Ejemplo Game: Versión 1.0"
* **Plataforma más versión:** PC (Windows 10)
* **Tipo de error:** Error gráfico
* **Área del juego:** Nivel 3 - Bosque Encantado
* **Breve descripción:** Los árboles en el Bosque Encantado tienen texturas parpadeantes y distorsionadas.
* **Cuerpo del bug:**
* **Steps to reproduce:**
1. Inicia el juego.
2. Carga el Nivel 3 - Bosque Encantado.
3. Observa los árboles en la pantalla.
* **Prioridad:** Alta
* **Reproducibilidad:** Siempre
* **Resultado actual:** Las texturas de los árboles parpadean y se ven distorsionadas.
* **Resultado esperado:** Las texturas de los árboles deben renderizarse correctamente sin parpadeos ni distorsiones.
* **Archivos adjuntos:** (Puedes adjuntar capturas de pantalla u otros archivos relevantes que ayuden a comprender el problema)
1. **ID del bug:** Un identificador único asignado al error para su seguimiento y referencia. Este número ayuda a organizar y priorizar la resolución de errores.
2. **Título del juego y versión:** El nombre del videojuego afectado por el error, seguido de la versión específica del juego en la que se encontró el error. La versión es importante porque un error puede variar entre diferentes versiones del juego.
3. **Plataforma más versión:** La plataforma en la que se experimenta el error, como PC, Xbox, PlayStation, o cualquier otra plataforma, junto con la versión específica de esa plataforma (por ejemplo, "PC - Windows 10").
4. **Tipo de error:** La categorización del tipo de error encontrado, como errores gráficos, errores de jugabilidad, problemas de sonido, problemas de red, etc. Esto ayuda a los equipos de desarrollo a dirigir el error al equipo adecuado.
5. **Área del juego:** La ubicación o sección específica del juego donde se encuentra el error. Esto es útil para los desarrolladores que deben localizar y solucionar el problema en un área particular del juego.
6. **Breve descripción:** Una descripción concisa del error, proporcionando una idea general de lo que está ocurriendo incorrectamente. Esto ayuda a los equipos a comprender el problema de manera rápida.
7. **Cuerpo del bug:**
* **Steps to reproduce:** Detalles paso a paso de cómo se puede replicar el error. Esto permite a los desarrolladores reproducir el problema y comprender mejor sus causas.
* **Prioridad:** La importancia del error, generalmente categorizado como baja, media o alta, lo que ayuda a establecer cuán urgente es resolverlo.
* **Reproducibilidad:** Si el error se reproduce siempre, a veces o solo en situaciones específicas. Esto ayuda a los desarrolladores a determinar cuán constante es el problema.
* **Resultado actual:** Una descripción detallada de lo que sucede cuando se encuentra el error.
* **Resultado esperado:** La descripción de lo que debería ocurrir si el juego funcionara correctamente.
* **Archivos adjuntos:** Posibilidad de adjuntar archivos como capturas de pantalla, videos, registros o cualquier recurso que ayude a entender y resolver el error.
Cool!! justo esto necesitaba !
Genial
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?