¡Hola a todos! Me llamo Yulia y soy probadora. El año pasado les hablé sobre Bugfest — un evento que organizamos en nuestra empresa para limpiar el backlog de errores. Es una opción completamente viable para reducirlo significativamente (entre un 10 y un 50% en diferentes equipos) en un solo día.

Hoy quiero contarles sobre nuestro formato primaveral de Bugfest — BUgHunting (BUH). Esta vez no arreglamos errores antiguos, sino que buscamos nuevos y propusimos ideas para funciones. A continuación, hay muchos detalles sobre la organización de estos eventos, nuestros resultados y comentarios de los participantes.

Después de planificar y redactar el reglamento, enviamos una invitación a todos los canales en Slack corporativo, en la que no había ninguna restricción:

Al final, se registraron alrededor de 30 personas — tanto desarrolladores como especialistas no técnicos. Se asignó un día laboral completo para el evento, se reservó una sala de reuniones grande y se organizaron almuerzos en la cafetería de la oficina.

¿Por qué?

Aparentemente, cada equipo prueba su funcionalidad. Los usuarios nos reportan errores. ¿Por qué llevar a cabo un evento así?

Teníamos varios objetivos.

1. Acercar a los chicos a proyectos/productos relacionados.
   Actualmente, en nuestra empresa todos trabajan en equipos separados — unidades. Son grupos de proyecto que desarrollan su parte de la funcionalidad y no siempre están completamente al tanto de lo que sucede en otros proyectos.
2. Simplemente presentar a los colegas entre sí.
   Tenemos casi 800 empleados en la oficina de Moscú, no todos los colegas se conocen en persona.
3. Mejorar la habilidad de búsqueda de errores de los desarrolladores en sus productos.
   Actualmente estamos promoviendo la Prueba Ágil y mejorando a los chicos en esta dirección.
4. Involucrar en las pruebas no solo a especialistas técnicos.
   Además del departamento técnico, tenemos muchos colegas de otras especialidades a quienes nos gustaría contarles más sobre las pruebas, sobre cómo reportar errores correctamente, para que recibamos menos mensajes del tipo "Aaaah... nada funciona."
5. Y, por supuesto, encontrar errores astutos y no evidentes.
   Queríamos ayudar a los equipos con las pruebas de nuevas funciones y darles la oportunidad de ver la funcionalidad realizada desde otra perspectiva.

Implementación

Nuestro día se compuso de varios bloques:

• breve informativo;
• una breve conferencia sobre pruebas, en la que solo tocamos los puntos principales (objetivos y principios de las pruebas, etc.);
• una sección sobre «reglas de buena conducta» al registrar errores (aquí principios bien descritos);
• cuatro sesiones de pruebas por proyectos con escenarios descritos a alto nivel; antes de cada sesión se realizó una breve introducción sobre el proyecto y la distribución en equipos;
• una breve encuesta sobre el evento;
• resumen final.

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

Reglas básicas

• La inscripción en los eventos es individual, lo que soluciona el problema de que todo el equipo se desplace por inercia si una persona decide no asistir.
• En cada sesión los participantes cambian de equipo. Esto permite a los participantes entrar y salir en cualquier momento, además de conocer a más personas.
• Comandos dos personas se forman antes de cada sesión de manera aleatoria, lo que resulta más dinámico y rápido.
• Se asignan puntos (de 3 a 10) dependiendo de la criticidad.
• No se asignan puntos por duplicados.
• Los errores deben ser registrados por un miembro del equipo de acuerdo con todos los estándares internos.
• Las solicitudes de características se registran en una tarea separada y participan en una nominación diferente.
• El equipo de auditoría vigila el cumplimiento de todas las reglas.

Otros detalles

• Inicialmente queríamos hacer un evento «avanzado» sobre pruebas, pero dado que se inscribieron bastante gente de equipos no productivos (SMM, abogados, PR), tuvimos que simplificar mucho el contenido y eliminar casos complejos/profesionales.
• Debido al trabajo de las unidades en Jira en diferentes proyectos según sus flujos, creamos un proyecto separado en el que configuramos una plantilla para registrar errores.
• Para contar los puntos, planeábamos utilizar un leaderboard que se actualizara a través de webhooks, pero algo salió mal y al final tuvimos que hacer el conteo manualmente.

Cada organización de eventos enfrenta dificultades y para que te resulte un poco más fácil, describiré nuestros problemas, que podrás evitar.

Uno de los ponentes se enfermó repentinamente y tuvimos que buscar uno nuevo.
Tuve mucha suerte de encontrar un reemplazo del mismo equipo a las 9 de la mañana). Pero es mejor no depender de la suerte y tener un plan B. O estar preparado para dar la charla necesaria.

No logramos implementar la funcionalidad, tuvimos que cambiar los bloques de lugar.
Para no desechar todo un bloque, es mejor tener un plan de respaldo.

