¡Hola a todos! Mi nombre es Yulia y soy tester. El año pasado te hablé de Bagodelnya - un evento realizado en nuestra empresa para eliminar la acumulación de errores. Esta es una opción completamente viable para reducirlo significativamente (del 10 al 50% en diferentes equipos) en tan solo un día.

Hoy quiero hablarles sobre nuestro formato Bagodelny de primavera: BUgHunting (BUg). Esta vez no solucionamos errores antiguos, sino que buscamos otros nuevos y propusimos ideas para funciones. Debajo del corte hay muchos detalles sobre la organización de dichos eventos, nuestros resultados y los comentarios de los participantes.

Habiendo pensado y redactado la normativa, enviamos una invitación a todos los canales de Slack corporativo, que no contenía ninguna restricción:

Como resultado, se inscribieron unas 30 personas, tanto desarrolladores como especialistas no técnicos. Reservamos un día de trabajo completo para el evento, reservamos una gran sala de reuniones y organizamos almuerzos en el comedor de la oficina.

¿Por qué?

Parecería que cada equipo prueba su funcionalidad. Los usuarios nos informan de errores. ¿Por qué incluso celebrar un evento así?

Teníamos varios goles.

1. Presentar a los chicos más cerca de proyectos/productos relacionados..
   Ahora en nuestra empresa todos trabajan en equipos separados: unidades. Estos son equipos de proyecto que trabajan en su propia parte de la funcionalidad y no siempre están plenamente conscientes de lo que sucede en otros proyectos.
2. Simplemente presente a sus colegas.
   En nuestra oficina de Moscú tenemos casi 800 empleados; no todos los compañeros se conocen de vista.
3. Mejorar la capacidad de los desarrolladores para encontrar errores en sus productos..
   Ahora estamos promoviendo Agile Testing y capacitando a muchachos en esta dirección.
4. Involucrar a más que solo especialistas técnicos en las pruebas.
   Además del departamento técnico, tenemos muchos compañeros de otras especialidades que querían hablar más sobre testing, sobre cómo reportar correctamente un error para que recibamos menos mensajes del tipo “Ahhh… nada funciona”.
5. Y, por supuesto, encontrar errores difíciles y no obvios..
   Quería ayudar a los equipos a probar nuevas funciones y darles la oportunidad de ver la funcionalidad implementada desde un ángulo diferente.

implementación

Nuestra jornada constaba de varios bloques:

• instrucciones;
• una breve conferencia sobre pruebas, en la que tocamos sólo los puntos principales (objetivos y principios de las pruebas, etc.);
• sección sobre “reglas de buenos modales” al introducir errores (aquí los principios están bien descritos);
• cuatro sesiones de prueba para proyectos con escenarios descritos de alto nivel; antes de cada sesión hubo una breve charla introductoria sobre el proyecto y la división en equipos;
• breve encuesta sobre el evento;
• resumiendo.

(Tampoco nos olvidamos de los descansos entre sesiones y el almuerzo).

Normas fundamentales

• La inscripción a eventos es individual., lo que soluciona el problema de que todo el equipo se agote por inercia si una persona decide no ir.
• Los participantes cambian de equipo en cada sesión.. Esto permite a los participantes entrar y salir en cualquier momento, y también puedes conocer a más personas.
• Equipos dos personas antes de cada sesión se forman al azar, esto lo hace más dinámico y rápido.
• Por errores introducidos se le otorga puntos (de 3 a 10) dependiendo de la criticidad.
• No se otorgan puntos por duplicados.
• Los errores deben ser archivados por un miembro del equipo de acuerdo con todos los estándares internos.
• Las solicitudes de funciones se crean en una tarea separada y participan en una nominación separada.
• El equipo de auditoría supervisa el cumplimiento de todas las normas.

Otros detalles

• Inicialmente, quería hacer un evento de prueba "avanzado", pero... Se inscribieron muchos chicos de equipos que no son de productos (SMM, abogados, relaciones públicas), tuvimos que simplificar enormemente el contenido y eliminar casos complejos/de perfil.
• Debido al trabajo de las unidades en Jira en diferentes proyectos, de acuerdo con nuestro flujo, creamos especialmente un proyecto separado en el que configuramos una plantilla para introducir errores.
• Para calcular los puntos, planearon utilizar una tabla de clasificación que se actualizaba mediante webhooks, pero algo salió mal y al final el cálculo tuvo que hacerse manualmente.

Todo el mundo tiene problemas a la hora de organizar eventos, y para ponértelo un poco más fácil te describiré nuestros problemas que puedes evitar.

Uno de los oradores se enfermó repentinamente y tuvo que buscar uno nuevo..
Tuve mucha suerte de encontrar un sustituto del mismo equipo a las 9 de la mañana). Pero es mejor no confiar en la suerte y tener repuesto. O prepárese para dar usted mismo el informe necesario.

No tuvimos tiempo de implementar la funcionalidad, tuvimos que intercambiar los bloques..
Para evitar tirar un bloque entero, es mejor tener un plan de respaldo.

