Transcripciones
1. INTRODUCCIÓN: Él lló a todos, y
bienvenido al curso convirtiéndose en una Q Elite
habilidades y estrategias. Este curso está diseñado
para ayudarte a obtener una comprensión sólida de
lo que significa ser una élite Q. Usé toda mi experiencia
previa para poner otros puntos principales
en este curso. Hagamos una runo rápida a través los principales puntos clave
para los aspirantes a Q Elite. En primer lugar,
es necesario desarrollar habilidades
técnicas para mantenerse competente en las herramientas de prueba y metodologías para garantizar la calidad Luego, mejoras las habilidades de
liderazgo, cultivas habilidades blandas para administrar
e inspirar a los equipos de
manera efectiva Entonces, por supuesto, necesitas
fomentar la colaboración, construir
relaciones sólidas entre departamentos para obtener mejores resultados. Y, por supuesto, hay que
comprometerse con la
mejora continua, abrazando una mentalidad de aprendizaje y
adaptación para En este curso,
vamos a cubrir el crecimiento y
desarrollo
profesional como Q elite, dónde empezar y qué
hacer para llegar a este puesto. Cubrimos cosas
como la tutoría, la creación de redes y el aprendizaje
continuo Otro tema importante del curso es
la preparación de
proyectos, lo cual es muy importante
para cada Q Elite. Comenzaremos con la comprensión de los requisitos y
especificaciones
del juego , la
creación de la estructura de VBS, se
cubrirán las técnicas de
estimación, planificación y la gestión de la
línea de tiempo, y también la creación de
planes y estrategias de prueba Después pasaremos a la preparación de
documentación. Necesitamos tener una comprensión
completa de las necesidades
de
documentación del proyecto, crear plantillas de casos de prueba, diseñar listas de verificación, definir
la gravedad y la prioridad, y también establecer algunos estándares de
informes. Una gran parte de cada
trabajo de QL es Jira y su configuración. Trabajaremos en la plantilla de
reporte de errores, en los filtros y
en los dashboards Estos son los principales elementos
de una gestión eficiente. Y, por supuesto,
cubriremos las principales actividades de los
clientes potenciales de
prueba durante el proceso de prueba, como pasar hitos, entornos de
prueba, proceso de
bacterias, priorización y actividades de
prueba Y claro, necesitamos
cubrir la gestión de riesgos. Necesitamos aprender a identificar los riesgos
del proyecto, analizar los riesgos
del producto, desarrollar estrategias de mitigación, monitoreo
continuo de riesgos y comunicación con las partes interesadas. Y por supuesto, en este curso, estamos abordando los obstáculos
comunes que
enfrentan los QALT en entornos
dinámicos, como las limitaciones de recursos, los requisitos
cambiantes
y la dinámica del equipo Si todo lo que se dijo
anteriormente no es suficiente, aquí hay una lista adicional de cosas que veremos, como supervisar el proceso de
aseguramiento de la calidad, planes de pruebas de
desarrollo, planes de pruebas de
desarrollo, coordinar con
el equipo de desarrollo y garantizar el
cumplimiento de las normas Además, analizaremos
lo que se necesita para
convertirnos en una élite clave, como fuertes habilidades
analíticas,
excelentes habilidades de comunicación, capacidades de
liderazgo y atención a los detalles. Y además de eso,
discutiremos cómo adquirir experiencia en
liderazgo, mejorar las habilidades técnicas, comprender la gestión de
proyectos y construir la colaboración en equipo. Este curso es una mezcla de
teoría y práctica. En mi ejemplo,
estaré mostrando cómo tomar un proyecto y organizar todos
los procesos como líder de QA. Entonces, si estás listo para
elevar tu carrera en QA, este curso es para ti.
2. Responsabilidades del líder de QA: Bienvenidos a nuestra primera parte
del curso sobre
convertirnos en Q Elite. En este capítulo,
trataremos de entender
lo que significa ser un Q Elite
en el desarrollo de juegos. Esto es solo una breve descripción general. Se compartirán más detalles
a lo largo del curso. Nuestra agenda es
las siguientes responsabilidades de un Q Elite, habilidades y cualidades
requeridas y transición de un probador de
QA a un QED Hay cinco pilares principales: gestión
de
equipos de responsabilidades, planificación de
pruebas, aseguramiento de la
calidad, comunicación y seguimiento de
problemas. Como líder de QA, una de sus principales responsabilidades
es la gestión de equipos. Dirigirás y
asesorarás a los miembros de tu equipo de control de calidad, asignarás tareas, establecerás
metas y proporcionarás Crear un equipo cohesivo
y motivado es esencial para lograr
nuestros objetivos de calidad Pasemos a probar la planeación. Consta de tres partes principales, objetivos, alcances
y recursos. Para los objetivos, necesitas
entender qué es exactamente lo que se espera de ti y de tu equipo y qué es exactamente lo
que vas a probar. Para leer esto, necesitas
crear planes
y estrategias de prueba. En términos de alcance
como élite clave, es
necesario comprender completamente
el contenido del juego o el proyecto y todo el aspecto que
hay que probar. Para ello, es necesario definir objetivos,
alcances y prioridades de las
pruebas. El siguiente son los recursos. En función de la cantidad de
pruebas que se deben realizar, en
función de la complejidad del juego, es necesario
encontrar la cantidad
adecuada de recursos y asignarlos y programar
actividades de prueba para ellos. Pasando al siguiente. Proceso de aseguramiento de la calidad. En general, es necesario
asegurarse de que todos los
procesos y entregables cumplan con los
estándares y procedimientos de calidad definidos Entonces necesitas hacer revisiones de calidad de
dolor y Audis para identificar áreas para
mejoras y cumplimiento Una vez que se realizan las revisiones, debe implementar
todas las mejoras e iniciativas para elevar la calidad
general del producto. Pasemos a la parte
de comunicación. La comunicación es algo muy
crucial para una élite Q. En general, es
necesario asegurarse de que todos los interesados estén al tanto del estado de la
calidad del juego. Necesitas poder
colaborar con el equipo de QA, con desarrolladores, y con todas las personas que
estén interesadas en el éxito del proyecto. Y por último,
hablemos del rastreo de tejidos. En general, podemos
dividirlo en algunas partes. El primero es el seguimiento de errores. Este es un proceso de
gestión del sistema de seguimiento B y proceso de resolución. El siguiente es la
priorización de errores. En general,
es necesario priorizar los errores y luego asignarlos
a los miembros de la propiedad,
ya sea desarrollador, artista o
tal vez a otros grupos de interés El último es la resolución de errores. Como élite clave,
debe asegurarse de que el equipo de desarrollo esté al tanto
del error y los corrija, y luego Kateam logra verificarlo y
verificar la En general, Kit juega un
papel crucial en el desarrollo de juegos. Desde el inicio
del proyecto, usted es el
responsable de entregar el producto de la mejor calidad
a los usuarios finales. Es por eso que necesitas ser
bueno en la gestión de equipos, planificación de
pruebas, aseguramiento de la
calidad, comunicación y seguimiento de
problemas.
3. Habilidades de liderazgo de QA: A nuestro siguiente capítulo. Exploraremos las habilidades y cualidades requeridas para
ser una Kd efectiva. Profundicemos en los atributos
esenciales que contribuyen al
éxito en este rol He dividido las habilidades
básicas en cinco categorías principales, habilidades
técnicas, habilidades de
liderazgo, habilidades de
comunicación, problemas y habilidades
organizativas. Comprobemos uno por uno. Las habilidades técnicas son
fundamentales para una élite Q. Permiten un proceso de prueba eficiente y
efectivo. Vamos a bucear un poco más profundo. Debe ser competente en las herramientas de
prueba que su equipo utilizará a diario También en metodologías
que necesitas usar para pruebas y en tecnologías que serán utilizadas
para tu proyecto. Entonces necesita tener una
buena comprensión del ciclo de vida
del desarrollo de software y los procesos para pruebas
integrales. Necesitas saber la
forma en que
se crea el juego desde el
principio hasta el fondo, de principio a fin. Para los lenguajes de programación, no
es algo que
sea obligatorio o deba ayudar. Es algo que es bueno
saber y poder usar
para crear scripts
automatizados o simplemente para
poder hacer una depuración más profunda. Si bien eres un buen líder qui, necesitas inspirar, motivar y guiar a los miembros de tu equipo Entonces debes
asegurarte de tener una buena toma de decisiones, resolución de
conflictos, pensamiento y procesamiento, y también, necesitas ser un líder
visionario y necesitas impulsar
mejoras en el equipo Ya estábamos hablando de
que la comunicación es una de las responsabilidades
de una élite Q, pero también tenemos que mirarla como una habilidad que necesitas mejorar porque mejorar las habilidades de
comunicación conduce a un mejor
éxito del proyecto y cohesión del equipo. Las habilidades de
comunicación claras y sólidas son esenciales para que una élite Q
transmita los objetivos del proyecto, las expectativas y la
retroalimentación de manera efectiva, fomentando un entorno de
equipo colaborativo. En la vida real, siempre te
enfrentas a algunos problemas, y cuando eres celta, eres responsable de
la resolución de ellos. Para poder resolver
diferentes problemas, es
necesario tener una
aptitud para identificar, analizar y resolver problemas Entonces a veces necesitas ser creativo al
pensar en encontrar una solución, y luego necesitas
tener una adaptabilidad y resilencio al
navegar los desafíos Las habilidades organizacionales son
esenciales para una élite q. Ayudan a garantizarte una
gestión y entrega eficiente de proyectos. Comprobemos más en detalle. En primer lugar, es necesario
tener la capacidad de
administrar tareas, recursos
y cronogramas En palabras simples,
es necesario poder realizar
un seguimiento de las tareas y asignarlas
a diferentes miembros del equipo. Necesitas asegurarte de que
tienes suficientes recursos, y luego debes
asegurarte de que estás haciendo todo a tiempo. Entonces necesitas tener una
buena priorización de tareas para poder cubrir primero cosas
importantes, y luego debes poder delegar otras responsabilidades
a diferentes personas porque como ser humano, a veces no podrás cubrir todo por ti mismo Entonces es necesario
tener una atención a los detalles y el apego
a los estándares de calidad. Esta es una lista general de
habilidades y cualidades requeridas. A lo largo del curso,
profundizaremos en cada una de ellas y la cubriremos
con ejercicios prácticos.
4. Transición al rol: Ahora, exploremos
el viaje de la
transición de un
probador de QA a un QA Lite Este proceso implica
avanzar de un rol de prueba técnica
a una posición de liderazgo. En este pequeño capítulo,
haremos una pequeña descripción general de la
transición de un
probador de QA a un rol principal de QA, y también discutiremos los aspectos de desarrollo
profesional y avanzar a una posición de
liderazgo Hay algunas cosas
que pueden ayudarte en desarrollo de habilidades de
transición, tutoría y oportunidades En primer lugar, es necesario trabajar duro en el liderazgo, la
comunicación y las habilidades gerenciales
para pasar de
un rol de prueba técnica
a un puesto de liderazgo Además, es agradable
encontrar un mentor, alguien que ya tenga un rol, que pueda mostrarte todas las cosas y enseñarte todas las cosas, además de participar en los programas de
desarrollo de liderazgo. Básicamente
participo en una de ellas en mi empresa que me
capacitó para convertirme en protagonista. Intenta explorar cualquier
nuevo reto y posibles responsabilidades en la QVL para avanzar en tu carrera Por ejemplo, si hay una tarea que no
sabes hacer, trata de ser voluntario y hazla. Si la empresa está buscando a alguien que pueda hacerse cargo
de una nueva tarea, tal vez también sea tu
oportunidad de probarte a ti mismo. Hay tres
habilidades principales que difieren de cualquier otra habilidad técnica que sea crucial para la posición de liderazgo Q. En primer lugar, es un
liderazgo y gestión,
luego es la gestión de proyectos y el desarrollo de
habilidades organizacionales, y luego es una mejora de
las habilidades de comunicación e interpersonales Mientras trabaja como QA, es posible que obtenga muchas habilidades
técnicas que
sepa hacer, cómo dividir tareas,
priorización y otras cosas Pero esto es algo que
necesitas trabajar duro tu cuenta para obtener un rol de QED Hay una de las
formas de desarrollar todas tus habilidades necesarias es usar una tutoría y programas de
coaching El mentor te ayuda en todas las etapas desde
la preparación hasta transición durante el
proceso de transición y luego después. Si tienes un quid en tu organización y te gusta
y te gusta lo que hace, entonces trata de preguntarle si puede ser mentor y
mostrarte todo lo que sabe Por lo general, a las personas les gusta esta
si no están demasiado ocupadas, les gusta ser mentores a
otras personas y les gusta compartir sus
conocimientos con ellos. También, me gustaría
agregar algunas palabras
sobre las actividades y programas de desarrollo de liderazgo. Recomiendo encarecidamente
participar si tienes alguna disponible dentro de
tu empresa o fuera. Un día, un sabio
me dijo que la mejor manera de
crecer es asumiendo
tus responsabilidades
y estar a cargo de ello. Y fue uno de los mejores
consejos que tuve en mi vida. Entonces veamos qué hay aquí. Voluntariado para roles. ¿Hay alguna
posición abierta en el proyecto? Siempre trate de ser voluntario para ello. Si hay una tarea asignada
al grupo de personas, siempre trate de estar
activo y mostrar algunas formas diferentes de
resolverla y abordarla. Aunque no estés seguro de que tu iniciativa es correcta y estás proponiendo de
la manera correcta, tener más iniciativas es
mejor que no tener ninguna. No tengas miedo de
tomar posesión de ninguna tarea o iniciativa. Esta es una de las mejores
formas de demostrar tus habilidades de liderazgo
y también de crecer. El siguiente punto es construir
una red profesional. Para ser honesto, no le
presté mucha atención a esta a lo largo de toda
mi carrera, pero recientemente, comencé a encontrarla muy
útil y útil. En primer lugar, trabajar con otras personas y otros
profesionales y compañeros puede brindarle mucha experiencia
nueva y diferentes puntos de vista y
soluciones a sus problemas. Además, siempre hay muchas posibilidades
diferentes para
ti dentro de diferentes organizaciones
y comunidades
profesionales, además de asistir a
conferencias, talleres y seminarios te brindan mucha experiencia
y conocimientos nuevos. O eres un oyente o una persona que trae
algo de discurso porque uno de los mayores
estrés para la persona es actuar frente
a una gran audiencia Qualit es una persona que tiene una fuerte capacidad de
comunicación, habilidades interpersonales,
es capaz de asumir responsabilidades y no tiene miedo de hacer algunas iniciativas Y básicamente, no hay nada que no sea posible ganar. Y avanzando más,
voy a tratar de darle tantos detalles sobre todos
estos como sea posible.
5. Preparación de proyectos. Requisitos: Pasar a nuestro siguiente capítulo, que se llama preparación de
proyectos. Vamos a comenzar con comprensión de los requisitos
y especificaciones. ¿Cuáles son los requisitos del juego y básicamente los
requisitos en general? Hay
características específicas, funcionalidades y características que
el juego debe tener para cumplir con las expectativas del
jugador y los stakeholders. Aquí hay algunos ejemplos solo para entender
mejor lo que
puede ser un requisito? Es una lista de
mecánicas de juego, gráficos, audio,
funcionalidad multijugador y compatibilidad de plataformas. Si ya trabajas un SQ, probablemente ya
estés familiarizado con los requisitos y para
qué se necesitan. Pero echemos un vistazo
al panorama general. ¿Por qué necesitamos los requisitos? En primer lugar, asegurar la alineación con las expectativas
previas. Los requisitos guían el
proceso de desarrollo y las decisiones. Y además, tener requisitos de consulta y listados proporciona agarre de
alcance y retrasos en el proyecto. crip de alcance es un
fenómeno cuando
se hacen
demasiados cambios incontrolados en el proyecto, y no se ve
lo que se supone que debe ser Hay tres componentes principales
de las especificaciones del juego, especificaciones
técnicas, definen plataformas esperadas, requisitos de
hardware. Entonces
especificaciones funcionales es sobre el funcionamiento
del juego, características mecánicas de
juego
y especificaciones de diseño. Definen el estilo artístico, el diseño de niveles y otros. Por qué es tan importante
tener una buena comprensión
de los requisitos. En primer lugar, asegura cuarty y dirección
del proyecto. Como líder de QA, desde el
inicio del proyecto, tienes una buena visión y entendiendo cuál debería ser el
proyecto. Entonces los requisitos
ayudan a facilitar la comunicación
efectiva
entre los miembros del equipo. A menudo sucede que desarrollador y QA tienen diferente
opinión sobre cómo debería funcionar
la función
y tener requisitos queer y escritos puede
ayudarlos a resolver este misterio. Y la última es
que los requisitos ayudan
a identificar los
desafíos y riesgos potenciales de manera temprana. Por ejemplo, tienes
un juego multijugador y esperas tener 60 jugadores
concurrentes Necesitas planificar las actividades de
prueba en el camino en un momento, necesitas cubrir
esta sesión de juego. Por lo general, todos los requisitos se comparten con el equipo de
QA de antemano. Pero de un proyecto a otro, de una empresa a otra, veces los requisitos se crean durante las
discusiones con diferentes miembros de eam
con grupos de interés o en
base a alguna documentación
o producto MVP Estoy planeando crear
requisitos para un Parque Piu. He elegido Pio park porque
básicamente este juego cubre todos los requisitos necesarios que podemos usar a lo largo
del curso, pero puedes elegir cualquier
otro proyecto o juego que te guste y realizar las
tareas prácticas en paralelo.
6. Preparación de proyectos. Lista de requisitos: Echa un vistazo rápido al juego y ve qué
mecánicas principales tiene. Tenemos modo de juego local,
modo de juego en línea, opciones, juego de salida,
tenemos en opciones. Bien, esas son algunas
opciones estándar, Pat Config. ¿Bien? Modo jugador local, tenemos dos, tres,
cuatro, cinco, seis, siete, ocho jugadores para el modo de
juego online, tenemos público. Es para unirse al juego público, es unirse al juego de amigos, anfitriones para iniciar su propio juego, opción es establecer algunos ajustes. Bien, aquí podemos establecer
algunas opciones, elegir color,
elegir jugadores Max. A ver cojugador,
dos jugadores. Bien, jugador uno, jugador dos, y tenemos opciones de batalla
mundial, sin fin. Eso creo que algunos modos. En cada mundo,
tenemos diferentes niveles. Y cada uno tiene cuatro subniveles. Y básicamente, tenemos algunos acertijos que
necesitamos resolver. Bien, tenemos dos esposas y necesitamos encontrar
soluciones de cómo pasarlo. Bien. Está bastante
claro para el inicio. Así que vamos a crear algunos
requisitos para este juego. Como dije antes,
generalmente los requisitos son compartidos con el
QATM por la producción, pero a veces hay que crear los
requisitos por su cuenta Vamos a crear algunos requisitos
simples para un parque Pico, por ejemplo. Esto es sólo un
documento de Gus y comencemos. Vamos a crear tres secciones. El primero son
las especificaciones técnicas, luego funcionales. Especificaciones, y la última son las especificaciones
de diseño. Empecemos a llenar uno por uno para
especificaciones técnicas. Bien, vamos a hacerlo. Tenemos, en primer lugar, plataformas
soportadas. Para plataformas, tenemos Nintendo PC y móvil. Hardware. Requisitos. Para los requisitos de hardware,
vamos con cuatro gigabyte RAM 100
megabyte, espacio libre Vamos al mercado, luego moviéndonos a continuación. Usemos alguna
compatibilidad de plataforma para Nintendo, debería ser compatible
con los modelos de switch. Para móviles. Digamos IOS, compatible con IS 11 o agua y Android 5.0 o Agua. PC Windows diez y 11 marcas. Entonces la siguiente parte
son los dispositivos de entrada. Controladores, teclado y ratón y para móvil, pantalla táctil. Entonces esas son las especificaciones
técnicas básicas que nos gustaría
tener para nuestro juego. Vamos a marcarlo todo en diferentes colores para tener
una mejor visibilidad. Para
especificaciones funcionales,
comencemos con la mecánica del juego. Para la mecánica del juego,
como hemos visto en el juego, tenemos rompecabezas. En jugabilidad, luego poner elementos antiguos, luego aumentar la dificultad y luego la cooperación basada en equipos. También tenemos
funcionalidad multijugador. Para
la funcionalidad multijugador,
tenemos multijugador local que admite ocho jugadores y
tenemos multijugador online, total también admite
ocho jugadores. Después características. No vamos a enumerar
aquí todas las características. Lo estaremos haciendo
más detalladamente en el siguiente capítulo sobre la estructura de desglose del
trabajo. Aquí solo enumeraremos algunas características generales
sobre el juego. Algo así como dinámico. Bueno,
diseñe con elementos interactivos, luego acertijos que requieran trabajo en
equipo para resolver los desafiantes obstáculos y peligros y también modos de juego. Para los modos de juego, tenemos mundo, pero y por lo tanto Bien, marcando características, luego
para una mejor visibilidad. Y ahora pasemos a algunas
especificaciones de diseño. Estilo artístico. Hagámoslo un poco más
hermoso. Estilo artístico. Pixel, arte, gris. Fijar, luego brillante brillante y colorida estética
visual que diseñamos Aquí tenemos diversos diseños de
niveles. Entonces también esperamos que
el juego tenga variedad de equipos y entornos, y también esperamos
que sea intuitivo. Entonces también para el diseño, necesitamos diseño de sonido. Para ello, necesitamos señales de
audio claras para todos los elementos. Pero la música tierra. Y también necesitamos algo de
sonido para acciones previas. Efectos de sonido de directiva
para elementos de juego. Cambiando algunos colores. Aquí hay algunas
especificaciones básicas. Por lo general, son proporcionados
por el equipo de producción. A veces faltan, así que tienes que
crearlo por tu cuenta, y este es un requisito que tu juego debe
cumplir al final. Parecen estar bastante
despiertos al principio, pero luego pasaremos al siguiente capítulo, estructura de desglose del
trabajo,
y estaremos creando algunos
elementos más detallados a partir de esto para asegurarnos de que
somos capaces de probarlos.
7. Preparación de proyectos. Descripción de WBS: Pasemos a la siguiente
parte y hablemos sobre proceso de
estimación y
las técnicas en las pruebas de juegos. Y comenzaremos con VBS. En general, VBS es una composición jerárquica del alcance
del proyecto en componentes
más pequeños y manejables, llamados En nuestro caso, este es el alcance del juego
que necesitamos probar. VBS organiza y define el alcance
total del proyecto, dividiéndolo en piezas
más pequeñas y manejables que se
pueden entender fácilmente y asignar a equipos específicos o
individuos para su Echemos un vistazo a los componentes de
suma de VBS. En primer lugar, es jerarquía. Un VBS está estructurado
jerárquicamente para desglosar el alcance del proyecto
en componentes detallados Después entregables. Cada nivel del VBS representa resultados
tangibles que contribuyen
a la finalización del proyecto Cuentas de control, elementos de
nivel superior en el VBS que sirven como puntos
de control de gestión Entonces nos estamos moviendo
a paquetes de trabajo. Se trata de las
unidades de trabajo más pequeñas en el VBS asignadas a los miembros del
equipo con duración y resssness
definidos Estaremos viendo esto más detalle en
la parte práctica. Otro elemento de VBS
es la composición. La composición es el
proceso de desglosar el alcance del proyecto en componentes más
pequeños
y manejables Y ahora vamos a crear
VBS para el parque Pia. Profundicemos en
el contenido del juego. Entonces, ¿qué tenemos aquí? Para el modo mundo,
tenemos uno, dos, tres, cuatro, seis, 12 niveles diferentes. Cada uno de ellos cuenta con
cuatro subniveles. Bien, para el modo batalla.
¿Qué tenemos? Tenemos cuatro modos diferentes. Sí, terminar y para interminables, también
tenemos cuatro modos
diferentes.
8. Preparación de proyectos. Creación en WBS: Bien, comencemos a crear
nuestra estructura VBS. Vamos a crear una nueva página. Vamos a llamarlo VBS. Ahora comencemos. Tenemos juego de Pica Park. Entonces vamos a tener
algunas categorías diferentes. Esta será nuestra categoría. Para las pruebas de funcionalidad, vamos a
tener otra división. F f para pruebas multijugador. Modos de prueba y juego. Empecemos con las pruebas
multijugador. ¿Qué tenemos aquí? Tenemos multijugador vocal, y tenemos online. Multi jugador. Para el multijugador loco,
tenemos 28 jugadores, y debido a que es máquina
local y estás
jugando desde una PC, no
necesitas tener
ningún tipo de conexión. Pero para un multijugador, sí hay que
mencionarlo que también tenemos que
poner a prueba la habilidad para jugar con
dos a ocho jugadores. Entonces necesitamos probar la conexión. Los dioses lo hacen por ahora. Para la conexión, tenemos que
asegurarnos de que podemos alojar el juego. Podemos unirnos al juego, y podemos unirnos a Friends Game. Después interacción. Tenemos que asegurarnos de que
en el juego multijugador, seamos capaces de interactuar
con otras personas y no haya cera ni
arrancadores y otros problemas. Bien. Pasando al siguiente paquete. Vamos con la mecánica
general. En este caso, tenemos movimiento, pruebas, luego interacciones
con objetos. Así que vamos a enumerar algunos
principales de ellos, llave, luego cajas, y
puentes y otros Y ahora, pasemos a los modos. Frist modo, tenemos mundo. Consta de 12 niveles. Cada uno de ellos consta
de cuatro subniveles. Entonces tenemos y eso
tiene más cuatro niveles. Y entonces tenemos
batalla que también tiene batalla que también
tiene cuatro niveles. Bien, avancemos más a
continuación será UI. Para UI, tenemos menú principal, y también tenemos en
juego pruebas de UI. Y además, tenemos configuraciones y opciones
que necesitamos probar. Entonces tenemos audio. Para el audio, tenemos música y tenemos
diversos efectos de sonido. También llamamos a este afijo. Entonces el siguiente es visual. Para visual, solemos utilizar efectos
visuales por
afijo y gráficos Entonces tenemos rendimiento. Para el rendimiento,
podemos tener FPS, probando fotogramas por
segundo, ¿entonces qué? Probando el uso de la memoria, así
como la red. Espere y vea. Entonces la gran parte
es la compatibilidad. Tenemos
que asegurarnos de que podamos jugar desde diferentes plataformas juntos en el juego desde diferentes dispositivos, análisis debe ser probado. En primer lugar, es plataforma. Entonces es dispositivo,
luego son sistemas operativos. El siguiente es la vocalización. Para la vocalización,
necesitamos lenguaje,
apoyo, luego vocalización Pruebas de interfaz de usuario para
asegurarse de que después traducción o el texto se ajustan
al tamaño esperado. Y luego sensibilidad cultural. Y luego al final, voy a agregar algunas actividades de
prueba diferentes que se deben hacer, pero por lo general no
son parte del alcance. Como
pruebas de regresión, integración, pruebas así
como compatibilidad, pruebas de
regresión. primer conteo de control es la prueba de
funcionalidad, luego tenemos UI Luego tenemos audiovisuales, rendimiento, compatibilidad,
vocalización y actividades Hagamos que todos
tengan el mismo aspecto. Ahora, hagámoslo un poco
más bonito y asegurémonos que todos correspondan
a un solo paquete Entonces esta es toda la conexión. Voy a fusionarlo, poner conexión aquí, así ya
no necesito este. Entonces todo pertenece
a la conexión. Todo esto pertenece al
multijugador multijugador online. Voy a ponerlo aquí. Entonces ya no necesito
esta línea. Este pertenece al multijugador
local. Yo sólo puedo moverlo aquí, hacerlo esta línea, botón equivocado. Y todo esto pertenece a las pruebas
multijugador. Entonces no necesito esta línea. Necesito
fusionarlo y renombrarlo. Hagamos una pequeña alineación. Ahora pruebas multijugador que consiste en multijugador local que tiene un elemento y un multijugador que
tiene tres elementos, y este tiene tres elementos. Ahora vamos a verme un
poco mejor. Ahora hagamos lo mismo con
el resto. Lo tenemos aquí. Esta es la mecánica general. H. Bien. Bueno. Entonces Buto
tiene cuatro niveles Y esto tiene cuatro niveles. No necesito a estos
dos. El litro. Ahora todo esto pertenece
al grupo mundial. Y ahora esos son todos nuestros modos ay. No. Así que hicimos este modo de descomposición de las
principales características del juego. Esto es lo que suelo hacer antes de comenzar cualquiera
de los proyectos para entender qué características y cosas necesitaría
probar en el futuro.
9. Preparación de proyectos. Técnicas de estimación: Entonces hemos terminado con VBS, y ahora pasemos al proceso
de estimación En general, la estimación
es un proceso de predecir o pronosticar
la cantidad de esfuerzo, tiempo y recursos necesarios para completar un proyecto de prueba estimación precisa
es la clave para planificación
del proyecto y la
asignación de recursos y las pruebas de juegos. Asegura que el proyecto
será probado y entregado a tiempo, así
como nos ayuda a construir
un cronograma y cronograma. Existen algunos factores
que afectan la estimación. En primer lugar, es la complejidad
del juego y sus características. Entonces el tamaño del juego. Eso es bastante autoexplicativo. Cuanto más grande sea el juego, más
tiempo necesitas para probarlo. Por ejemplo, el tiempo necesario para probar el juego
Tetris y el asesino
ScritGame Entonces otro factor importante son los recursos
disponibles y la
experiencia dentro del equipo. Cuando no hay
personas mayores en tu equipo, el tiempo de prueba será mayor. Si hay un plazo estricto
para entregar tu proyecto, existe la posibilidad de que
necesites destinar más personas, más recursos, y algunos de ellos serán nuevos y necesitas incluir el tiempo necesario para
que acomoden
en la estimación. Existen algunas técnicas
para
una estimación efectiva. Juicio experto cuando el
probador experimentado proporciona entrada
basada en su conocimiento y
experiencia, estimación análoga, comparando el proyecto
actual con un proyecto pasado similar, modelado
paramétrico, usando modelos matemáticos para
calcular estimaciones basadas en parámetros
específicos y estimación de punto
libre cuando se está usando optimista,
pesimista y lo pesimista escenarios para estimaciones más
precisas. Comprobemos uno por uno.
Técnica de juicio pericial. Esta técnica se basa
en gran medida en probadores experimentados. La estimación se
basa principalmente en la
experiencia previa que podrían usar en proyectos
anteriores o cuando intentan
realizar tareas similares. La siguiente técnica es la estimación
análoga. Entonces, en general, solo estamos comparando proyectos
que necesitas estimar con cualquier
proyecto similar del pasado. A veces comparas
todo el proyecto, a veces solo tomas algunas
características de él y ves cuánto le costó al proyecto anterior terminar las pruebas. Avanzando, modelado paramétrico. Esta
técnica de estimación implica el uso modelos
matemáticos para calcular estimaciones basadas en parámetros
específicos. Entonces, básicamente, tienes una lista
de características y te tomas un promedio
de tiempo necesario para cubrir una característica y
luego simplemente multiplicarla. Y la última es la técnica de estimación de tres
puntos. Esta técnica
implica pasar por todas las características y proporcionar el
mejor escenario de los
casos, el peor de los casos y el escenario
más probable. Y luego la fórmula
te proporciona la estimación final. Vamos a crear una estimación para un parque Pico basado en VBS
que creamos anteriormente
10. Preparación de proyectos. Creación de estimaciones: Usa el mismo documento y
solo modifícalo un poco. Agreguemos una línea adicional. Estaremos utilizando la técnica de estimación de tres
puntos. Entonces para esto, necesitamos horas
medias de tiempo. Max, horas de tiempo. Lo más probable, horas. Y luego final. Para final,
estaremos usando fórmula. Y ahora comienza la estimación. Bien, para el multijugador local, tenemos de dos a ocho jugadores. Entonces, en general, lo que
tenemos que comprobar es la capacidad de
unirnos al juego con diferente cantidad
de personas y que
seamos capaces de ir
más allá de todos los niveles. Pasar todos los niveles
estará cubierto principalmente por pruebas de modos de
juego. Entonces, para el multijugador local, solo
necesitamos asegurarnos de que
podemos comenzar el juego con diferente cantidad de
jugadores en el mismo PC. Entonces por mínimo, iría
con 4 horas por máximo, iré con 12 horas y lo más
probable es que sean 8 horas. Después multijugador en línea. Conectarse en el modo multijugador en línea puede llevar un poco
más de tiempo porque necesitamos
asegurarnos de conectarlo desde diferentes dispositivos, desde
diferentes cuentas. Para este,
iré con ocho, 16 y muy probablemente 12 horas. Luego conexión.
Para albergar el juego, necesito una persona para crear el juego y otras
personas para intentar unirse. Esta es una tarea bastante
simple de 1 hora, 2 horas, muy probablemente 2 horas. Oh, juego conjunto. Aquí
tengo un error. Hagámoslo un poco más grande. Tal vez sea mejor
para la visibilidad. Juego conjunto, si quiero probar diferentes articulaciones de
diferente tipo de join, entonces iría con el
mismo uno, dos, dos. Y el juego de amigos es
bastante igual. La mayoría de las interacciones de nivel, nuevamente, se cubrirán
en los modos de juego, pero aún necesitamos probar algunas interacciones como colisiones entre
diferentes jugadores Además, hay un
mensaje de texto que puedes enviar, así que iría con 2 horas, 4 horas, y
lo más probable es que sean 4 horas. Bien, ahora tenemos números. Consigamos algún
número total para estas áreas. Fórmula tan simple. Y esparcirlo a través. Para el número final, con base en
la estimación de tres puntos, existe una fórmula especial, que es el mejor de los casos más cuatro
multiplicado por el peor
de los casos, más el más probable y todos estos divididos por seis. Lo estamos aplicando
a todo. Vamos a formatear los datos. Número que no necesitamos. Solo necesitamos un número por ahora. Bien, vamos a cubrir para
las pruebas funcionales, entonces serán 17. Y vamos a difundirlo
aquí y también aquí. Bien, procediendo con las
siguientes pruebas de movimiento. Esta es una tarea bastante sencilla. Vamos con una, dos,
dos interacción
con el objeto, una clave. También, tarea sencilla 111, cajas 111, puentes 111, y otras iguales Ahora estamos llegando a los modos de juego. Esta es la parte más compleja
de las pruebas de funcionalidad. Porque antes que
nada, tenemos que
pasar por todos los niveles. Tenemos que verificar todos los objetos
interactuables ahí. Tenemos que asegurarnos de que podamos terminar el nivel,
fallar el nivel,
y también los rompecabezas se ven bien, diseño de
nivel de arte de nivel se ve bien. De hecho podríamos incluso
hacerlo más detallado en nuestro VBS y
probablemente hagámoslo. Esta es una práctica normal cuando crees que
terminaste una tarea y luego tienes otras ideas que pueden ayudarte a
estimar el proyecto, para que puedas arreglar algo más tarde. Entonces para cada una de ellas, vamos a crear algunas áreas
adicionales. Entonces, vamos a una fila adicional. En realidad, necesitamos
un poco más de filas. Llego al subnivel. Tenemos que probar pasar fallar. Tenemos que probar el nivel. Vamos a llamarlo diseño de niveles. Necesitamos probar interacciones, y tenemos que probar
acertijos porque cada nivel es único y
tiene alguna forma de completarlo. Ahora vamos a crear lo
mismo para cada nivel. Bien. Luego volviendo a la estimación, debido a que tenemos 12 niveles y cuatro subniveles, cualquier cosa que tengamos que hacer, necesitamos multiplicar
por 12 y cuatro. Entonces básicamente, para
verificar el pase fallar, necesitamos alrededor de 10
minutos por nivel, entonces necesitamos usar
una fórmula aquí. Tenemos que mantener todo
en el formato de horas, pero algunas de las cosas
tardan menos de hora, así que necesitamos
traducirlo en horas también. Entonces por ejemplo, pasar fallar, verificar, nos va a
llevar 10 minutos. Entonces la fórmula será 1/6. Tenemos que hacer esto
para cuatro subniveles. Lo multiplicamos por cuatro
y por 12 niveles. Entonces al final, tenemos 8 horas. Entonces solo usemos la fórmula y en el peor de los casos
necesitamos 20 minutos, y lo más probable es que
sean 15 minutos. Para el diseño web, podría tomar en el mejor de los casos,
media hora por cada, peor de los casos, 1 hora por nivel. Hagamos lo mismo. Simplemente copiemos nuestras fórmulas. Y luego solo cambia el número. Media hora es de tres por seis
y 1 hora es de seis por seis. Mejor caso iré con
1 hora en el mejor de los casos también. Creo que las interacciones
tomarán la misma cantidad de tiempo que una prueba AOD y
lo mismo para la lógica de rompecabezas Salió la fórmula. Bien, sin fin, tenemos cuatro
niveles para el modo sin fin, es
decir, que todas las estimaciones deben multiplicarse por cuatro. Entonces para pasar fallar,
iría con 1 hora, luego después de multiplicar cuatro,
ocho, y en el mejor de los casos,
seis, LAODO hora por nivel
multiplicado por cuatro es cuatro,
ocho, y creo que
ocho es Interacciones, 2 horas
por interacción, luego ocho o caso 16, 12. La lógica de rompecabezas para
el modo sin fin es más simple. Iré con dos, cuatro, cuatro, y nos quedamos con botella
y en mi suposición, la estimación será exactamente la misma que para el modo sin fin. Y ahora tenemos el número final para pruebas de funcionalidad. Entonces procedamos
para la siguiente interfaz de usuario. Menú principal UI, 2
horas de pruebas, el
mejor de los casos, para el peor de los casos. Bien, vamos con ocho
porque tal vez haya
más de seis en las pruebas de la
interfaz de usuario del juego, dos, seis, Cuatro, el ajuste es opción y
las opciones es una tarea bastante grande. Es necesario verificar cada configuración, cada opción y ver cómo
afecta al juego. Iré con 24 48 y el
mejor de los casos probablemente 32. Vamos a
alargar la fórmula. Avanzando. Música, no hay
mucha música. Entonces iría con cuatro, ocho, seis, y aufix
hay aún menos Hay un afijo para
algunas cosas básicas, y la mayoría de ellas se cubrirán durante las pruebas de los modos de juego Así que solo tenemos que
asegurarnos de que
haya sufijo único
por cada acción única Dos, cuatro, cuatro efectos visuales. Igual que un sufijo,
dos, cuatro, cuatro. Y las pruebas gráficas, esta es
bastante grande porque
tenemos la capacidad de
jugar el juego en PC en diferentes
resoluciones en el móvil. Entonces gráfico es
algo que
requeriría al menos dos
días de pruebas. Entonces son 16, 24, y el mejor de los casos es 20. Prueba de FPS. Esto va a
estar sucediendo de forma natural. que hacer algunas pruebas especiales de
rendimiento a veces y planificar
estas actividades, así que yo iría con 16, 24, 20 pruebas deberían ocurrir
algunas veces, así que es 244. El uso es el mismo. Y Qutenc de red
también sucede de forma natural mientras se
prueban otras cosas, pero a veces necesitas establecer algunas actividades y usar
algunas herramientas para verificarlo Entonces iría con
algún número grande porque este también es un juego
multijugador, y el quotenc de la red
es algo importante Entonces yo iría con 12, 24, y tal vez 16 aquí. Pruebas de compatibilidad. Tenemos muchas plataformas
diferentes. Serán 16, 24, 20, tenemos muchos dispositivos. 24, tal vez 48 en sistemas
operativos, no
tenemos
tantos, entonces son 412, ocho. La forma no funciona. Bien. Ahora se ve mejor.
Soporte de idioma para 86. La interfaz de usuario de vocalización requiere
muchas pruebas en diferentes dispositivos Estará sucediendo naturalmente también probando otros modos, pero aún así hay que prestar
mucha atención a esto. Así que vamos con las 24 horas 48, y el mejor caso será de 32. La sensibilidad cultural no
es una tarea grande. Y nos quedamos con actividades. Las actividades suelen
ocurrir de vez en cuando. Por ejemplo, pruebas de regresión, necesitas hacerlo después de
algunos cambios en el sistema, pruebas de
integración después de que se
hicieron
algunas características nuevas y pruebas de
regresión de compatibilidad también, debes hacerlo después de que se corrigieron
algunos errores. Entonces planificaremos solo una
gran cantidad de tiempo ahí, y luego los repartiremos
por igual entre los diferentes hitos Entonces, por ejemplo,
las pruebas de regresión son de 48 horas hasta 60. Entonces digamos 56 pruebas de
integración, 24, 40 36 y compatibilidad,
24, 40 36. Bien. Ahora, agreguemos
algunas fórmulas aquí. Probablemente lo voy a omitir, así que se ve más rápido
para que no esperes. Entonces tenemos todos los números. Ahora, consigamos nuestro número final
total. Tenemos que obtenerlo
de la columna. Necesitamos todo este número
y tenemos que dividirlo por dos porque lo
escribimos dos veces. Y aquí está nuestra estimación
para el proyecto. En horas. Si queremos
dividirlo en días, entonces tenemos que tomarlo y
dividirlo por 8 horas diarias. Y por semanas, necesitamos
tomar este número y dividirlo a 40
horas porque suele ser 40 horas
semanales de tiempo de trabajo. Número de formulario Así
que estos son nuestros números finales. Para cubrir completamente todo el
proyecto, escoja un parque, necesitamos 80
días hábiles o 16 semanas. Solo quiero mencionar que
esta es una estimación bastante rápida. Si eres una élite Q, generalmente
necesitas ser más preciso y
profundizar en los requisitos y en el juego y el
contenido y las expectativas en el diseño para proporcionar números
más precisos. Estos números se
basan en solo un vistazo rápido, por lo que puede que
no sean tan precisos, pero solo
estoy tratando de brindarle una pequeña visión general del
proceso en general.
11. Preparación de proyectos. Planificación: Después de que creamos la estimación, hablemos un poco de planeación. La planificación es un
aspecto crucial de las pruebas de juegos y ayuda a los equipos a
organizar sus esfuerzos, asignar recursos de
manera efectiva y gestionar los riesgos. La planificación efectiva garantiza que las actividades de
prueba
estén bien coordinadas, se cumplan
los plazos y se informe a
las partes interesadas
del progreso del proyecto. Al invertir tiempo en la planificación, los equipos pueden minimizar
las incertidumbres y maximizar las posibilidades
de éxito del proyecto En este capítulo,
comprobemos los beneficios de
la planeación eficiente. Hay varios pasos clave
que están presentes en la planeación. En primer lugar, se definen los
objetivos y alcance de las pruebas. Lo hicimos creando
requisitos y
creando la estructura VBS El siguiente paso es identificar
recursos y limitaciones, luego crear
cronogramas y cronogramas detallados El cuarto paso es establecer canales de
comunicación, y el paso cinco es definir
el crecimiento y las responsabilidades. Crear un
programa de pruebas implica traducir el esfuerzo
estimado de prueba en una línea de tiempo detallada que describe cuándo se realizará cada
actividad de prueba Al crear una línea de tiempo, debe tener en
cuenta algunos factores. En primer lugar, es la disponibilidad
de recursos. Dependiendo de
empresa en empresa, de proyecto en
proyecto,
siempre hay diferente
composición del equipo. El equipo, nos referimos a
cuántos probadores junior tienes, probadores medios,
senior ¿Hay una persona
disponible o más? ¿Es la empresa la que te
da una cantidad de recursos o depende de
ti encontrar los recursos? Entonces esto es algo que
debes tener en
cuenta al crear una línea de tiempo. El segundo es la estimación
que se refiere a la
cantidad de tiempo que necesitas para probar el juego hasta su finalización, luego las dependencias entre tareas Esto es algo obvio, pero a veces hay que
entender que
algunas tareas no
se pueden hacer a menos que
se complete otra tarea y viceversa. El último son las restricciones
del proyecto. Por ejemplo, si se trata de
un proyecto multijugador, no
es posible que
una persona lo cubra. Pasemos a una creación de cronograma de pruebas y cronograma
para el proyecto Pico Park.
12. Preparación de proyectos. Asignación de recursos: Comience a crear un planificador de
recursos, necesitamos tener una
información
del equipo de desarrollo sobre las limitaciones
del proyecto. Por ejemplo, plazos y
fechas de entregas principales. Por lo general, se comparte
con el equipo de QA de
antemano para que puedan
crear una planificación adecuada. Imaginemos que este
es un plan compartido con nosotros por el equipo de desarrollo para Pico Park. ¿Qué tenemos aquí? Tenemos abril, mayo, junio, tres meses
de desarrollo. Y las fechas principales son pre
Alpha, 19 de abril, Alpha, 10 de
mayo, Beta, 14 de junio y Goden 28 de junio Entonces vamos a estar trabajando
alrededor de estas fechas. Primero, vamos a crear
un planificador de recursos. Vamos a crear
peine adicional a la izquierda. Estaremos usando este peine
para diferentes denominaciones. Bien. Recurso
uno, recurso dos. Vamos a moverlo un poco,
así se ve mejor. Para crear la asignación de recursos, necesitamos echar un vistazo a nuestra cantidad
esperada de horas. Tenemos 640. Entonces pongámoslo en alguna parte Bien. Ahora, vamos a crear
alguna asignación. Y crear algunos mostradores
para nuestra comodidad. Estaremos usando la fórmula. La fórmula será aquí
colocamos a una persona, luego suma 8 horas
porque esta es cantidad
habitual de horas gastadas
por un día por una persona. Si ninguno, entonces cero. Bien. Hagámoslo
por toda la duración. Y también a suma total. Forma habitual.
Comprobemos si funciona. Uno aquí, uno aquí, uno aquí. Sí, parece que está funcionando. Asignemos recursos
a diferentes líneas de tiempo. Para pre Alpha, me gustaría tener probablemente un tester al final solo para asegurarme de que el proyecto cumpla con los
criterios esperados para pre Alpha. Después a partir de Alpha, me gustaría tener un
recurso disponible todo el tiempo. Básicamente, me
gustaría prolongar un recurso a la duración
del proyecto y luego ver cuánto espacio
tenemos para el segundo recurso y si hay
necesidad de aún más recursos Entonces en total, tenemos 440 horas. Por lo que tenemos $200 adicionales para la segunda asignación de recursos. Me gustaría comenzar desde
el final porque es bueno
tener más gente cerca del
lanzamiento del proyecto. Entonces voy a ir aquí Esto me da 512 y
luego más hacia Beta. Bien, 40 horas, así que
tengo una semana más. En este caso, tenemos 640. Y con este planificador de recursos, podremos asignar recursos
adicionales tres
semanas antes de la entrega beta.
13. Preparación de proyectos. Creación de líneas de tiempo: Seguimos adelante y
copiamos nuestra estimación en
la hoja de la línea de tiempo, por lo que es más fácil
para nosotros crear una planificación. Solo quería
mencionar que normalmente lo creas cuando tienes
una sincronización con la producción, y ellos comparten su línea de tiempo de
producción contigo. Para que sepas cuándo la
función está lista para ser probada y cómo planificar mejor
tus actividades. Esta vez, no
tenemos equipo de producción, así que solo
intentaré usar las mejores prácticas
en la creación de cronogramas. No hay necesidad de crear una planeación
muy detallada. Por lo general, no todas
las cosas salen según lo planeado, y te adaptas en el proceso. Pero crear una línea de tiempo
al principio solo
te da al menos una idea de cómo
planeas ejecutar el proyecto. Y luego solo haces
ajustes menores en el proceso. Entonces comencemos. Vamos a comenzar en pre Alfa una semana. Apple estará probando algo
que debería estar presente, interacciones
básicas y movimiento. 2 horas y 4 horas
son 6 horas, por lo que debería tomar al
menos un día. Además damos 2 horas para
configurar todo para el probador. En este caso, tenemos
mecánico general cubierto completo y algunas cosas básicas
que también deberían estar presentes en el menú. No esperamos ningún
audio en el pre Alpha, ningún visual, performance,
compatibilidad, vocalización Entonces, en general, estaremos haciendo algunas
pruebas de integración solo para ver cómo diferentes sistemas
interactúan con otros sistemas. Después nos movemos lentamente hacia Alfa. El Alpha es un momento en el comienzan a aparecer
prototipos de características Entonces me gustaría pasar
algún tiempo probando mundo, tal vez tres días un día
de termina un día de batalla. Podrían aparecer
algunas primeras opciones. Así que pasemos un tiempo aquí. No esperamos ningún rendimiento
visual y audio en Alpha en absoluto, pero sí esperamos tener al menos algunas
plataformas de trabajo y algunos dispositivos. Y estamos iniciando la
última semana de Alpha. En la última semana, podría
haber ya algunas
pruebas multijugador esperadas. Entonces iría con un día de día libre multijugador
local y un multijugador y un
día libre en cada modo. Por supuesto, puedes probar
tres modos todos los días. Sólo estamos tratando de drawizar el plan principal para nosotros en general. Después de que Alpha haya terminado,
me gustaría hacer algunas pruebas de regresión
solo para cubrir la compilación. Entonces iría con tres días de regresión y un poco de regresión de
compatibilidad. Vamos a establecer una pequeña fórmula
para facilitar el cálculo. Entonces para éste,
necesitamos este número menos suma de Centio Good Entonces no necesitamos números
generales aquí, y necesitamos asegurarnos de
que tenga números. Esto es solo un día de trabajo, así que aquí es solo un número. Y aquí solo necesitamos
una suma de todo. Y si está cerca de cero, entonces hicimos un buen trabajo. Bien, muriendo atrás,
segunda semana de Beta. Probemos un poco de
contenido aquí, aquí. Bien. Bien. Bien. Entonces ahora tenemos a
dos personas disponibles. Tengamos algunas pruebas
multijugador aquí. Aún así, hacemos pruebas de contenido. Entonces el segundo día,
sería bueno probar algunos
ajustes y opciones. Y algunas pruebas gráficas. Quizás hasta dos días y también haríamos algunas pruebas de
rendimiento. Pero también podemos iniciar pruebas de
compatibilidad. Estos son tres de ellos. Tenemos uno aquí y dos aquí. Faltan dos semanas
para que termine Beta. Hagamos un poco de pruebas de
vocalización. Y algo de compatibilidad con ello. Tenemos que revisar la música
y también los efectos visuales. Podemos dejar como afijo
y fijar al escenario dorado, t's marcarlo para no olvidarlo ¿Cuándo estamos golpeando el oro aquí? Entonces será solo
pongamos cuatro y cuatro. Y tenemos que probar la
música durante la Beta, así que va a suceder antes. Entonces necesitamos probar la latencia de la red de uso de
memoria durante la Beta. Será así hasta
aquí y para y cuatro aquí. Bueno. Y la última semana de beta, necesitamos probar
mucho contenido. Tenemos que hacer una
regresión primero para
asegurarnos de que muchos
cambios no surtan efecto. Pongamos primero algunas
pruebas de regresión. Entonces entonces tenemos pruebas
de contenido. No nos olvidemos
del modo multijugador. Así que pasemos un tiempo aquí. Entonces acaba de terminar todo. Es aquí. Entonces hagamos algunos ajustes, probando. Todavía nos queda algo de tiempo para las pruebas
de compatibilidad. Y vocalización, claro. ¿Son 80 horas? Sí. La semana pasada, todavía
tenemos muchas
pruebas de regresión, lo cual es bueno. Lo haremos en los últimos días, así que tenemos que terminar
con el mundo y la batalla. Incluso podemos pasar
un día más probando y el resto es regresión. ¿ Cuántos días más tengo? Un día más. Yo iría con Comprobemos si
no se pierde nada. Tenemos 40 horas aquí, 40 aquí, 40 aquí. Bueno. Bueno. Entonces hay un
día más que podemos agregar, y tenemos pruebas de
regresión de compatibilidad, no completamente utilizadas, vocalización
y algunas otras cosas pequeñas Prefiero pasar
más tiempo haciendo pruebas de
regresión de
compatibilidad solo para asegurarme de que todas
las plataformas para siempre. Así que durante esta semana, podemos encontrar una manera en la que
solo haya una persona usada
y agregar otra. Bien, 80 y 80. Ahora nos quedamos con 12 horas,
lo cual está totalmente bien. Todavía se utilizará
durante el periodo de prueba, y ahora tenemos un cronograma
general. Se cambiará mucho durante la ejecución
del proceso, y eso es bastante natural.
Eso es lo normal. Solo tenemos que
asegurarnos de que tenemos al
menos un plan
para nosotros mismos y la capacidad de cubrir
todas las cosas principales que
necesitamos y colocarlas durante
el tiempo más relevante. Entonces ahora tenemos nuestra línea de tiempo, y pasemos
al siguiente tema.
14. Preparación de proyectos. Plan de prueba: Ahora echemos un vistazo a otro
elemento muy importante, el plan de pruebas. Un plan de pruebas es un documento
que describe el enfoque, alcance, recursos y
horario para probar un juego. Sirve como una hoja de ruta
para el esfuerzo de prueba, proporcionando orientación
al equipo de pruebas sobre cómo se
llevarán a cabo las pruebas, qué se probará y cuándo llevarán a cabo las actividades de
prueba Echemos un
vistazo más de cerca a los elementos. Primero, es el enfoque
que describe el método y las técnicas
para probar el juego. Entonces alcance que define lo que se cubrirá en
el proceso de prueba. Luego recursos que
cubren todas las herramientas, equipos y personal
necesarios para las pruebas y cronograma que
describe el cronograma para las actividades de prueba
e hitos Echemos un vistazo a todos
los componentes del plan de pruebas. Cada uno de nosotros sirve
un propósito
específico guiar el esfuerzo de prueba. Los componentes son introducción de pan de
prueba, objetivos, alcance,
enfoque, recursos, cronograma,
estrategias de riesgo y mitigación, supuestos y dependencias,
entregables de prueba y criterios de salida Echemos un
vistazo más de cerca a cada uno de ellos. La introducción de Testpan nos brinda una breve descripción del
juego que se está texteando, el propósito y el alcance del plan de prueba, y también proporciona una identificación de
las partes interesadas y contactos Luego tenemos objetivos de prueba claros y
medibles y alineación con las
metas y requisitos del proyecto. Entonces tenemos alcance, y define lo que se
probará y lo que no se probará
como parte del esfuerzo de prueba. Tenemos tres puntos principales. Se trata de la inclusión y exclusión
de pruebas, características, funcionalidades y
plataformas a probar, y condiciones
y limitaciones de límites. Luego tenemos un enfoque
que
consiste en probar metodologías
y técnicas a utilizar, niveles de
prueba y tipos de prueba. Luego tenemos la
composición del equipo de pruebas y filas, herramientas y tecnologías
necesarias para y
configuración del entorno de pruebas y pruebas. Luego tenemos un cronograma que consiste en cronograma
para las actividades de prueba, hitos y entregables y
dependencias y caminos críticos Además, incluimos riesgos y estrategias de
mitigación que consisten en la identificación de riesgos y desafíos
potenciales, estrategias de
mitigación
para enfrentar riesgos y planes de contingencia para el
manejo de imprevistos Entonces también tenemos que
incluir supuestos y dependencias que
consisten en dependencias internas, factores
y dependencias
externos, y plan de comunicación para
administrar dependencias plan de comunicación para Además, tenemos que delinear entregables
de prueba. Es una lista de entregables de
prueba, casos de
prueba, los scripts, informes de
prueba, formato y estructura de entregables de
prueba, y proceso de distribución
y revisión para entregables de prueba Y entonces tenemos criterios de salida. Eso es condiciones que
deben cumplirse para concluir las pruebas y firmar el proceso
para concluir las pruebas. Y ahora pasemos a la creación de Test
pan para nuestro juego.
15. Preparación de proyectos. Creación de planes de prueba: Ya se creó una pequeña plantilla y se colocaron aquí los elementos principales. Entonces empecemos a
popuparlo con un contenido. Y estamos comenzando con la introducción del plan de
pruebas, y aquí tenemos una visión general del juego. Pongamos aquí un aio de nuestro juego que
vamos a estar probando. Algo así como Pio Park es un juego de puzzle
multijugador cooperativo donde el jugador debe
trabajar en conjunto para superar diversos retos
y llegar a la meta. Ahora, pongamos aquí el propósito
y el alcance de las pruebas. Solo estamos recorriendo
que el propósito principal de
este plan de pruebas es garantizar que parque
Pico cumpla con los estándares de
calidad, los requisitos de
funcionalidad y las expectativas del usuario
en la etapa de lanzamiento Y para el alcance
de las pruebas, nombramos que necesitamos
cubrir todo lo que colocamos en
la estructura VBS Así que vamos a simplificarlo
un poco y solo digamos que el alcance cubre todas las páginas de trabajo listadas en el VBS para todas las plataformas
listadas en requisitos Parece que se ha vuelto más grande. El último es la identificación
de grupos de interés. Los principales actores
del proyecto son las personas que están
interesadas en su éxito. Para nosotros, podría ser el
productor del proyecto. desarrollo de la sede lleva a comunicarse con él
sobre los temas y los problemas y la gestión
de liberaciones. Por lo general, los codificadores de mesa son las personas con las que trabajas, y en su mayoría están interesados en el resultado de tu trabajo También
podría proporcionar aquí
información más detallada como nombres, posiciones y formas de
contactarlos. Pasando a los objetivos y coloquemos aquí
los principales objetivos de las pruebas. En primer lugar, necesitamos
validar la mecánica del juego. Algo importante
es el modo multijugador. Por lo que necesitamos verificar la funcionalidad
multijugador
tanto para los modos vocal como en línea. Entonces estamos llegando
a la compatibilidad. Por lo tanto, necesitamos garantizar compatibilidad entre
diferentes plataformas. Y uno de nuestros objetivos es completar todos los casos de prueba
preparados. Y también, tenemos que
asegurarnos de que se cumplan
todos
los requisitos del proyecto. Bien. Pasando al alcance.
Básicamente, definimos todos los alcances que
planeamos
probar en nuestra estructura EDT Así que vamos a enumerar
todo aquí. Bien. Avanzando. Aproximación. Para los métodos, usaremos libro negro. Y también, podemos intentar usar caja
gris y tener capacidad para probar
algo en el motor. Después para probar niveles. Vamos a comenzar
con la integración, luego el sistema y también la aceptación. Para los tipos de prueba, usaremos pruebas
funcionales no funcionales así
como más detalles
usaremos compatibilidad,
pruebas, rendimiento,
pruebas, usabilidad y también pruebas exploratorias Entonces para fuentes. Equipo. En la cima, estaremos
teniendo dos probadores, y la composición del equipo es otro tema que
estaremos discutiendo Pero en general, pueden ser nivel
medio y junior para herramientas. Hagámoslo más hermoso. FT, usaremos
Jira para las pruebas. Tren de prueba, por ejemplo, y tal vez uno de los motores. Por ejemplo, es Unity. Oh, olvidé mencionar las pruebas de
regresión. Para el medio ambiente, necesitamos consolas de
PC y dispositivos móviles, Nintendo, que se
incluirán en las consolas. Para los sistemas operativos,
usaremos Windows IOS y
Android para navegadores,
Chrome, Firefox
y Safari y para red 11 y la red móvil. Bien. Avanzando. Para horario, ya
creamos una
línea de tiempo para horario, acuerdo con la línea de tiempo
que ya creamos. Vamos a conseguir Alfa Alfa, Beta y lanzamiento. Para Pre Alpha, es el 19 de abril Alpha es el 10 de mayo. Los datos son el 14 de junio y el lanzamiento es el 24 de junio. Por riesgo, digamos algo
que se nos viene a la mente. Espero que ocurran algunos problemas
con las pruebas de
compatibilidad
porque es un gran avance técnico. Así que iría con problemas
técnicos podrían aparecer durante las pruebas de
compatibilidad. Para una mitigación,
lo primero que
me viene a la mente es definir si se trata tema relacionado con el
proyecto o tema relacionado con la
plataforma, y si necesitamos el apoyo
de una empresa regional. Los temas son específicos de plataforma
o proyecto. En este caso,
los desarrolladores tendrán más información y
capacidad para solucionar el problema. Bien, vamos a tener algunas
suposiciones y dependencias. lo que generalmente asumimos
que los desarrolladores completan todas las características y
funcionalidades planas de acuerdo a
los requisitos y diseño. Y luego también asumimos que
el entorno está
configurado correctamente y tiene todo el software de
hardware y configuraciones de
red necesarias . Y vamos a tener algunas
dependencias también. La de las mayores
dependencias es la resolución de los
defectos porque tener
errores que no se corrijan
o que los problemas de bloqueo presentes en la compilación puedan
afectar las pruebas y la planificación Ir a los entregables de prueba. Los principales entregables
son el plan de pruebas, el esquema de estrategias
y metodologías de
enfoque de prueba estrategias
y metodologías de
enfoque Entonces tenemos casos de prueba. Detallar casos de prueba que están
cubriendo todos los escenarios. Entonces tenemos reportes de defectos. Estaremos documentando
todos los defectos identificados. Informe resumido de prueba. Este es un informe resumido que describe los resultados generales
de las pruebas. Y probablemente y
eso es todo por ahora. Y el último
son los criterios de salida. ¿Qué esperamos
de nuestras pruebas? En primer lugar, esperamos
100 de los casos de prueba cubiertos. Entonces esperamos la finalización
exitosa criterios
de sustancia
para cada hito. Y lo peor es que el producto
final
no tiene grandes problemas. Y la
tasa de resolución de defectos es de alrededor del 95%. Entonces esta es la creación básica
de plan de pruebas para un juego. Es importante hacerlo para tener visibilidad
completa y
una imagen general de la ejecución del proyecto. Algunas empresas
lo hacen más detallado. Algunas empresas no lo
usan en absoluto, pero es bueno saber
algunas cosas básicas y las formas de
crearlo. Entonces, sigamos adelante.
16. Documentación. Informes: Estamos pasando a
nuestro siguiente capítulo que se llama preparación de
documentación. Es parte del papel de KL
preparar una plantilla y organizar un flujo de
documentación adecuado sobre el proyecto. En la primera parte,
vamos a hablar de K reportes
y plantillas. Exploraremos
la importancia de los informes
K en el ciclo de vida de
desarrollo, diferentes tipos de informes KA y plantillas que se utilizan
comúnmente para
documentar actividades de QA Los informes QR juegan un papel
crucial en el ciclo de
vida del desarrollo de software proporcionar información valiosa sobre la calidad del producto. Estos informes sirven como un
medio de comunicación entre el equipo de desarrollo
del equipo de QA y las partes interesadas, ayudando a identificar
problemas, rastrear el progreso y tomar decisiones informadas lo largo del proceso de
desarrollo. Los informes K juegan un
papel crucial en proporcionar información
valiosa sobre calidad del
software y guiar el proceso de toma de
decisiones. Estos informes sirven como brújulas para dirigir el curso del desarrollo
del proyecto, asegurando que los
estándares de calidad se cumplan y mantengan durante todo
el ciclo de vida del software Existen varios
tipos de informes de QA comúnmente utilizados en proyectos de
desarrollo de software. Esto incluye informes
resumidos de pruebas que proporcionan una
visión general concisa de los resultados de las pruebas. Luego informes de defectos que se utilizan para la identificación
y seguimiento de problemas de software
e informes de estado que brindan visibilidad sobre el progreso
y el desempeño
actual del proyecto. Echemos un
vistazo más detallado a cada uno de ellos. Los informes resumidos de las
pruebas
proporcionan una visión general de las actividades de prueba
realizadas durante una fase o
ciclo específico del proyecto. Hay elementos principales
como objetivos de
prueba, cobertura de pruebas, resultados de pruebas
y recomendaciones. Entonces tenemos reportes de defectos. Al aprovechar los informes de defectos, los equipos pueden rastrear
y abordar los defectos sin problemas, mejorando la colaboración y asegurando un proceso eficiente de resolución de
defectos Los informes de defectos proporcionan una visión general completa
de cada defecto, incluyendo su descripción de
identificador único, gravedad, prioridad
y estado actual. Este es básicamente el
informe principal de cada probador de QA. Al pasar al informe de estado, proporcionan actualizaciones sobre el
avance del proyecto,
incluidos los hitos logrados, incluidos los hitos logrados, los desafíos encontrados
y el gasto en elementos de acción Los informes de estado fomentan
la transparencia, la comunicación y la alineación entre los equipos
para la entrega oportuna de los proyectos Los informes de estado sirven como un medio para mantener a los interesados
y tomadores de decisiones actualizados sobre el estado
actual del proyecto y cualquier problema potencial
que afecte su progreso. Por qué es importante tener los mismos estándares en todos los
informes del mismo equipo. Básicamente, al adoptar plantillas
estandarizadas, los equipos pueden alinear sus estándares de
informes, mejorando la colaboración
y asegurando un flujo continuo de
información dentro de los proyectos En palabras simples, cada
vez que recibes un reporte, ya
sabes cómo usarlo y dónde encontrar la información que actualmente
necesitas. Vamos a crear Plantilla de
informe de resumen de prueba para Pico Park.
17. Documentación. Plantilla de informe: La forma más sencilla de crear una
plantilla es usar Google Docs. Vamos a crear una nueva pestaña. Llamémoslo un informe de resumen de
prueba y comencemos a crear una plantilla. Hagamos que todas las fronteras sean blancas, para poder dibujar nuevas fronteras. Solo vamos a crear
el borde exterior, algo
así para el inicio y todo
se creará en su interior. Nosotros solo hacemos creamos
un lugar para un nombre. Esta es nuestra prueba, informe
resumido. Lo centramos ahora a continuación, queremos tener una fecha, fecha inicio y fecha de finalización. Algo así. Por otro lado, alguna información
adicional importante como ejecutor y número de compilación Ahora, pasemos a secciones. Nuestra primera sección es resumen. Centrarlo y solo
dejamos algo de espacio para ello. Lo fusionamos horizontalmente para
poder poner algunos puntos principales. Entonces estamos agregando la siguiente sección. El siguiente apartado
es probar el alcance, también centrándolo
y dejando un lugar para los puntos principales. Hecho. Luego pasando a
nuestra siguiente sección, que es probar los resultados. Bien. Ya que necesitamos más
espacio, podemos ocuparnos del agua. Para los resultados de las pruebas,
vamos a tener dos secciones principales, casos de
prueba y errores. En esta sección,
solo queremos agregar alguna representación visual de los resultados
de nuestras pruebas. Para los casos de prueba,
queremos entender
cuántos de los
casos de prueba se aprobaron luego fallaron que
aún están por hacer porque tal vez
no logramos terminar. Cuantos aún están en progreso. Y cuántos de ellos no
pudimos probar. Lo ponemos como CNT. No pudimos probarlos por
diferentes razones. El ejemplo más fácil
es que tal vez
tuvimos que probar el modo multijugador de ocho
personas, pero esta vez no logramos encontrar a
ocho personas, y solo teníamos siete personas. Entonces, en general, probamos
1-7, pero no ocho. Entonces tenemos algunos números
aquí vamos a poner algo, por
ejemplo, por ahora,
sólo para ver si nuestras fórmulas
van a estar funcionando correctamente. 024. Ahora agreguemos algo de espacio aquí. Ahora, vamos a un diagrama
aquí. Nosotros elegimos esto. Empecemos con esto y
luego vamos al gráfico de búsqueda. A mí personalmente me gusta más
Don Style. Ahora tenemos esta etiqueta de
agregar etiqueta. Aquí está nuestra etiqueta. Bien. Y juguemos
con la personalización. Tenemos color de fondo.
Tenemos color de borde. Prefiero no tenerlo. Entonces todo aquí se ve bien. Pase. Cambiemos algo coloración porque generalmente el
pase es más verde, archivado es más rojo. Hacer es gris. En progreso es naranja y no pudo probar
, que sea morado. Cambiemos un poco el estilo
de leyenda, que
quede a la izquierda, y
agreguemos algo de valor al mismo. Yo valor de laboratorio. Se ve bien. Mudándolo aquí,
arreglando un Bien. Ahora hagamos lo
mismo cuatro pavos. Vamos a copiar, pegarlo aquí y cambiarlo
en función de la gravedad. Crítico. Alto. Pre medio W oeste. Se puede cambiar
dependiendo del proyecto y configuración. Crítico diez, hiprio 20,
medio, cinco, el Esto es sólo por un ejemplo. Entonces podemos simplemente copiar
y pegar y cambiar la configuración. Tenemos que arreglar esta es nuestra nueva gama, luego le agregamos una etiqueta y el valor está aquí. Ahora vamos a jugar un poco
con los colores. Critical es definitivamente rojo, HybrioAnge medio
medio es blanco, amarillo, es verde, y
el más bajo es azul Entonces pasemos
a la siguiente parte, que es Seguro. Resumen de defectos. Creamos espacio para ello. Pero vamos a tener algunos
elementos adicionales aquí como ID, luego resumimos la gravedad y esa línea un poco. Bueno. Esta es una
estructura básica de nuestro informe, agregarle algún formato. Áreas mínimas.
Hagámoslos de color gris oscuro. El nombre de un reporte puede
ser de color gris más oscuro tanto. Haciendo ambos. Entonces tenemos áreas más pequeñas. Hagámoslo blanco gris. Agrega un poco de borde aquí. Entonces queremos fusionarlo horizontalmente y
agregar algunos bordes dentro sobre ellos ser más blancos. Es demasiado blanco,
hagámoslo un poco más oscuro. Lo mismo aquí. Bueno. Esta es una plantilla
que podemos guardar, compartir con el equipo,
y luego usar para cualquier pase de prueba que
planeemos tener. Ahora, usemos un
ejemplo y rellenémoslo.
18. Documentación. Creación de informes: Tener una plantilla de
informe de resumen de prueba, intentemos simular
su creación. Por ejemplo, teníamos
un pase multijugador, ahora queremos
proporcionar el reporte. Entonces, lo que hacemos,
simplemente lo duplicamos, y llamémoslo
TCR, multijugador Esta será nuestra
plantilla, y será nuestra plantilla
original para todos los pases futuros. Imaginemos que teníamos un pase de prueba multijugador
que duró dos días. Por lo que comenzó el 18 de octubre y terminó
el 20 de octubre. Hombre ejecutor. Este, y construir el cambio de número 25 datos, 45, y el sonido 56. La forma en que funciona build Number suele ser definida
por el proyecto. Nos saltamos resumen por ahora, resumen es algo que
queremos proporcionar
al final cuando tengamos
todos los datos disponibles. ¿Cuál es nuestro alcance de prueba? La forma más fácil de ver nuestro alcance de
prueba es ir a VBS y ver qué se incluye
en el pase de prueba multijugador Entonces, antes que nada,
probaremos conexión
multijugador
como el juego anfitrión, unirse al juego, y juego de amigos, luego citas de PA. Funcionalidad para dos
a ocho jugadores. Entonces estamos planeando verificar todas las interacciones
en el modo multijugador. También puede haber
algunas pruebas específicas que estás planeando hacer. Por ejemplo, queremos ver
cómo funciona la desconexión. Bien, entonces simplemente lo hacemos
algo que no necesitamos. Entonces nos estamos moviendo
a nuestros casos de prueba. Por ejemplo,
tenemos 40 casos de prueba superados 15 caso de prueba fallido, cero para hacer, cero en progreso porque terminamos un
pase y por ejemplo, cinco, no pudimos probar. Ahora puedo ver que falta un elemento que
puede ser muy beneficioso. Vamos a dt aquí, y necesitamos
cambiar un poco el formato. Entonces necesitamos cambiar
todas las fronteras y traer de vuelta la frontera y
el samson es total Hagamos lo mismo aquí. Voy a actualizar esto
más adelante para la plantilla. Tengamos una suma aquí y la
excluyamos del gráfico. Tengamos lo mismo aquí. Y también
excluirlo del gráfico. Cambiemos un poco el color
para diferenciarlo. Y también podemos agregar
otro elemento. Podemos agregar un porcentaje
para cada categoría. Entonces es este
número dividido por total. Bien. Hagamos lo mismo aquí. Cambiemos el formato
a un porcentaje. Y no necesitamos tantos
números por ahí Dot. Y nuevamente, necesitamos arreglar
el formateo. Bueno. Ahora tenemos alguna representación
visual para porcentajes para
diferentes categorías. Imaginemos que tuvimos
un error crítico durante nuestras pruebas de que cuando
tienes más de cuatro
jugadores en escuadra, el multijugador no funciona. Este es un tema crítico para nosotros. Entonces también tuvimos pocos errores prio
más altos, algunos errores medianos
y pocos problemas Al final, tenemos 21 temas. Ahora vamos a pasar a
la siguiente sección y esta sección suele
crearse con la ayuda de Jira Aún no hablamos de Jira. Voy a poner algún
cuadro de marcador de posición aquí por ahora. De proyecto en proyecto,
es diferente de cuántos bugs quieres destacar en el reporte resumido. Por lo general, es crítico, prio
alto y caja mediana. Imaginemos que
en nuestro proyecto, ponemos solo temas críticos
y de prio alto En general,
se verá así. ID 01, ID 02 y ID 04. Por lo general, ponemos aquí un
enlace al boleto de Jira. Y entonces se va
a quedar así. Entonces aquí tenemos resumen
cuatro caja. Podemos ponerlo aquí. No funciona cuando el partido tiene más de cuatro
jugadores cortar
es crítico y el estatus suele representar
si en el momento de la creación
del informe inició o no
algún trabajo sobre el tema En nuestro caso, lo más probable es que el trabajo
ya esté en progreso. Aquí hacemos un poco de formateo. Crítico.
Cambiémoslo a rojo. Y el estatus y el progreso
suele ser como yo a yo. Entonces tenemos algunas cajas PEO
más altas. No quiero tomarme tiempo ahora y llegar a un resumen, por lo que es resumen uno Resumen dos
y resumen tres alto prio
do y prio es naranja Entonces esto es extra para
nosotros. Vamos a borrarlo. Arreglar de nuevo el formato. El apartado de resumen es lo primero que
estarán viendo los coviders Entonces queremos poner aquí las
cosas y hallazgos más importantes. Para nosotros, lo más
importante es que función
multijugador no es funcional cuando hay
más de cuatro jugadores. Así que solo podemos comenzar con ello. Y también podemos agregar un enlace al ticket
del jurado para que todos
puedan rastrear el progreso. Imaginemos que es un enlace. Entonces la siguiente información
importante es que hay tres temas
más de alta prioridad. Así que vamos a poner algo de información
breve al respecto. Y también agregamos enlaces. Entonces agreguemos alguna información
general sobre la característica en sí. En general, la
función multijugador es funcional, por lo que podemos elaborar más. La tasa de aprobación es del 67%. Y también alguna información
sobre la calidad. Hay 21 cajas reportadas. Como se trata de un pase
simulado y
no tenemos información más detallada por ahora, creo que estamos de acuerdo con este estado
actual del informe. Entonces estamos haciendo estas filas. Podemos hacer algún formato
haciendo negrita, y verde. Este verde es al
blanco, verde oscuro. Y después de que todo
esté terminado, o simplemente
copiamos, pegamos todo y lo metemos en
el correo electrónico o lo guardamos como Perdev y lo enviamos a todos los stakeholders a través canal de
comunicación que
se estableció previamente También puede haber
diferentes secciones, diferentes partes
y diferentes formas de reunir toda la
información. Acabo de mostrarte la forma
más sencilla de asegurarme proporcionar la valiosa
información a las partes interesadas, proporcionar algunas ideas y estado
general de la
característica que se probó. Asegurarse de que todos los miembros del equipo estén usando la misma
plantilla hace que la
comunicación sea más
eficiente porque si recibes el mismo
tipo de reporte, sabes dónde se encuentra la información que
buscas en él. Ahora, después de que todo
esté hecho, vamos a movernos
19. Documentación. Severidad y prioridad: Como equipo, estamos cada vez más cerca de reportar nuestra caja. Pero antes de proceder a esto, necesitamos definir
algunas cosas importantes como prioridad y gravedad
para la caja reportada. En general, se define
por la teoría de las pruebas, pero vamos a tener algunas pautas
únicas para nuestro proyecto, el
equipo debe seguir. Para ello, vamos a crear una pestaña
adicional en nuestro documento y
llamarlo pautas de severidad y
prioridad. Ahora hagamos un poco de
formateo sencillo bastante rápido. Hacemos todas las Fronteras blancas. Entonces queremos tener sección de
severidad. Y sección prioritaria. Empecemos por la severidad. En primer lugar, estamos
esperando una severidad alta, luego esperamos una gravedad media. Esperamos baja
severidad y menor. Bien, comencemos
con alta severidad. ¿Qué definimos
como alta severidad? En primer lugar,
debería ser una característica que no funcione. Esto
es bastante claro. Entonces queremos agregar algunos tiempos
reales del proyecto. Por ejemplo, tenemos característica
que funciona parcialmente, pero tenemos un lanzamiento pronto
y necesitamos probarlo. Así que ponemos aquí bugs que impiden que QT pruebe. Entonces queremos agregar algunos elementos
diferentes. Ejemplo, problema de sonido importante y problema de controles importantes. Y por supuesto, cualquier
choque o congelamiento. Bueno. Después moviéndose a
la gravedad media. Es hacer formateo
bastante rápido. Bien. Para severidad media, necesitamos
comenzar con algo que veamos algunos fallos
gráficos importantes. Entonces tenemos características que
parcialmente no funcionan. Y algo que ayude a
definir la gravedad media. trata de un error que afecta experiencia
del usuario pero que no
impide el juego. Bueno. Eliminamos algo
que no necesitamos, y estamos pasando
a una gravedad baja. gravedad baja suele
definir los errores que tienen un impacto mínimo en el
juego o la experiencia del usuario. Por lo general, estos errores no
requieren acción inmediata. Los más comunes
son los errores de texto, luego algunos problemas menores I, menores. Falla gráfica y algunos problemas
menores de rendimiento. Y nos estamos moviendo a
la gravedad más baja. Los problemas de gravedad más bajos son
algo que agradable de solucionar, pero no afectan a ninguna experiencia
de juego o usuario. Cosméticos problema de interfaz de usuario muy menor. El más común es la sugerencia. La sugerencia es un tipo de error muy
interesante. P suelen proporcionar
algunas sugerencias, cómo piensan que pueden mejorar la jugabilidad y usar
su experiencia. Y de vez en
cuando, dependiendo los plazos y de lo
ocupados que estén los desarrolladores, todos los stakeholders
pueden sentarse juntos, repasar todas las sugerencias y arreglar o implementar
algunas de ellas. Pero van a la gravedad
más baja solo porque el juego sigue funcionando
como se diseñó originalmente, y esta es solo una
forma de mejorarlo. Bien, vamos a
copiar nuestro formato, hacerlo todo el texto, y ¿qué tenemos aquí? Llamemos a esto severidad. Éste. Y por lo general hay tres
grandes prioridades. Primero uno es alto, luego tenemos medio, y luego tenemos bajo. Y para alta severidad y en
las secciones de gravedad alta, tenemos errores que deben
abordarse de inmediato a su impacto crítico en la funcionalidad del juego
o la experiencia del usuario. Aquí hay algunos ejemplos. En primer lugar, el juego se bloquea. Siempre son de alta prioridad. Entonces tenemos bichos que están impidiendo que el juego salga a la sala. Entonces tenemos los bugs que están impidiendo que QT se pruebe. Entonces tenemos temas actuales de
sprint. ¿Por qué los temas actuales de sprint
tienen alta prioridad? Porque era nuestro plan
implementar estas
características, este sprint, y estamos planeando mostrar
el resultado a las partes interesadas, y queremos
que vean que la funcionalidad está funcionando y que están
contentos y todos están contentos. Prioridad media y baja en general, imita las secciones de severidad, por lo que no necesitamos dedicarnos
mucho tiempo a definirla Nosotros solo copiamos y
pegamos lo mismo aquí. Entonces solo lo copiamos aquí. Agreguemos un poco de codificación de colores. Y ahora hablemos de
algo que es un todo esto, que son temas críticos. Vamos a agregarlo en la
parte superior de todo. Este es grande y rojo. Lo cual se pone aquí
una pauta para todos los temas críticos que no se vean afectados por ninguna
gravedad o prioridad. Son los bichos más importantes que deben ser tratados lo antes
posible. En primer lugar, volvemos
a los bloqueos de juego que ocurren inmediatamente después de que el arranque
se colocan en los caminos dorados y nos impiden
completar el juego. También se les conoce como
walk through bokers y cualquier caída que
esté presente en el
juego antes del arrendamiento La siguiente sección es para la pérdida o corrupción de
datos, incluyendo Guardar archivos,
la progresión del jugador que se pierde y en los elementos del juego o moneda que desaparecen
de los inventarios de jugadores Entonces tenemos problemas multijugador donde el modo multijugador no funciona. Para nuestro juego, es
muy crucial e importante porque es uno de puntos
de venta
y la mecánica base. Entonces tenemos graves problemas
de desempeño. Además, incluimos cualquier vulnerabilidad
de seguridad. Y el último es
importante para los negocios cuando alguna de las
características de venta no está funcionando. Porque en este caso, tenemos el riesgo de que la compañía no pueda vender el juego, recibir críticas negativas y el juego no
sea rentable. Q debe tener cuidado con
estas características y
asegurarse de que la producción sepa sobre cualquiera de los errores que
le sucedieron Estas son pautas bastante
básicas, pero es importante que
cada miembro del equipo lo sepa y
se guíen por
él a la hora de informar sobre los problemas. Ahora pasemos a Jira.
20. Jira. Plantilla de error: Y nos estamos moviendo a la parte de Jira. Por lo general, cuando
llegas al proyecto, la Jira ya está presente y ellos simplemente crean
una cuenta para ti Pero imaginemos
que en nuestro proyecto, tenemos que configurarlo
todo por nosotros mismos Entonces solo vamos al sitio habitual
de Jira
y presionamos consígalo gratis Ponemos nuestro correo electrónico
y presionamos registrarse. A
Jira le toma algún tiempo configurarlo todo. Estamos eligiendo la plantilla más
popular y Prest. Nos pide que demos
un nombre de proyecto. Vamos a llamarlo prueba de Pico Park. Y escojamos que estoy un
poco familiarizado con Jira. Y en el estado actual, tenemos una Jira totalmente clara, y podemos empezar a montarse en ella En primer lugar, vamos a
crear una plantilla de error. Para esto, tenemos que ir
a la configuración del proyecto, luego elegir el tipo de problema y debemos agregar el tipo de problema. Esto es un error, y presionamos Add
Jira
agrega automáticamente campos principales como descripción
resumida,
estado, SME, etiqueta,
padre y reportero El reportero está presente en la sección vacía de
altura, pero no queremos
que esté vacía,
así que volvamos a moverlo a los campos de contexto
habituales. Vamos a acercarlo al SNE para que estén
cerca el uno del otro, y no creo que necesitemos padre así que simplemente lo quitamos Ahora, también queremos
agregar algunos campos de contexto que nos van a ayudar en la
organización del proyecto. Entonces, antes que nada, necesito
comenzar con severidad
y prioridad. Así que voy a crear la
sección Campo y elijo desplegable. Entonces codifico severidad
y tengo opciones críticas altas, medias y más bajas. Dije medio por defecto. Este es un campo obligatorio, y lo movemos bajo reportero. Nosotros hacemos lo mismo por prioridad. Las opciones son altas,
medias y bajas. Entonces también necesitamos algunos elementos importantes
como pasos para reproducir, así que elegimos texto, y lo llamamos pasos para reproducirlo y
hacerlo también requerido. Además, lo bueno es
tener número de construcción. Lo movemos al final ya
que no es tan importante. Además, para un mejor seguimiento, agreguemos un componente de código de
campo adicional. Es una
sección desplegable y en opciones, queremos enumerar todas las áreas de nuestro juego,
como
la funcionalidad, luego la interfaz de usuario
rendimiento de sonido compatibilidad visual y vocalización Nos bajamos un poco bajo
la sección de prioridad. Ahora guardamos nuestros cambios. Ahora veo que en realidad los pasos para reproducir deben ser
de tipo párrafo. Entonces lo retiramos y agregamos de nuevo. Ahora, ya está hecho. Volvamos al proyecto e intentemos
crear nuestro primer bug. Presionamos el botón Crear. Tenemos esta ventana apareció, y empezamos con Sam. El partido consta de ocho jugadores. Vamos a paso para reproducir, primer paso es
poner el título en Build ir al juego host
multijugador, esperar
a que siete jugadores se unan presione start. Bien. Yo descripción, damos alguna
información adicional multi player. No trabajo cuando hay
ocho personas en la fiesta, funciona para uno
a siete jugadores. En SINE, ponemos ya sea a nuestro gerente o desarrollador
responsable. Yo soy el reportero y nuestra gravedad es crítica porque tenemos
lanzamiento en una semana, y lo ponemos como alta prioridad por componente
que es funcionalidad, campo de
etiqueta. Por ahora,
no lo necesitamos. Número de compilación, por ejemplo, cambiar x, luego datos, luego sonido. Entonces este es nuestro número de compilación. Ponemos los archivos adjuntos
que tengamos, como videos o
capturas de pantalla, tal vez buey. Si hay una tarea para
crear multijugador, entonces podríamos vincularlo, pero en nuestro caso, no lo
vinculamos. Y tenemos esta capacidad de ***
para asegurarnos que todos
entiendan que este es un error
importante y
presionamos Crear. Y vemos que nuestro primer
error apareció en nuestro tablero.
21. Jira. Estado y filtros: Intenta cambiar un poco la configuración
de nuestro tablero. Para esto, he agregado
algunos bugs de marcador de posición, así que es visualmente más fácil para nosotros. Lo que tenemos que hacer primero,
volvemos a la configuración, tipos de
problemas, error y
editamos un flujo de trabajo. Creo que en esta
etapa de la carrera, todo el mundo es bastante consciente
del ciclo de vida que parece. Entonces solo necesitamos agregar
los estados a Jira. Entonces necesitamos nuevo estado en
progreso, vamos a
llamarlo que review. Y necesitamos el estado para toda la caja que se
arregló y necesita prueba de QA. Después de la prueba,
podríamos rechazar la solución, por lo que el desarrollador
necesita volver a hacerlo. Entonces agregamos el estado de QA rechazado. Y también, a veces
ya sea desarrollador o QA necesita más información. Por lo que agregamos
estatus adicional que se llama necesita más información. Después presionamos actualizar
el flujo de trabajo. Y ahora tenemos las columnas
actualizadas. Vamos a cerrar volver al
proyecto, veamos cómo funciona. Bien, tenemos que
reorganizarlo un poco. Presionamos configurar placa. Nos movemos hecho al
final en más info aquí. Entonces tenemos que hacer en
progreso en más información, Q rechazado, K revisión, y hecho. Guardemos nuestros cambios y
echemos un vistazo a cómo funciona. Comprobemos si
también funciona correctamente. Pongamos alguna caja en
diferentes secciones. Haga clic en él y vea que necesita
más información. Vamos a corregir. Esto es K rechazado, correcto. Y esto está en revisión. Comprobemos también si
hecho funciona bien. Sí. Entonces nuestra junta
parece estar funcionando. Ahora, creemos
algunos filtros básicos y comencemos a construir
nuestros dashboards Simplemente, para crear un filtro, necesitamos presionar sobre la búsqueda. Y ponlo a la vista de lista. Hazlo este, elige nuestro
proyecto tipo pickupark, bug. Y eso es todo esto es
nuestro primer filtro que se llama Pia park O Bx Si queremos usarlo para los dashboards y
el equipo para configurar, necesitamos
cambiarlo de privado a
grupo u organización
y elegir a todos los usuarios Entonces, este es nuestro primer filtro. También vamos a crear un filtro
adicional para todos los cuadros críticos o marcados. Para este, simplemente
agregamos atributo adicional, que se llama flagged Ahora tenemos cuatro casillas
que están señaladas y guardamos como copia para
que sea una nueva Llamamos a todos caja señalizada. Ahora, puedes ver que tenemos dos filtros que podemos usar
para crear nuestra darda En el proceso de
creación de dardos, podríamos necesitar filtros
adicionales, por lo que
los estaremos creando en el Y ahora pasemos a la
primera creación de dardos.
22. Jira. Creación de paneles: Ahora pasemos a la
primera creación del dashboard. Presionamos en los dashboards, y presionamos Create Dashboard Pico, parque Tablero principal y haremos lo
mismo con la acción. Y ya está hecho. Este es
nuestro primer tablero, y necesitamos
definir qué queremos ver en él y por
qué incluso lo necesitamos. Normalmente construyo cuadros de mando. En la forma en que
me ayudan a crear reportes. Entonces tengo toda la información visual que ya está filtrada para mí. En primer lugar, quiero ver la lista visual de todos mis libros. Entonces solo voy con filtro. Filtrar resultados. Elijo todos los bichos, y elijo lo que quiero ver. Tipo de problema, error, K, resumen, prioridad, gravedad y estado. A para refrescar, guardar. Y tengo mi primer widget. Vamos a llamarlo Pico
Park lista visual y portada verde. Vamos a moverlo a la derecha. Entonces quiero ver la caja
dividida por diferentes severidades. Voy al
filtro bidimensional. Lo agrego aquí. Elijo caja para Y xs. Quiero severidad para
Xxs quiero estatus. Tengamos diez, ahorra. Y ahora podemos ver
el futuro para todos los estados y todas las
severidades que tenemos Vamos a cambiarle el nombre. Cuadro de parque Peco
ordenado por severidad. Y elijo algún color
diferente. Entonces quiero ver todos
mis problemas marcados. Entonces elijo diferentes temas señalados de
teatro. Lo que me interesa
ver es su estado. Y la prioridad que hay que arreglar. Tengamos más, y
veamos cómo funciona. Vamos a retocarlo un
poco, cambiar de lugar. Total y X para elegir prioridad
e Y para elegir estado. Vamos a renombrarlo de
cinco cuadro por estados. Y hagámoslo rojo. Este es nuestro top pio. Creemos también un filtro
para todas las cajas sin resolver que no perdamos nuestro tiempo en algo que ya está
en estado hecho Vayamos a Filtros. Vamos a toda la caja y solo agregamos
y solo elegimos resolución. Y elegimos todas las cajas
sin resolver. Guardamos el filtro
como copia y llamamos a todos y lo llamamos a
todo caja sin resolver Lo guardamos, y
volvamos a nuestro dashboard. Vamos a dt y también
añadimos este filtro. Que es caja bidimensional
o sin resolver. Escojamos componente
y nuestra severidad. Y veamos qué
tenemos. ¿Bien? Vamos a cambiarle el nombre.
Ah, caja sin resolver. Por componente. Bueno. Oh, hagamos
amarillo y muévanse aquí. Entonces echemos un vistazo rápido
al tablero y
veamos qué tenemos. En primer lugar, vemos todos los errores de
hecho por sus estados. Entonces podemos ver que algunos
de ellos están en progreso, algunos de ellos fueron rechazados, y algunos de ellos
aún están por hacerse. Entonces podemos ver todos los
bugs por severidad. Entonces, si necesitamos
crear algún filtro, solo
podemos presionar aquí
y agregar algunos detalles. Por ejemplo, necesitamos
todos los errores no resueltos. Entonces agregamos resolución,
presionamos sin resolver, y también queremos tener alguna medida de tiempo
cuando se creó Entonces vamos aquí,
pulsamos crear tiempo. Y podemos elegir algunos rangos
y utilizarlos para reportar. Entonces solo tenemos
una lista de bolsas, y también podemos filtrarla, ejemplo, por severidad. Y tenemos la lista de todos los pantanos no resueltos
en función de su componente. Y podemos ver que la caja
más crítica está presente por compatibilidad
y funcionalidad, e incluso podemos hacer clic en
ella y ver qué es. Ahora, agreguemos también alguna representación
visual. Así que vamos a elegir un gráfico circular y, por ejemplo, elegir cuadro y componente
no resueltos Nos da este
hermoso filtro para entender la división de caja
entre diferentes componentes. Vamos a llamarlo. Una
caja no resuelta por componente Et se mueve al fondo. Y podemos hacer lo
mismo por severidad. Una caja sin resolver y
elegir severidad. Podemos ver el 25%
crítico alto bajo ost. Y vamos a moverlo también
al fondo. ¿Hecho? No, está salvado. Por lo que solo tenemos tablero principal con
toda la información principal, incluyendo alguna
representación visual de nuestros datos. En general, el tablero también
es muy útil. Normalmente creo muchos dashboards
diferentes para diferentes pases,
para diferentes
componentes, y
los utilizo para ver el estado y
el estado del proyecto Por ejemplo, cuando hay
un mejor periodo de validación, también suelo crear mi panel especial
dedicado a este proceso. No vamos a
entrar en detalles por ahora, pero creo que
tienes la idea principal y la forma de crearla. Entonces con un poco de
imaginación y práctica, creo que vas a
poder crear una hermosa y útil
dianas. Y sigamos adelante.
23. Pruebas. Hitos: Deja ir a nuestro siguiente tema y
platicar sobre los procesos de
ejecución de texto. Hablemos de cosas
importantes como hitos y el
papel de QL en su éxito pases de hitos
juegan un papel crucial en el ciclo de vida del proyecto, marcando etapas clave
del progreso y asegurando la alineación
con los objetivos del proyecto. En general,
hay dos cosas principales que son importantes para Q Elite. El primero es la
supervisión del punto de control que asegura que se cumplan los criterios
del proyecto antes avance en las puertas de Milestone Entonces es la supervisión de pruebas. Como Q Elite,
debe supervisar las actividades de prueba para mantener
los estándares de calidad
en los pases Milestone Lo importante de hito es que después de realizar pruebas
y validaciones de hitos, es más fácil para nosotros evaluar estado y la
progresión
del proyecto y asegurarnos que todo se entregue a
tiempo y de acuerdo con los estándares de
calidad Tener una mirada de hito nos
da la capacidad de tener un enfoque estructurado para
evaluar el desarrollo del proyecto, guiar las decisiones sobre la
dirección del proyecto y los próximos pasos. En palabras simples, después de recibir los resultados de la validación de
hitos, el equipo puede entender si se
están moviendo en
la dirección correcta. Hagamos un breve
recorrido por los principales hitos, y comencemos con Alpha El hito Alpha marca una fase crítica en el proyecto, centrándose en la
validación de características principales y las pruebas tempranas. Qa juega un papel vital
durante Alpha al garantizar la funcionalidad
inicial
e identificar defectos
críticos para su resolución. ¿Cuáles son las expectativas
del QA en la etapa Alpha? En primer lugar, se trata de probar y validar las funcionalidades de las
características principales. Luego identificación
y priorización de defectos críticos
para su resolución, asegurándose de que la
producción
conozca primero los problemas más
críticos Y también para iniciar las primeras colaboraciones con el equipo de
desarrollo, comunicarse con ellos
y asegurarse de que entienden todas las
prioridades establecidas por QA Y hablemos de
las responsabilidades de QED durante este hito En primer lugar, es la planificación de pruebas antes del inicio del hito
Alpha, QLID se asegura de que
comprenda la funcionalidad
y las características
esperadas
y cree un plan de validación Otra cosa importante es la
comprensión de la cobertura. QED se asegura de que
tiene todas las actualizaciones del equipo de desarrollo sobre
qué características se
planearon e implementaron
para la etapa Alpha, qué debe probarse
y qué no Y luego QED crea una lista de características para cubrir y la
comparte con el equipo Y por supuesto, otra responsabilidad
importante
es la comunicación
con las partes interesadas. Se puede hacer a través de gráficos, llamadas o correos electrónicos e informes porque
lo principal es asegurarse de que otras partes interesadas tengan
la total transparencia alineada con las metas y
entiendan el estado actual. Ahora hablemos de
Beta Milestone. En general, Beta Milestone debe estar contenido completo
y característica completa, y el juego debe estar
cerca de la etapa final. ¿Cuáles son las principales
expectativas de QA? En primer lugar, Team debe planificar las pruebas de regresión regulares para asegurar la estabilidad
de la construcción. Entonces Katam se está asegurando de que todo el contenido y todas las funciones estén completadas e integradas Y también equipo realiza monitoreo de
métricas de rendimiento y está tratando de identificar las áreas
para la optimización
porque en la etapa Beta, rendimiento es muy importante y el juego debe
ejecutarse sin bloqueos, picos o caídas de FPS. Veamos cuáles son las expectativas
de KELite en etapa Beta En primer lugar, es
una coordinación de todas las actividades y recursos
porque en este momento, la producción podría
haber cerrado beta, beta
abierta, y estarán usando diferentes
cogollos para todas estas actividades, y depende de QElite dividir los recursos de
la manera más eficiente Otra cosa importante
es la priorización. El juego ya tiene mucho
contenido, todas las características integradas, habrá mucha caja, y le toca a Q Elite
priorizarlas. Además, podría haber comentarios
recibidos de la realización de otras actividades como
Beta abierta y beta cerrada. Por lo tanto, Q Elite necesita asegurarse que se alinea con los objetivos
del proyecto, filtrarlo y
compartirlo con las partes interesadas Y la
parte muy importante es informar. Necesitamos
asegurarnos de preparar informes de pruebas
integrales, asignaciones de preparación
del proyecto y compartirlo con todas
las partes interesadas. Y ahora estamos en el hito maestro que
significa la etapa final
antes del lanzamiento de la producción,
donde se verifican todas las
características críticas, donde se verifican todas las
características críticas resuelven los
defectos y se valida la preparación de la
producción ¿Qué esperamos del
equipo de QA en este hito? Verificación de que todas las características y funcionalidades cumplen las especificaciones y no tienen ningún bug que esté impidiendo que
el juego se lance. El equipo confirma que todos
los errores que se reportaron previamente se resuelven y se pule
el producto. Y luego Team realiza
la validación final, recorriendo todo el
contenido del juego para asegurar que el producto esté
listo para el lanzamiento. Ahora, volvamos a
las responsabilidades de QA. En primer lugar, manejamos las actividades de prueba
finales, asegurándonos de que
no se perdió nada, se probó
el juego completo y se completó todo. Sucede muy a menudo
que en la etapa final, el juego todavía tiene algunos problemas
sin resolver, por lo que Keld necesita
colaborar con todos los stakeholders para
asegurarse de que están al tanto de ello, y se toman
decisiones ya sea para posponer lanzamiento y arreglar los problemas o liberarlo y solucionarlo más tarde Además, este es el momento de plantear sus inquietudes sobre el estado de la calidad a todos
los grupos de interés. Y también, necesitamos preparar informes
finales de prueba y evaluación de
preparación para
la conclusión del proyecto. Entonces, como conclusión, hay algunas cosas que son muy
importantes en cada etapa. En primer lugar, es
comprender el alcance y la preparación
de la cobertura de las pruebas, y luego asegurarse de que todos los interesados sean conscientes del estado
de la calidad, capaces de comprender sus informes y estén al tanto de cualquier
problema que esté presente.
24. Pruebas. Hitos: Crea algunos
criterios básicos de hitos para nuestro juego. Para ello, vamos a
crear una nueva pestaña, llamémosla criterios de hito Y empieza a
poblarlo con los datos. Empecemos con Hito Alfa y comencemos con criterios básicos. El primero es bastante básico que nuestro juego
no se bloquea o no se congela. Esto
es bastante básico. Entonces dos sobre nuestra funcionalidad
principal de juego y jugabilidad está presente. Pero para Alpha, no esperamos que todas las características se
integren e implementen. Entonces agregamos un pequeño nodo
uno por instancia. ¿Cuál es el significado de esto? Pasemos a nuestra
estructura VBS y veamos que las principales características para
nosotros son el multijugador, mecánica
general
y los modos de juego No necesitamos todo
esto para estar funcionando. Solo tenemos que asegurarnos de que una instancia de cada una esté funcionando. No esperamos que el
multijugador en línea y multijugador
bienvenido sea completamente funcional con ocho jugadores. Solo tenemos que
asegurarnos de que es posible jugar el juego
en modo multijugador. Entonces vamos aquí,
funcionalidad multijugador,
local, luego
funcionalidad multijugador en línea. Entonces esperamos que el movimiento
esté funcionando. Entonces un nivel por cada modo. Entonces vamos a
asegurarnos de que tenemos algunos objetos interactuables
que también se implementan Y el mismo por instancia. El significado principal de
esto es que tenemos cajas
clave y puentes como
principales objetos interactables, pero no esperamos que todas las claves en todos los
niveles estén funcionando Solo tenemos que asegurarnos de que funcionalidad
general
de una clave esté funcionando. Entonces lo copiamos aquí hecho. Entonces simplemente vamos por
otras funcionalidades. La interfaz de usuario es funcional. Tampoco esperamos
la funcionalidad. Solo esperamos que
los menús sean funcionales. Entonces se integra el gestor
de sonido. Entonces en la etapa Alpha, esperamos que algún sonido
esté presente en el juego. Entonces no esperamos ningún
visual en la etapa Alpha, pero sí esperamos
alguna actuación. Entonces, en la etapa Alfa, estamos rondando nuestro FPS objetivo No esperamos que sea suave, así que no hay caídas de FPS. Nosotros debemos 20. Por lo que establecemos
nuestro objetivo en 20 fps. Entonces no esperamos que se integre ninguna
compatibilidad
o que la vocalización y
las actividades sean más para una Q. Así que este es nuestro criterio de
hitos Alfa Vamos a formatearlo un poco. Y agreguemos algo de validación de
datos ahí. Entonces respondemos al menú desplegable
y tenemos dos opciones. Uno es pasar, otro es fallar. Y hacemos lo mismo
para los subcriterios. También podemos agruparlo para un mejor seguimiento y luego
agrupar este criterio.
25. Pruebas. Añadir criterios: Lo siguiente, lo que
tenemos que hacer es
integrar nuestros criterios
en nuestro proyecto Jira Simplemente vamos a nuestro proyecto. Luego vamos a la configuración del proyecto, nos encontramos con el tipo de problema bug, y necesitamos agregar cualquier
campo que sea un menú desplegable. Criterios alfa, validación, y necesitamos poner aquí
todos nuestros criterios Y luego lo salvamos. Ahora
veamos cómo funciona. Así que vayamos a nuestro tablero, intentemos crear una nueva característica, y tenemos validación de
criterios Alpha. Entonces funciona. El
siguiente paso es agregar el widget a nuestro
dashboard, vamos a editar, que es filtro bidimensional, que es todo
cuadro sin resolver porque en general, todo lo que se arregló
no es tan interesante para nosotros Entonces, para X,
escojamos el estado para X, y para Y,
elegimos la
validación de criterios Alpha. Apareció aquí. Número de resultado
diez, y nosotros a salvo. Por ahora, podemos ver
que no tenemos ninguno porque no tenemos
pantanos que tengan este criterio Vamos a renombrarlo
COVID de validación. El cambio de portada y lo que tenemos que hacer para que la
caja aparezca aquí, necesitamos actualizar este
campo en la caja. Entonces vayamos a nuestro proyecto. Por ejemplo, tenemos ventana de
interfaz de usuario está vacía. Llegamos a criterios APhA y
ponemos UI no es funcional. Y por ejemplo,
vamos a poner aquí también este
criterio. Ahora vamos a revisar nuestro tablero de instrumentos. Entonces ahora podemos ver que
tenemos bugs que están fallando los criterios de
cobertura
porque el mejor de los casos es cuando todos ellos no son ninguno. Así que imaginemos que terminamos
nuestra validación Alpha, y ahora nuestro tablero
se ve así. Por lo que todavía tenemos dos
criterios que son fallidos. Vamos a nuestro reporte, vemos
que UI no es funcional, así que ponemos fallar aquí
y hay gotas, ponemos fallar aquí y no
hay otros temas, es
decir, todo lo demás es pasar. Entonces simplemente pasamos todo así es como funcionarán nuestros
resultados de hitos Alpha. En base a esto,
estaremos preparando el informe y compartiéndolo
con otras partes interesadas. Ahora, preparemos algunos criterios básicos de hitos
beta.
26. Pruebas. Beta y criterios dorados: Mucho más fácil preparar mejores
criterios de hito cuando
tenemos estructura VBS
porque en general, solo
necesitamos
probar todo el juego Entonces hagámoslo rápidamente. Tenemos mejor hito. Entonces, el primer criterio es el mismo. Segundo criterio es el mismo, pero ya no es
uno por instancia. Entonces esperamos que el
multijugador de Bienvenida sea completamente funcional
y el multijugador
de vino sea completamente funcional, luego esperamos el movimiento luego
esperamos un mundo sin fin y
batallar todos los niveles. Entonces tenemos
objetos interactables que se implementan. No más uno por instancia, entonces tenemos algo que es bastante nuevo es el contenido completo,
es
decir, que todos los
activos están integrados. Y no quedan titulares. Entonces tenemos UI
funcionales y para UI, necesitamos todas las cosas El siguiente es el gestor de sonido. Ya no está integrado. El sonido es integrado y funcional y
simplemente copiamos todo. Entonces tenemos visuales. Están integrados y el
rendimiento funcional es estable. Ningún FPS cae por debajo de 60. Entonces el siguiente es que la
compatibilidad está integrada. Teníamos criterios y el
último es sobre localización. La ización está integrada. Hagamos un poco de
formateo rápido aquí. Ese es nuestro criterio básico Beta. Después de las pruebas,
se verá algo así. Esto será pase. Si no
tenemos choques, esto podría ser O
pasar y luego pasar. Esto debería ser también O pass. Hay algún error
en el formateo. Bien. Pase completo de contenido, la
interfaz de usuario es funcional. mejor tenemos algún bug con UI, por lo que pasará pase, pero fallará si hay uno falla, que el criterio es
fallido en general. El sonido está integrado, las imágenes están integradas, las pruebas
gráficas fallan, pase de
rendimiento, el pase de
compatibilidad y la vocalización es Y después de tener
mejores criterios, que hacer lo
mismo con Jira, ir allí, y en el nuevo campo, no
vamos a estar haciéndolo
ahora mismo porque es exactamente
lo
mismo que hicimos para Alpha Y para Golden Milestone, los criterios son
bastante los mismos porque comprobamos la funcionalidad
principal Lo que podemos hacer es que
en realidad podemos copiar y pegar
todo lo que se llama Dorado y agregar un
criterio que se llama O M platos son fijos. Básicamente, este criterio
será algo que difiera el estado del
juego en Beta y en Golden. Apenas unas palabras
sobre los criterios. Si estás trabajando
en la gran empresa, probablemente ya tengas los
criterios definidos para ti Entonces solo necesitas seguirlos. Y si estás trabajando
en una pequeña empresa, entonces depende de ti organizar las pruebas y el proceso de
trayectoria de hito. Lo importante es
asegurarse de que su equipo comprenda completamente
sus expectativas y tenga una
visibilidad completa sobre cómo
planea realizar la validación de
hitos. Estos son sólo algunos criterios
básicos que estuvieron trabajando para
mí toda mi carrera. Si solo los creas para
ti y los sigues, la vida
te será más fácil. Entonces eso es todo. Sigamos adelante.
27. Pruebas. Priorización: Terminado de crear los criterios y las pruebas ahora
están en curso, hay algunas actividades
que QLT suele realizar Echemos un
vistazo a algunas de ellas. Y primero es la priorización. La priorización es vital en
las pruebas para optimizar los esfuerzos, asignar recursos de
manera efectiva y mitigar los riesgos que afectan el cronograma
del proyecto El desarrollo del
juego no es perfecto, y en ocasiones nos enfrentamos a
situaciones en las que no tenemos
suficiente tiempo ni personas, por lo que necesitamos
asignarlos adecuadamente. Entonces, como élite clave,
asumes esta responsabilidad sobre
ti mismo y tomas decisiones. La priorización permite que los equipos
se centren en áreas críticas, mejorando la eficiencia de las pruebas,
reduciendo los retrasos en los proyectos y asegurando entregables de calidad
dentro de los plazos establecidos Existen diversas técnicas para priorizar las tareas de
prueba que existen, que es
enfoques y criterios a distancia Echemos un
vistazo a algunas de ellas. La primera es la técnica
basada en el riesgo. La idea principal es identificar y abordar primero las áreas de
alto riesgo. La siguiente técnica se
llama basada en impacto. La idea principal es
priorizar las tareas en función su impacto en
las funcionalidades críticas para mejorar los resultados Otro se
llama basado en el tiempo, y se basa principalmente en
considerar plazos y horarios de
entrega
al priorizar las tareas de
prueba para la eficiencia La idea principal de esta técnica está en la capacidad del conductor de QA para identificar las
áreas más riesgosas y probarlas primero. La identificación se puede
hacer con base en la experiencia de proyectos anteriores sobre el análisis del estado
actual de calidad, es
decir, verificar el área
que tiene más errores reportados o después de platicar
con el equipo y preguntarles cómo desarrollo
y preguntarles cómo
va
el desarrollo y qué ven como el área más
difícil de implementar. La idea principal de
esta técnica es que la priorización
de áreas de riesgo y pruebas
adicionales aseguran
que las áreas de alto riesgo sean probadas a fondo para
minimizar posibles fallas, mejorando el éxito del proyecto
y el aseguramiento de la calidad Veamos algunos
ejemplos de Pico Park. Y imaginemos
que después de la discusión con desarrolladores y en
base a la propia experiencia, identificamos dos áreas
que son las más riesgosas. El primero es el multijugador online. multijugador en los juegos siempre es un área arriesgada porque
requiere tener el servidor, una conexión
estable
y otros detalles. Otra área es la compatibilidad, es
decir, que diferentes plataformas requieren diferentes configuraciones, e identificamos esta área como riesgosa y esperamos que haya muchos
errores ahí. Entonces tenemos que
probarlo más a fondo. Pasando a la siguiente técnica, técnica de priorización basada en
impacto se centra principalmente tareas de
prueba
basadas en su impacto en funcionalidades críticas
o escenarios de usuario En palabras simples, priorizamos las
pruebas de las áreas que podrían tener el mayor impacto en experiencia
del usuario y
sus expectativas Y como resultado, después de asegurarnos de que
probamos todas estas áreas, aumentamos la posibilidad
de éxito del proyecto. Echemos un
vistazo a algunos ejemplos. Y para el Parque Pico, tenemos el siguiente ejemplo. El primero es probar el rendimiento
del sistema porque bloqueos o caídas de pases pueden afectar mucho la
experiencia del usuario. Entonces el siguiente es, por
supuesto, caminar
por la evaluación. Recorrer es lo principal, y si los usuarios tienen
bloqueadores en su pase, no
va a ser
bueno para el proyecto. Y el último ejemplo
es la verificación de conectividad, asegurándose de que
todos los jugadores puedan conectarse al servidor
y jugar juntos, asegurándose de que la gente pueda
jugar con sus amigos. ¿Bien? Avanzando. Y la técnica de
priorización basada en el tiempo es principalmente usar el tiempo
como base principal En palabras simples, estamos probando todas las características en función de nuestra línea de tiempo y cronograma de
desarrollo. Como tenemos nuestros criterios
para diferentes hitos y hemos planeado que las características se
desarrollen en los cronogramas, nos centramos principalmente en probar
características particulares para asegurarnos de que
el proyecto
aún esté en camino y que el proyecto
aún esté en camino y todas las características reciban
suficiente Los principales ejemplos
de Pickle Park son pruebas de
hitos ya que realizamos la validación al
final de cada hito El siguiente son las pruebas de
contenido de sprint, es decir, que para cada sprint, el
equipo de desarrollo tiene un plan de actividad que planean
implementar e integrar, y nosotros como equipo de QA
estamos asegurándonos de que todo salga de
acuerdo al plan. La última es la prueba de actividad del
codificador. A veces en el
proceso de desarrollo, diferentes personas
quieren asegurarse que algunas cosas
funcionen o quieren
tener una
construcción adicional para mostrarse en
algún lugar de alguna actividad de
promoción. Podrían pedirle a élite que pruebe algunas misiones
o áreas específicas del juego. Esto es solo una visión general aproximada de la priorización
y en la vida real, te enfrentarás a muchos escenarios en los que
necesitas tomar decisiones, qué probar y qué omitir Espero que esto pueda ayudarte a entender dónde
debes enfocarte primero.
28. Pruebas. Reunión de triage: Otra actividad importante que no siempre
está sucediendo en el proyecto es el proceso de arrastre de BC
y las reuniones de partes interesadas. ¿Qué es el triaje de errores en general? Es un proceso crucial
en el desarrollo que ayuda a priorizar y
gestionar los errores de manera eficiente Al asignar la
prioridad correcta a los errores, los equipos pueden garantizar
la entrega oportuna productos
de alta calidad
a las partes interesadas Veamos todos los
elementos del proceso. En primer lugar, tenemos que
probar el juego e identificar todos los errores
que nos interesan. Entonces el equipo se sienta unido, pasa por todos y cada uno de los
errores y establece la gravedad y decide el impacto de cada error para determinar
su prioridad. El equipo puede utilizar criterios de
hitos o cualquier otro tipo de criterio
dependiendo de la situación. Y como último paso, todas las bolsas de
basura se asignan al miembro de
la propiedad o al equipo en
función de su
severidad y prioridad. triarca BAC
influye significativamente en la calidad del producto, plazos de
lanzamiento y Priorizar y administrar errores manera efectiva a través del
proceso de clasificación contribuye a un
ciclo de desarrollo más suave y garantiza que los productos de alta calidad
se entreguen a tiempo al Sr. de
manera efectiva a través del
proceso de clasificación contribuye a
un
ciclo de desarrollo más suave y garantiza que
los productos de alta calidad
se entreguen a tiempo al Sr.
Expectation. BG Trias se realiza a través de una reunión de
partes interesadas Es una plataforma
para la toma de decisiones y alineación entre los grupos de interés
del proyecto. Estas reuniones
facilitan las discusiones sobre la priorización de errores, las estrategias de
resolución y el progreso general del proyecto, asegurando que las partes interesadas estén informadas e involucradas
en el manejo de errores Es importante involucrar a los actores
clave del proyecto,
como propietarios de proyectos, equipos de
desarrollo y representantes
comerciales. Al involucrar a las partes interesadas
en la discusión de arrastre posterior, equipo obtiene información valiosa, califica los requisitos y se
alinea en las prioridades. ¿Quiénes deberían estar presentes
en estas reuniones? Por lo general, son
propietarios de productos, gerentes de proyectos, desarrolladores, probadores y
otras partes interesadas relevantes Es líder de QE o gerente de
proyecto es el principal facilitador de estas reuniones Durante estas reuniones, se lleva a cabo un
proceso
colaborativo de toma de
decisiones para priorizar errores de manera eficiente y asignar recursos en
función de las necesidades del proyecto Las partes interesadas colaboran para
identificar problemas críticos, evaluar su impacto
en los objetivos del proyecto y
determinar colectivamente el mejor curso de acción para la resolución de errores. Este
enfoque colaborativo garantiza que la
decisión de secadores de errores se alinee con los objetivos
del proyecto y
las expectativas de las partes interesadas Palabras simples, si solo
se sientan juntos en la reunión, revisen la lista de la caja. Por ejemplo, tenemos
diez dólares y definimos cuáles son cruciales para ser
arreglados lo antes posible. Como resultado, estarás teniendo algo
así como cuatro dólares, prio
alto, tres dólares, prio
medio, tres
dólares, prio bajo Todas las personas principales
entienden qué
tratar primero y cuáles
son los siguientes pasos.
29. Pruebas. Entornos: Movamos un poco y
hablemos de entornos de software. Probablemente ya
sabes algo al respecto o
lo enfrentaste ya
en tu carrera, pero hablemos de
ello con más detalle. ¿Cuáles son los entornos? Son
configuraciones dedicadas que se utilizan para diferentes etapas del ciclo de vida de
desarrollo Estos entornos replican
la infraestructura y las configuraciones
necesarias para probar, validar e implementar
aplicaciones Pasemos por algunos de
los principales entornos que están presentes en el desarrollo de juegos. El primero es
el entorno de desarrollo donde ocurren la codificación y la
programación. Luego tenemos
entorno de pruebas para pruebas de
software y juegos
e identificación de errores. Luego tenemos un
entorno de puesta en escena para la
validación final antes del lanzamiento. Además, podemos tener
ambiente UAT donde
colocamos nuestro producto y dar acceso a
los usuarios para verificar
su experiencia Y claro, tenemos
producción o ambiente en vivo donde el usuario final
puede jugar el juego. Vamos a revisarlos con más detalle. Entonces, ¿cuál es el entorno de
desarrollo? Este entorno es
necesario para escribir código. Esta es la rama principal donde
los desarrolladores crean el juego. Entonces diferentes
desarrolladores integran su cambio para garantizar la
compatibilidad y funcionalidad. Además, somos capaces de probar diferentes componentes
en este entorno. De vez en cuando,
los desarrolladores ponen sus actualizaciones en la rama del entorno de
pruebas. Esto suele corresponderle a Quill para decidir con qué frecuencia hay que hacer las
actualizaciones Personalmente pedí a los desarrolladores que actualizaran el
entorno de pruebas dos veces por semana. ¿Cuál es el propósito principal? En primer lugar, hacemos pruebas
funcionales
en este entorno. Además, realizamos pruebas de
integración, y estamos tratando de
probarlo como usuarios finales. Después de que todas las pruebas se realicen
en el entorno de pruebas, empujamos las actualizaciones
al entorno de escenario. El entorno de puesta en escena
es crucial para validar todo antes de implementarlo en
el entorno vivo Se refleja la
configuración de producción y todas las partes interesadas para revisar y aprobar las actualizaciones
antes del lanzamiento. También algunos proyectos cuentan con ambiente de
pruebas de aceptación del
usuario. Este es un lugar donde el usuario final
o los representantes del cliente validan el juego contra los requisitos del
negocio
y los criterios de usabilidad. retroalimentación de UAT ayuda a
garantizar que el software se alinee con las expectativas del usuario
antes Y el último es el ambiente
de producción. Este es el
destino final de nuestro proyecto. Estos entornos
no aparecen de la nada y no son estándar
en todos los proyectos. El equipo de desarrollo, junto
con otros grupos de interés, necesitan configurarlos y
configurarlos adecuadamente. Requiere una cuidadosa planeación y consideración de los requisitos
del proyecto. Esto implica el aprovisionamiento recursos de
hardware y software, configuración de la red y la implementación de
las herramientas y aplicaciones necesarias. Administrar y mantener entornos de
software es un proceso continuo que requiere monitoreo
y mantenimiento
regulares. Esto incluye garantizar
la estabilidad y confiabilidad, garantizar la seguridad
de los entornos, rastrear los cambios y actualizaciones a través del control de versiones y la administración de la
configuración, y fomentar la
colaboración entre el QA de desarrollo y el equipo de
operaciones para una administración efectiva del
entorno. En la vida real, el proceso
es bastante sencillo. Tienes un entorno donde los desarrolladores producen el juego. Como élite Q, vienes
a ellos y les pides que empujen todo al ambiente
de pruebas. Después de eso, realiza pruebas
y reportes de errores principales. Cuando todo está hecho
y se corrijan todos los errores, el equipo empuja
todo al escenario entorno que replica el entorno de
producción tanto
como sea posible Cuando
termine la prueba ahí, solo
dices ir y
el juego se pone en marcha.
30. Pruebas. Actividades generales: Además de diferentes
reglas y eventos, tú como Q elite, también tienes que planificar diferentes actividades de
prueba
para tu equipo. Las actividades de prueba
abarcan una variedad de procesos realizados para validar la funcionalidad del
software, acceder al rendimiento y garantizar calidad durante todo el ciclo de vida del
desarrollo. Cada actividad de prueba tiene un propósito específico
para detectar defectos, mitigar riesgos y mejorar la experiencia general del usuario Exploremos las actividades de
pruebas K y su momento óptimo en
el proceso de desarrollo. Las pruebas funcionales
van más allá de simplemente verificar el software con los requisitos
especificados. Se profundiza en garantizar que la funcionalidad
central se alinee
con las expectativas del usuario, cubriendo la mecánica del juego, las interacciones y Se lleva a cabo durante las iteraciones de
desarrollo y antes versiones
principales para garantizar que la funcionalidad
central
cumpla con los requisitos Las pruebas funcionales en Pico Park implican controles intrincados de
la mecánica del juego, las interacciones
del usuario
y el progreso de nivel Más allá de verificar nuevos cambios, las pruebas de
regresión las funcionalidades
existentes de interrupciones
involuntarias Al verificar los errores corregidos
previamente y las características principales del juego, junto con probar la compatibilidad
con varios dispositivos, este proceso mantiene la integridad
del sistema y mejora la confiabilidad de la
experiencia del usuario. Se lleva a cabo después de cambios o actualizaciones de
código, incluidas correcciones de errores, mejoras de
funciones o actualizaciones del sistema
antes de las versiones principales. En el ciclo de desarrollo,
las pruebas de regresión no solo garantizan que los
nuevos cambios no afecten negativamente a las funcionalidades
existentes, sino que también validan
la estabilidad de las
características
principales del juego y la
compatibilidad de direcciones con
diferentes dispositivos Las pruebas de rendimiento evalúan la capacidad de respuesta,
estabilidad y escalabilidad del software bajo diversas condiciones, mostrando su confiabilidad
bajo Al simular escenarios como manejo
del wat del servidor y el rendimiento
multijugador, esta fase garantiza el funcionamiento
y escalabilidad óptimos del
sistema antes Por lo general, se realiza durante las últimas etapas de desarrollo para evaluar el rendimiento
y la escalabilidad del sistema antes de su lanzamiento A lo largo de las pruebas de rendimiento, Pico Park se somete a evaluaciones
rigurosas en varios en el manejo
y
el rendimiento multijugador para asegurar
una capacidad de respuesta óptima, estabilidad y escalabilidad
en diferentes Las pruebas de usabilidad
se centran en evaluar la facilidad de uso y la satisfacción
general del usuario. A través de la evaluación de
aspectos como el diseño QR, respuesta del
control
y la retroalimentación de los jugadores, esta fase tiene como objetivo optimizar
la interfaz del software para una experiencia de usuario intuitiva y
satisfactoria Se realiza durante las
últimas etapas de desarrollo. Las pruebas de visibilidad en Pico Park implican una evaluación en profundidad del diseño de la interfaz
de usuario, respuesta
del control
y la retroalimentación de los jugadores Las pruebas de seguridad tienen como objetivo
identificar vulnerabilidades,
debilidades y posibles amenazas de seguridad
dentro del software para salvaguardar los datos confidenciales y
evitar el acceso no autorizado. Se lleva a cabo a lo largo del
ciclo de vida del desarrollo con un enfoque en la identificación
temprana de vulnerabilidades y evaluaciones continuas
de seguridad. Las pruebas de compatibilidad
verifican que el software funciona correctamente en diferentes dispositivos, navegadores y plataformas para ofrecer una experiencia de
usuario consistente Se realiza durante las
últimas etapas de desarrollo. En Pico Park, las pruebas de
compatibilidad implican pruebas en
varios sistemas operativos, dispositivos, resolución de pantalla
y configuraciones de red. Y luego las pruebas
exploratorias. Implica técnicas de
prueba ad hoc para explorar la
funcionalidad del software, descubrir defectos y acceder a
problemas de usabilidad en tiempo real Se lleva a cabo durante todo el ciclo de vida del desarrollo con un enfoque en la detección temprana de
defectos y la mejora continua.
31. Gestión de riesgos: Importante área de responsabilidad para Kid es la gestión de riesgos. Profundicemos
en este asunto. En primer lugar, necesitamos
entender cuál es el riesgo. El riesgo es un evento o
circunstancias potenciales que pueden
afectar los objetivos del proyecto. Entonces, ¿qué es la gestión de riesgos? En primer lugar, necesitamos
identificar los riesgos. Implica reconocer los riesgos
potenciales que podrían afectar los objetivos del proyecto. Entonces necesitamos evaluar el riesgo. Significa que necesitamos
evaluar la semejanza e impacto del riesgo identificado a través
de análisis de
calidad y
cuantitativo El siguiente paso es la mitigación de
riesgos. Significa que necesitamos
implementar estrategias para reducir el impacto de los riesgos en los resultados
del proyecto
para asegurar el éxito. Y el último paso es el monitoreo
continuo. Es una supervivencia continua
para rastrear y gestionar los riesgos de manera efectiva a lo largo
del ciclo de vida del proyecto. manejo efectivo del riesgo comienza con la identificación del riesgo de dolor Técnicas como la
lluvia de ideas, las revisiones y análisis de
datos ayudan a
descubrir riesgos potenciales En los proyectos,
los riesgos potenciales incluyen limitaciones de
recursos,
que afectan los plazos de los proyectos, cambios de
alcance que conducen
a requisitos, ambigüedades y dependencias
tecnológicas limitaciones de
recursos,
que afectan los plazos de los proyectos, cambios de
alcance que conducen
a requisitos,
ambigüedades y dependencias
tecnológicas que afectan la entrega del proyecto. Reconocer estos riesgos de manera temprana permite estrategias efectivas
de gestión de riesgos. Después pasamos a la evaluación de riesgos. Realizar una evaluación de riesgos
es crucial para comprender el impacto potencial del riesgo
identificado en los objetivos
del proyecto. Métodos como el análisis cualitativo
y cuantitativo ayudan a evaluar los riesgos en función de
su semejanza y gravedad análisis de calidad
evalúa subjetivamente la probabilidad y el impacto del
riesgo, mientras que el
análisis cuantitativo proporciona un enfoque más impulsado por los datos estimar las probabilidades Cuando tenemos todos los riesgos
identificados y evaluados, ahora es el momento de
elegir la estrategia. Estos son los principales
tipos de estrategia. El primero es la evitación, es
decir, que estamos
tratando de evitar el riesgo por completo, pero no participando en las
actividades que poseen el riesgo ejemplo principal aquí es que
es posible que no queramos agregar una nueva característica si no tenemos
tiempo suficiente para probarla, y podría contener box. Por lo que es mejor no
agregar la función, evitar el riesgo de tener problemas
adicionales. Otra es la reducción. Significa implementar
medidas para disminuir la semejanza
o impacto del riesgo El siguiente es la transferencia, trasladando el riesgo
a otra parte, como por ejemplo a través de seguros
o externalización. El mismo ejemplo va aquí. Si no tenemos
tiempo suficiente para probar la función, tal vez deberíamos contratar un
equipo adicional para realizar las pruebas. Y la última es la aceptación, cuando elegimos
aceptar el riesgo y sus posibles consecuencias sin tomar acciones específicas. Además de la gestión de riesgos, necesitamos entender
la diferencia entre los riesgos del proyecto y los riesgos del producto porque
entender la distinción entre ellos es crucial para una gestión efectiva del
riesgo. Los riesgos del proyecto son factores que pueden afectar la finalización
exitosa de un proyecto, mientras que el riesgo del producto está relacionado con problemas
que afectan la calidad, funcionalidad o usabilidad
del producto pino. Echemos un vistazo más profundo
a los riesgos del proyecto. El primero son los retrasos programados. Se trata de un posible retraso en el cronograma del proyecto,
impactando la finalización general Entonces sobrecostos presupuestales, es decir, rebasar el presupuesto asignado dando lugar a tensiones financieras Entonces tenemos
limitaciones de recursos cuando tenemos disponibilidad
limitada de personal o material
que afecta el progreso del proyecto. El siguiente son los riesgos de alcance
cuando los requisitos del proyecto se extienden más allá del alcance inicial debido a las expectativas cambiantes de las
partes interesadas. Y el último son los factores
externos que son influencias externas al control de los equipos del proyecto
impactando los resultados Ahora,
hablemos de los riesgos del producto. El primero son los problemas de
funcionalidad. Son las principales
preocupaciones relacionadas con
las funciones y características centrales del producto. Entonces son
desafíos de usabilidad que son dificultades para usar el producto de manera efectiva
e intuitiva El siguiente son los cuellos de botella de
rendimiento. Hay otros problemas obstaculizan el
bit y la eficiencia de los productos Y la última son las vulnerabilidades de
seguridad, las amenazas a la
protección de datos del producto y la privacidad del usuario. Ahora implementemos un pequeño rastreador de
riesgos para nuestro proyecto.
32. Gestión de riesgos. Registro de riesgos.: Crear registro de riesgos para nuestro proyecto. Para este, volvemos
a nuestro Excel y comenzamos
con los campos principales. El primero es el ID de riesgo
porque cada riesgo necesita tener su propio identificador
único. Entonces tenemos resumen de riesgo
o descripción del riesgo. Queremos saber si se trata de un riesgo de
producto o de proyecto. Entonces tenemos categoría de riesgo, entonces queremos tener
impacto del riesgo, como whoood y severidad Después de esto, debemos elegir el tipo de mitigación y la estrategia de
mitigación. Y lo principal que también
queremos
saber es un
plan de contingencia, propietario y estado Estas son nuestras principales
categorías que necesitaríamos
tener para cada disco. Imaginemos algunos riesgos
diferentes que basamos en nuestra experiencia, prevemos que puedan
suceder en nuestro proyecto Entonces riesgo 001, riesgo 002. El primero y algo que pasa
casi todo el tiempo, eso es un problema
con el multijugador. Imaginemos que
nuestro multijugador
no canta correctamente con los
ocho jugadores de la sesión. Entonces otra
área problemática es la compatibilidad. Así que imaginemos que nuestra interfaz de usuario del juego no funciona
correctamente en dispositivos móviles. Agreguemos un poco de riesgo de desempeño. Entonces imaginemos
que tal vez no tengamos suficientes personas en nuestra
compañía para probar el juego. Y escojamos el peor. Y esto también es algo
que suele suceder. Se trata de retrasos en la implementación vocalización para
diferentes idiomas. Esta es solo una lista básica de
cosas que me vienen a la mente. Por lo general, cuando comienza el
proyecto, tú como Eelite clave te sientas y piensas en todos los posibles
riesgos que puedan ocurrir A veces haces un
término de sucursal con el equipo, tal vez con los stakeholders. Por lo general, depende de la
escala del proyecto. Entonces vamos a llenar la
información para cada riesgo. Categoría de riesgo. Si se trata de la funcionalidad
multijugador, esto es riesgo del producto. Impacto. Siempre. Si se trata de algo de jugabilidad y multijugador, es de alto impacto. Whood de que suceda. Por lo general, depende de la
experiencia del equipo. Imaginemos que
tenemos bastante buen equipo. Entonces esto es una semejanza media. Oh severidad. La gravedad es crítica. Entonces tipo de mitigación y estrategia
de mitigación. No podemos evitar este riesgo porque necesitamos la funcionalidad
multijugador, y no podemos ignorarla ni
transferirla a otra persona. Todo lo que podemos hacer es reducir la
probabilidad o el impacto. ¿Qué podemos hacer? Podemos realizar pruebas de estrés multijugador
tempranas y también podemos garantizar estabilidad
del servidor
con jugadores simulados. Si nada funciona, todo lo que podemos proponer es retrasar el
lanzamiento multijugador si es necesario, o limitar temporalmente el
tamaño de la sesión. El propietario será QA Elite, ya que será la
persona principal para conocer sobre este riesgo y tener todos los
datos a la brevedad posible. Estado, mantengámoslo abierto, y pasemos a otro riesgo. Juego I escalando incorrectamente
en la versión móvil. Esto también es riesgo del producto. No tiene un impacto tan alto, así que vamos con el medio. Al igual que la capucha es bastante alta
según mi experiencia, y la severidad
también es bastante alta. Para el tipo de mitigación,
esta es la misma historia. Vamos con la reducción y
pensamos en la estrategia de mitigación. Lo principal aquí
es tratar de cubrir tantos dispositivos
como
sea posible en etapas tempranas. Entonces lo que tenemos que hacer es
probarlo en diferentes dispositivos. Además, podemos utilizar simuladores para simular todas las
combinaciones posibles de teléfonos Para plan de contingencia,
esto es bastante lo mismo. Podemos retrasar la liberación móvil. El propietario es muy probable que la interfaz de usuario
deje que necesite pensar diferentes formas de reescalar
la interfaz de usuario y el estado abierto Pasemos a caídas decentes de FPS. También el impacto del riesgo del producto es alto porque el rendimiento siempre
es alto. Las TIC son medianas y la
gravedad es crítica. Mismo tipo de mitigación, y pensemos en la estrategia de
mitigación. La mejor
estrategia de mitigación es optimizar los gráficos y diseñar bien
para que sea menos intenso. Plan de contingencia es reducir los efectos
visuales o texturas
para baja y dispositivos La persona responsable es desarrollador principal
o líder tecnológico, y el estado también es abierto. El equipo de pruebas no puede
cumplir con los plazos de prueba. Esto es riesgo de proyecto. El impacto es medio, la
HD también es media y la gravedad también es media. tipo de mitigación de reducción no va a ayudar aquí, así que vamos a utilizar la transferencia. Si no vamos a poder
cumplir con los plazos, vamos a pedir servicios de pruebas de
terceros. Para el plan de contingencia,
necesitamos priorizar las actividades
principales de nuestro equipo y dar el resto
al equipo de subcontratación Incluso debido a
que todo necesita ser administrado por Q Elite, en JIF, esto depende del
gerente de proyecto para conseguir este equipo adicional
y mitigar este riesgo Y es lema nuestro riesgo final, retrasos en la implementación de la localización para
diferentes idiomas. Esto también es el
riesgo de proyecto que el impacto es alto, ya que algunas personas podrían
no ser capaces de jugar el juego sin su idioma
preferido. ¿Por qué quién tú? ¿Y bien? Porque
usualmente subcontratamos todos los idiomas a una misma gente y ellos preparan
todos los idiomas, pero a lo mejor sucedió algo
y no tienen el idioma específico
y severo es medio Para el tipo de mitigación, necesitamos
evitar este riesgo
lo antes posible. Para la estrategia, necesitamos
comenzar la localización lo antes posible o contratar socios de
localización adicionales. Para el
plan de contingencia, es posible que queramos el juego en idioma primario primero
el juego en idioma primario y agregar
otro post lanzamiento Y el dueño de este riesgo
es el plomo de vocalización. Por ejemplo,
éste esté en progreso. Por lo que esta es la idea principal de nuestras estrategias de
mitigación de riesgos y riesgos. Hagámoslo un poco
más hermoso. Bueno. Ahora tenemos todas las cosas resaltadas en
rojo que son altas, y esta es nuestra lista básica de los
riesgos del proyecto. ¿Vamos a movernos?
33. Equipo de QA. Comunicación: Pasando a la parte
de comunicación. A veces, pienso
que la comunicación es algo que entrenas a
lo largo de toda tu vida. Pero aún así, hay
algunas técnicas que
puedes usar para mejorar la
colaboración dentro de tu equipo. comunicación efectiva
dentro del equipo de QA es fundamental para el
éxito de los procesos de QA, facilitando el
reporte de errores, la planificación de muertes y el intercambio de nodos
entre los miembros del equipo. Al fomentar canales de
comunicación claros y promover la colaboración, los equipos pueden garantizar la productividad, reducir los malentendidos
y lograr los objetivos del proyecto La comunicación efectiva conduce a una mejor colaboración,
reduce los malentendidos y mejora la productividad
dentro del equipo de control de calidad, contribuyendo
finalmente
al éxito del proyecto de aseguramiento
de la calidad Hay algunos momentos
clave para fomentar una comunicación clara, como el establecimiento de reuniones de
regularidad, definición de canales de comunicación y las prácticas de presentación de
informes transparentes Aquí hay algunos ejemplos de prácticas de comunicación
claras. El primero es ponerse de pie. Se trata de una breve reunión diaria para alinearnos en las tareas y
abordar temas. Si estás en la oficina,
puedes reunir al equipo a tu alrededor, tomar una taza de café y simplemente discutir todas
las cosas principales. También se puede hacer
a través de reuniones en línea. Otro tipo de reunión
son las retrospectivas. Se trata de una
revisión periódica para reflexionar sobre los avances e identificar
mejoras. Además, puedes realizar revisiones
por pares. Se trata de una sesión de retroalimentación para mejorar la calidad
y la colaboración. colaboración y el uso compartido de
nodos dentro del QATM son vitales
para maximizar eficiencia y mantener los estándares de
calidad durante todo el ciclo de vida del
proyecto Echemos un vistazo a
algunos ejemplos de cómo fomentar el trabajo en equipo
para entregables de calidad Puedes intentar usar pruebas de pares. Es un método de
prueba colaborativo que involucra a dos y más probadores que
trabajan juntos para mejorar la
eficiencia y la calidad de las pruebas Diferentes personas pueden tener diferentes opiniones sobre
la forma de probar la misma característica, así
como trabajar junto con alguien podría traer
más alegría a su trabajo. Puedes configurar sesiones de
intercambio de conocimientos en tu equipo. Se trata de sesiones interactivas donde los miembros
del equipo comparten
su experiencia, mejores prácticas y conocimientos para mejorar los
conocimientos y habilidades del equipo. Y además, no te olvides la innovación al promover la
creatividad y las ideas
novedosas dentro
del equipo para impulsar mejora
continua
y soluciones únicas. Hablemos de otro tipo de comunicación que no
incluye hablar real. Es una transparencia en los informes de
errores porque los informes transparentes de errores
son cruciales dentro del equipo de control de calidad para el seguimiento
efectivo de los problemas, priorización de las correcciones y el
mantenimiento de la visibilidad del estado del proyecto Los principales elementos del
reporte
transparente de errores son palabras clave, resumen
claro, descripciones detalladas de
errores, paso
claro para reproducir y actualizaciones oportunas
sobre el estado de los errores. Al seguir estas prácticas, puedes brindar más
colaboración dentro del equipo y asegurarte de que todos entiendan la situación
actual del proyecto. También K lead está incluido en muchas
otras conversaciones diferentes. Echemos un
vistazo a algunos ejemplos. Estarás hablando mucho con
el equipo de desarrollo. Es necesario mantener una comunicación
regular con el equipo de desarrollo para comprender el estado
del desarrollo continuo, los cambios
futuros y las
posibles áreas de riesgo. Klits colabora estrechamente
con los desarrolladores para garantizar que los esfuerzos de prueba
se alineen con plazos
y prioridades de
desarrollo Entonces estarás platicando
mucho con la gerencia de producto. Necesita obtener información sobre
los requisitos del proyecto, las historias de los
usuarios y las prioridades de las
funciones. Q Et participa en sesiones de
recopilación de requisitos, aclara ambigüedades
en los requisitos y asegura que los esfuerzos de prueba cubran
adecuadamente todos los
aspectos del producto Entonces, por supuesto, estarás interactuando con
otros miembros de QT. Estarás brindando orientación, apoyo y tutoría
a otros miembros de QAT Coordinarás actividades de
pruebas, distribución de tareas y
revisarás tpan y casos de prueba Luego, K Elites se comunica
con las partes interesadas del proyecto, incluidos
los gerentes de proyectos, clientes y analistas de negocios para proporcionar actualizaciones sobre el progreso de las
pruebas, informar defectos y problemas, y abordar cualquier inquietud o pregunta relacionada con el aseguramiento de la
calidad Y en caso de que proveedores o
contratistas
externos estén involucrados
en actividades de prueba, K Elite sirve como punto de contacto
principal. Coordinan los esfuerzos de prueba, proporcionan las pautas de
documentación necesarias y aseguran que los equipos externos cumplan con los estándares
y requisitos del proyecto. Echemos un vistazo a las estrategias de
casos para mejorar la comunicación
dentro de un equipo de proyecto. Asegúrese de programar reuniones
periódicas con las partes interesadas del
caso para discutir estado
potencial,
las prioridades y las preocupaciones. Puedes preguntarles
con qué frecuencia quieren escuchar
sobre estas actualizaciones. Utilice
documentación clara y concisa para comunicar planes de pruebas, casos de
prueba, informes de defectos y otra información relevante. Esto asegura que todos los
interesados tengan acceso a la información
esencial y puedan mantenerse informados sobre
el progreso del proyecto. Escuche activamente las
inquietudes, comentarios y sugerencias de
los miembros del equipo y las partes interesadas. Al escuchar atentamente, los
clientes potenciales de K pueden
comprender mejor las necesidades y perspectivas de
los demás y abordar cualquier problema o
desafío de manera efectiva Mantener la transparencia al
informar el progreso de las pruebas, defectos y métricas de calidad, proporcionar actualizaciones e
informes periódicos a las partes interesadas, destacando logros, desafíos y áreas
de mejora. Con
herramientas y plataformas colaborativas
como software de gestión de proyectos, sistema de seguimiento de
problemas y
canales de comunicación para facilitar la
comunicación y
colaboración entre los miembros
del equipo y las partes interesadas Y establecer mecanismo do para
fomentar la comunicación abierta
y la mejora continua. Alentar a los miembros del equipo
y a las partes interesadas a proporcionar comentarios sobre
los procesos,
el flujo y
las prácticas de comunicación, y tomar medidas para abordar cualquier problema
o sugerencia planteada. Por supuesto, esto es
solo una breve descripción de las principales
estrategias de comunicación. Solo asegúrate amable y educado en
tu estilo de comunicación, y podrás resolver
cualquier problema que surja
34. Equipo de QA. Composición: El siguiente tema es la
composición y administración efectiva de atm. Comprobemos los detalles. Efectivo en la composición es crucial para garantizar la calidad
en el desarrollo del juego. roles clave como
los evaluadores y analistas de QUALD, así
como las habilidades esenciales en el dominio
técnico
y el conocimiento del dominio juegan un papel vital en el
éxito del proyecto Pasemos por los roles
clave en el equipo de QA. El primero es el líder de QA. Las características principales son fuertes habilidades de liderazgo y
comunicación, amplia experiencia en
metodologías y prácticas de QA, y capacidad para priorizar tareas y administrar
recursos de manera efectiva Entonces nos estamos moviendo a los probadores de QA. Sus principales responsabilidades
son ejecutar casos de
prueba y escenarios para
identificar y reportar defectos, realizar
pruebas de regresión y verificar correcciones de errores y proporcionar
comentarios sobre las características del juego, usabilidad y la calidad general. Entonces podríamos tener ingeniero
de automatización. Son capaces
de desarrollar y mantener scripts de
prueba automatizados, integrar
pruebas automatizadas en la canalización e identificar
oportunidades para probar la
automatización para mejorar la
eficiencia y la cobertura de las pruebas. Y el último pero no
menos importante K Analyst, y está a cargo de analizar las métricas de rendimiento del
juego y comentarios de los
jugadores para identificar
áreas de mejora, colaborar con desarrolladores
y diseñadores para abordar temas relacionados con la
calidad y contribuir a la estrategia de
planificación de pruebas, y documentación. posición y
las responsabilidades claras dentro
del equipo de control de calidad son vitales para la
rendición de cuentas y la eficiencia. Cada función contribuye de manera única a la planificación de pruebas, ejecución, automatización y análisis de
rendimiento, mejorando el proceso general de aseguramiento de la
calidad. Como élite Q, es necesario tener una definición clara de la
antigüedad en el equipo En primer lugar, porque necesitas
saber a quién contratar en tu equipo, y luego necesitas tener un
plan de desarrollo claro para tu equipo. Veamos las principales
diferencias en la antigüedad. Pruebas KA Senior. principales responsabilidades
son liderar los esfuerzos de
pruebas para
características y componentes específicos, asesorar a los evaluadores junior
y brindar orientación, y ayudar al QED en la planificación de
pruebas y ¿Cuál es la expectativa? Varios años de experiencia
en roles de pruebas de control de calidad, sólidos conocimientos de
metodologías de prueba y
mejores prácticas, y habilidades comprobadas
para probar esfuerzos. Pasemos al probador de QA de
nivel medio. principales responsabilidades
son ejecutar casos de
prueba y escenarios
para identificar defectos, realizar
pruebas de regresión y verificar correcciones de errores y proporcionar
comentarios sobre las características del juego, usabilidad y la calidad general. ¿Qué esperas
de su antigüedad? 2-5 años de experiencia
en roles de pruebas de control de calidad, competencia en
metodologías y herramientas de prueba,
y capacidad para trabajar forma independiente y colaborativa con
un Y Probador Junior. principales responsabilidades son
ayudar en la ejecución de textos, verificación de
bu
y la documentación, luego aprender los procesos,
metodologías y herramientas de KA, y luego brindar apoyo y contribución a los esfuerzos generales de
prueba. No esperamos mucho de antigüedad porque el probador
Junior K es un
puesto de nivel de entrada adecuado para individuos con experiencia
limitada en K y pruebas de crecimiento Comprensión básica de los principios de pruebas de
software y entusiasmo y crecimiento en el campo y una fuerte
atención al detalle y un recorrido por el vidrio
dispuesto Echemos un vistazo rápido al ingeniero de automatización y
sus responsabilidades. En primer lugar, es
responsable de desarrollar y mantener scripts de
prueba automatizados para garantizar un proceso de
prueba eficiente. Luego está integrando pruebas
automatizadas en integración
continua, canalizaciones de desarrollo
continuo
para pruebas sin problemas y también identificando e
implementando oportunidades para automatización de
pruebas para mejorar la eficiencia
y efectividad de
las pruebas. Ahora echemos un
vistazo a QA Analysts. Esta es una posición bastante rara, pero aún así necesitamos tener un
conocimiento sobre sus fundamentos. Esta posición se
encarga de analizar las métricas de
desempeño para identificar áreas de mejora
y optimización. Entonces K Analysts colabora manera efectiva con otros equipos para
garantizar la alineación con los estándares de calidad y las estrategias
de prueba También contribuye a la
planificación de pruebas desarrollando casos de
prueba, escenarios y estrategias
para una cobertura integral. Y luego una de
las responsabilidades es crear y mantener documentación
detallada
para casos de prueba, resultados y procesos para procesos de
referencia y auditoría. Además de los
puestos mencionados, hay otros equipos especializados que podrían ser utilizados en el proyecto. Tomemos una breve descripción de
varios roles de prueba
dentro de un Qateam El probador de
seguridad realiza evaluaciones de seguridad y pruebas de
penetración, identifica vulbilidades
y colabora con desarrolladores para mejorar la seguridad del
software comprobador de rendimiento
diseña y ejecuta pruebas de
rendimiento para
evaluar la capacidad de los sistemas, identifica cuellos de botella
y recomienda estrategias de optimización y probador de localización valida pruebas de
precisión de contenido
traducido para temas de soporte
lingüístico
y colabora con el equipo de
vocalización para El probador de accesibilidad garantiza el
cumplimiento de la accesibilidad del software, realiza pruebas de usabilidad con tecnologías de
asistencia
y aboga
por prácticas de diseño inclusivo El probador de usabilidad realiza estudios de
seguridad, recopila comentarios útiles
para mejoras y colabora
con el equipo de diseño para mejorar la experiencia del usuario Y el comprobador de cumplimiento garantiza el cumplimiento del
software con las regulaciones
y estándares de la
industria, documenta los hallazgos que cumplen y prepara
presentaciones de regulaciones, colabora
constantemente
con los asuntos regulatorios y los equipos G para abordar los problemas de
cumplimiento Ahora, vamos a crear
una composición de equipo para nuestro proyecto Pickup Park.
35. Equipo de QA. Creación de composición: General, el proyecto no
es tan grande,
así que no necesitamos mucha gente para estar presentes en el proyecto. Podemos volver a Twine y ver nuestro planificador básico de
recursos Por lo que esperábamos tener 600 horas y tener dos recursos. Entonces podemos comenzar
con esta copiarlo, crear algún formato básico. Recurso uno y recurso dos. Sólo tenemos que definir la
antigüedad de estos recursos. Hay dos formas de cómo podemos crear esta composición de
equipo. Así que vamos a crear la variante
uno y la variante dos. En nuestra primera variante, tenemos QA lid que no
está trabajando a
tiempo completo en este proyecto, sino que solo se encarga
de cómo va todo. Así que ponemos aquí QA
lead a tiempo parcial. En este caso, el recurso uno que inicia primero puede ser posición
media. Y recurso para
eso comienza más tarde. Él solo se une a ayuda con las pruebas así que no
necesitamos otro medio. Podemos ayudar a QA junior. No conozco mucho apoyo. Entonces este será
nuestro plan principal para esto Entonces imaginemos que no tenemos
Q LED en el equipo. En este caso,
podemos tener Senior K que cubra parcialmente las responsabilidades
QLED Y luego también solo
agregamos otro Junior QA. Para apoyar a senior
con todo. Estas son dos variantes
que podrían funcionar bien. Primera variante, tenemos K led que realiza supervisión y probador K
medio que realiza la mayor parte del trabajo con
el apoyo del junior. En nuestra segunda variante, tenemos Senior KA que cubre mucha parte
organizacional de
Kleid realiza la mayor parte de las pruebas y cuenta con
Junior K como soporte Entonces podríamos tener posiciones
opcionales que funcionarán para ambos, como vocalización, testing, tester y performance tester Podemos invitarlos a realizar pases
rápidos en las
etapas finales de nuestro proyecto. Como el proyecto lleva
solo unos meses, no
necesitamos un
probador de automatización porque crear pruebas
automatizadas
puede llevar mucho tiempo y no vamos a ser
beneficiosos de ello, así
como no necesitamos QANOS que los requisitos
no son
tan complicados Hagamos un formateo rápido. Esta es una composición bastante
simple para un proyecto bastante simple.
36. Equipo de QA. Compromiso: Siempre fue especial para mí
como élite para asegurarse que la gente en el equipo
no solo esté haciendo el trabajo esperado, sino que también tenga la sensación de
que su trabajo es apreciado en el
equipo y están en el buen ambiente y
tienen buena gente a su alrededor que
los apoya
y ayuda con todo. En el aseguramiento de la calidad
y en todos los demás equipos, gestión
efectiva de las personas es vital para garantizar entregables de alta
calidad, mantener la moral del equipo y fomentar una cultura de mejora
continua Hay muchas
teorías diferentes del compromiso, pero me gusta apegarme a este modelo de compromiso de
seis pilares que me ayudó
mucho en mi carrera, empoderamiento, prestar
reconocimiento, atención, desafío, desarrollo y
compartir el panorama general. Echemos un
vistazo a cada uno de ellos. empoderamiento en la gestión de personas implica proporcionar autonomía, autoridad y recursos
para que los empleados tomen
decisiones y se
apropien de su trabajo. Empoderar a los miembros del equipo conduce a una
mayor satisfacción laboral, mayores niveles de motivación y una mayor productividad, ya
que se sienten valorados, confiables y capaces de contribuir de manera efectiva al éxito de la
organización. El reconocimiento efectivo es esencial para la satisfacción
y motivación de los empleados. Reconocer la
contribución de los empleados impulsa la moral y fomenta la excelencia
continua reconocimiento justo y consistente refuerza una cultura laboral positiva y
mejora el compromiso de los empleados El reconocimiento significativo implica retroalimentación regular, reconocimiento
público
y recompensas tangibles La implementación de diversas estrategias de
reconocimiento
crea una cultura de apreciación e impulsa el rendimiento y la lealtad del
equipo. La atención consiste en
escuchar activamente a los miembros de nuestro equipo, comprender sus necesidades y
abordar sus preocupaciones. Al mostrar un
cuidado e interés genuinos, podemos construir confianza,
fortalecer las relaciones y promover un ambiente de
trabajo solidario. Al escuchar activamente,
mostrar empatía y mantener una comunicación
regular, los gerentes pueden
demostrar cuidado y comprensión para las necesidades,
preocupaciones y comentarios de
los empleados ,
preocupaciones y comentarios escucha activa, la empatía y las comunicaciones
regulares son prácticas
clave para construir relaciones
sólidas y
promover el compromiso de los empleados El desafío consiste en
brindar a los miembros
de nuestro equipo oportunidades para
crecer, aprender y sobresalir. Cuando los empleados se dedican a un trabajo desafiante que se alinea con sus habilidades e interés, es más probable
que se
mantengan motivados, innoven y
comprometidos con sus roles asignaciones de
trabajo cambiantes y significativas empujan a
los empleados a expandir sus
habilidades y capacidades, fomentando el crecimiento personal y
profesional. Proporcionar tareas de
trabajo desafiantes no solo estimula el desarrollo de
los empleados, sino que también ayuda a retener a los mejores talentos. El desarrollo se
trata de invertir en el éxito a largo plazo y el crecimiento profesional de los miembros de
nuestro equipo. Al brindar oportunidades
de aprendizaje, desarrollo de habilidades
y avance, podemos mejorar compromiso, la
retención y la satisfacción de los
empleados. Echemos un vistazo a algunas de
las formas de desarrollo de los empleados. En primer lugar, es la capacitación, inversión en programas de
capacitación de empleados potenció las habilidades y conocimientos. Proporcionar tutoría,
cultiva la relación
y orienta la progresión de la carrera Crear oportunidades
para el avance profesional motiva a los empleados a sobresalir desarrollo de planes de
desarrollo individuales adapta las estrategias de crecimiento
a cada empleado Compartir el panorama general consiste conectar el trabajo
diario a los miembros de
nuestro equipo con la misión y visión más amplias de la
organización. Cuando los empleados entienden cómo su contribución impacta las metas
y objetivos generales, están más
comprometidos, motivados y alineados con la dirección de la
empresa. Y recuerda, si tu
equipo está bien comprometido, cada proyecto
será exitoso.
37. El final: Así que terminamos todo lo
que se planeó. Quiero darles las gracias por
todos los que se quedaron aquí
conmigo y decir que pueden contactarme donde quiera, por
ejemplo, en Linkin Si tienes algunas
otras preguntas o aclaraciones o los comentarios Sé que mi voz
no es la mejor para hacer cursos y trato de que
suene lo más queer posible. Entonces quiero pedir perdón si no fue lo
suficientemente queer para ti. Traté de mostrarte ejemplos
de todos mis conocimientos que
solía reunir en
diferentes empresas de empresa a empresa. Hay diferentes necesidades
y las formas en
que haces tu trabajo. Así que trato de traer todo mejor de todos los lugares por los que
he pasado. Lo que quería decir es que la
práctica hace que todo sea mejor. Así que no dudes en
conseguir cualquier juego y
tratar de hacer lo mismo. Crea plan de pruebas,
para crear planeación, estructura
EDT porque nadie
es perfecto desde el principio, y necesitas seguir tratando de llegar al
lugar donde quieres En general, la posición de Ted es bastante interesante
e inspiradora. Tú estás a cargo de la
calidad del juego, y eres la persona
para asegurarte de que todo
el equipo tenga una comprensión y
visibilidad completas donde está el juego. Y, por supuesto, no olvides
ser un ejemplo para tu equipo. Tú eres su mentor,
tú eres su gerente, para asegurarse de que se sientan
cómodos, inspirados y comprometidos. Te deseo suerte en
todos tus viajes, y espero que vayas a lograr lo que te
mereces. Nos vemos.
Руслан Мурга