Se cayeron algunos usuarios de prueba, tuvimos que recrear nuevos rápidamente..
Verifique a los usuarios de prueba con anticipación o tenga la capacidad de crearlos rápidamente.

Casi nadie de los chicos por quienes se simplificó el formato, vino..
No es necesario arrastrar a nadie por la fuerza. Acepten.
Hay una opción de definir estrictamente el formato del evento: "aficionado"/"avanzado", o preparar dos opciones y decidir cuál llevar a cabo en función de los hechos.

Momentos organizativos útiles:

• reserve la sala de reuniones con antelación;
• organice las mesas, no olvide las extensiones y filtros de red (las cargas de las laptops/teléfonos pueden no ser suficientes para todo el día);
• automatice el proceso de conteo de puntos;
• prepare tablas de clasificación;
• haga copias impresas con los nombres de usuario y contraseñas de los usuarios de prueba, instrucciones para trabajar con Jira, y escenarios;
• no olvide enviar recordatorios una semana antes del evento, y especifique lo que necesita llevar consigo (laptops/dispositivos);
• comente sobre el evento con sus colegas en las demostraciones, durante los almuerzos, con una taza de café;
• coordine con los devops para que no actualicen ni implementen nada ese día;
• prepare a los ponentes;
• coordine con los propietarios de las funciones y redacte más escenarios para las pruebas;
• pida algunos bocadillos (galletas/dulces) para picar;
• no olvide informar sobre los resultados del evento.

Resultados

A lo largo del día, los participantes lograron probar 4 proyectos y crear 192 errores (de los cuales 134 eran únicos) y 7 tareas con solicitudes de funciones. Por supuesto, los propietarios de algunos de estos errores ya estaban al tanto. Pero también hubo hallazgos inesperados.

Todos los participantes recibieron premios dulces.

Y los ganadores, termos, insignias y sudaderas.

Lo que resultó interesante:

• para los participantes fue inesperado el formato de las sesiones estrictas, donde el tiempo es limitado y no se puede dedicar demasiado tiempo a pensar;
• pudimos probar la versión de escritorio, la versión móvil y las aplicaciones;
• vimos muchos proyectos de una sola vez, no hubo tiempo para aburrirse;
• conocimos a diferentes colegas y observamos sus enfoques para registrar errores;
• sentimos todo el dolor de los testers.

Lo que se puede mejorar:

• hacer menos proyectos y aumentar el tiempo de la sesión a 1,5 horas;
• preparar regalos/souvenirs con mucha anticipación (a veces la confirmación/pago se extiende por un mes);
• relajarse y aceptar que algo saldrá no como estaba planeado y habrá imprevistos.

Opiniones

Anna Bystrikova, administradora de sistemas: «La Bugdeliña me ha resultado muy instructiva. Aprendí sobre el proceso de pruebas y sentí todo el 'dolor' de los testers.
Al principio, en el proceso de pruebas, como un usuario típico, revisas los aspectos básicos: si los botones funcionan, si se carga la página, si el diseño se mantiene. Pero luego te das cuenta de que debes pensar de manera más innovadora y tratar de 'romper' la aplicación. El trabajo de los testers no es fácil, no solo se trata de hacer clic por toda la interfaz, hay que esforzarse por pensar de manera no convencional y ser altamente observador.
Las impresiones que quedan son solo positivas, incluso ahora, después de un tiempo desde el evento, veo cómo se trabaja en los errores que encontré. Es genial sentirse parte de la mejora del producto ^_^».

Dmitry Seleznyov, desarrollador frontend: «Las pruebas en un formato de competencia motivan a encontrar más errores). Creo que todos deberían intentar participar en el Bug Hunting. Las pruebas exploratorias permiten descubrir casos que no están descritos en el plan de pruebas. Además, las personas que no conocen el proyecto pueden dar retroalimentación sobre la usabilidad del servicio».

Antonina Tatchuk, editora senior: «Me gustó probarme en el rol de tester. Es un estilo de trabajo completamente diferente. Tratas de romper el sistema, no de hacerte amigo de él. Siempre tuvimos la oportunidad de preguntar a nuestros colegas sobre las pruebas. Aprendí más sobre la priorización de errores (por ejemplo, solía estar atenta a errores gramaticales en los textos, pero 'el peso' de tal error es muy pequeño; y viceversa, algo que a mí me pareció poco importante resultó ser un error crítico que se solucionó de inmediato).
En el evento, los chicos dieron un resumen de la teoría de pruebas. Fue útil para especialistas no técnicos. Y unos días después, me sorprendí pensando que estaba escribiendo al soporte de otro sitio siguiendo la fórmula 'qué-dónde-cuándo' y describiendo en detalle mis expectativas del sitio y la realidad».

Conclusión

Si quieres diversificar la vida del equipo, mirar la funcionalidad con una nueva perspectiva, organizar un mini «Come tu comida de perro», entonces puedes intentar llevar a cabo un evento así y luego podemos discutirlo juntos.

¡Saludos a todos y que haya menos errores!

Fuente: habr.com