Algunos usuarios de prueba abandonaron, tuvimos que volver a crear rápidamente otros nuevos..
Verificar previamente a los usuarios de prueba o poder realizarlas rápidamente.

Casi ninguno de los chicos para quienes se simplificó el formato vino.
No es necesario arrastrar a nadie por la fuerza. Sé humilde.
Existe la opción de prescribir estrictamente el formato del evento: “amateur”/“avanzado”, o preparar dos opciones a la vez y decidir cuál realizar después del hecho.

Puntos organizativos útiles:

• reservar una reunión con antelación;
• organice las mesas, no se olvide de los cables de extensión y los protectores contra sobretensiones (cargar computadoras portátiles o teléfonos puede no ser suficiente para todo el día);
• automatizar el proceso de puntuación;
• preparar tablas de clasificación;
• hacer folletos en papel con nombres de usuario y contraseñas de usuarios de prueba, instrucciones para trabajar con Jira, scripts;
• No olvides enviar recordatorios una semana antes del evento y también indicar qué necesitas llevar contigo (portátiles/dispositivos);
• cuénteles a sus colegas sobre el evento en una demostración, en almuerzos, tomando una taza de café;
• acordar con los desarrolladores no actualizar ni implementar nada ese día;
• preparar oradores;
• negociar con los propietarios de funciones y escribir más escenarios para realizar pruebas;
• pedir golosinas (galletas/dulces) como refrigerio;
• No olvides contarnos los resultados del evento.

resultados

Durante todo el día, los chicos lograron probar 4 proyectos y crear 192 errores (134 de ellos únicos) y 7 problemas con solicitudes de funciones. Por supuesto, los propietarios del proyecto ya conocían algunos de estos errores. Pero también hubo hallazgos inesperados.

Todos los participantes recibieron dulces premios.

Y los ganadores son termos, insignias, sudaderas.

Lo que resultó interesante:

• los participantes encontraron inesperado el formato de las sesiones difíciles, cuando el tiempo es limitado y no se puede dedicar mucho tiempo a pensar;
• logró probar la versión de escritorio, móvil y las aplicaciones;
• miramos muchos proyectos a la vez, no había tiempo para aburrirse;
• conocí a diferentes colegas, analicé sus enfoques para introducir errores;
• Sentí todo el dolor de los probadores.

Que se puede mejorar:

• hacer menos proyectos y aumentar el tiempo de la sesión a 1,5 horas;
• preparar regalos/souvenirs con mucha antelación (a veces la aprobación/pago tarda un mes);
• relájate y acepta que algo no saldrá según lo planeado y habrá fuerza mayor.

opiniones

Anna Bystrikova, administradora del sistema: “El asilo es muy educativo para mí. Aprendí el proceso de prueba y sentí todo el "dolor" de los evaluadores.
Al principio, durante el proceso de prueba, como usuario ejemplar, verifica los puntos principales: si se hace clic en el botón, si se accede a la página, si el diseño se ha movido. Pero luego te das cuenta de que necesitas pensar más fuera de lo común e intentar "romper" la aplicación. Los evaluadores tienen un trabajo difícil; no basta con "hurgar" en toda la interfaz; es necesario intentar pensar fuera de lo común y estar extremadamente atento.
Las impresiones fueron sólo positivas, incluso ahora, un tiempo después del evento, veo cómo se está trabajando en los errores que encontré. Es fantástico sentirse involucrado en la mejora del producto ^_^”.

Dmitry Seleznev, desarrollador front-end: “Probar en modo competitivo nos motiva mucho a encontrar más errores). Me parece que todo el mundo debería intentar participar en Baghunting. Las pruebas exploratorias le permiten encontrar aquellos casos que no están descritos en el plan de pruebas. Además, las personas que no conocen el proyecto pueden dar su opinión sobre la conveniencia del servicio”.

Antonina Tatchuk, editora senior: “Me gustó probarme a mí mismo como probador. Este es un estilo de trabajo completamente diferente. Estás intentando romper el sistema, no hacerte amigo de él. Siempre teníamos la oportunidad de preguntar algo a nuestros colegas sobre las pruebas. Aprendí más sobre cómo priorizar errores (por ejemplo, estoy acostumbrado a buscar errores gramaticales en los textos, pero el “peso” de un error de este tipo es muy pequeño; y viceversa, algo que no me parecía muy importante terminó siendo un error crítico, que se solucionó inmediatamente).
En el evento, los chicos dieron un resumen de la teoría de las pruebas. Esto fue útil para personas no técnicas. Y unos días después me sorprendí pensando que estaba escribiendo en apoyo de otro sitio usando la fórmula “qué-dónde-cuándo” y describiendo en detalle mis expectativas respecto del sitio y la realidad”.

Conclusión

Si desea diversificar la vida de su equipo, eche un nuevo vistazo a la funcionalidad, organice un mini "Come tu propia comida para perros", entonces puedes intentar realizar un evento de este tipo y luego podemos discutirlo juntos.

¡Todo lo mejor y menos errores!

Fuente: habr.com