Hola a todos! Mi nombre es Julia y soy tester. El año pasado les conté sobre Bagelnya , un evento realizado en nuestra empresa para limpiar la acumulación de errores. Esta es una opción completamente viable para reducirla significativamente (en diferentes equipos del 10 al 50%) en solo un día.

Hoy quiero contarles sobre nuestro formato de primavera de la tienda de equipaje - BUgHunting (BUH). Esta vez no solucionamos errores antiguos, sino que buscamos nuevos y ofrecimos ideas para las funciones. Debajo del corte, muchos detalles sobre la organización de tales eventos, nuestros resultados y los comentarios de los participantes.

Después de pensar y prescribir las reglas, enviamos una invitación a todos los canales en el Slack corporativo, en el que no había restricciones:

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

Por qué

Parece que cada equipo está probando su funcionalidad. Los usuarios nos reportarán errores. ¿Por qué incluso celebrar tal evento?

Teníamos varios objetivos.

1. Presente a los chicos más cerca de proyectos / productos relacionados .
   Ahora en nuestra compañía todos trabajan en equipos separados - unidades. Estos son equipos de diseño que vieron su parte de la funcionalidad y no siempre son plenamente conscientes de lo que está sucediendo en otros proyectos.
2. Simplemente presente a sus colegas entre sí .
   Tenemos casi 800 empleados en la oficina de Moscú, no todos los colegas se conocen en persona.
3. Mejore la habilidad de buscar errores entre los desarrolladores en sus productos .
   Actualmente estamos promoviendo Agile Testing y estamos impulsando a los chicos en esta dirección.
4. Involucrar no solo a expertos técnicos en pruebas .
   Además del departamento técnico, tenemos muchos colegas de otras especialidades que querían hablar más sobre las pruebas, sobre cómo informar correctamente, para que recibamos menos mensajes en el formato "Ahhh ... nada funciona".
5. Bueno, por supuesto, encuentra errores difíciles y obvios .
   Quería ayudar a los equipos a probar nuevas características y ofrecer la oportunidad de ver la funcionalidad implementada desde un ángulo diferente.

Implementación

Nuestro día consistió en varios bloques:

• información
• Una breve conferencia sobre las pruebas, en la que tocamos solo los puntos principales (objetivos y principios de las pruebas, etc.);
• sección sobre los "buenos modales" al instituir errores (los principios están bien descritos aquí );
• cuatro sesiones de prueba para proyectos con scripts de alto nivel; antes de cada sesión hubo una breve conferencia introductoria sobre el proyecto y distribución a los equipos;
• una breve encuesta del evento;
• resumiendo

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

Reglas básicas

• La inscripción para eventos es individual , lo que resuelve el problema de agotar la inercia de todo el equipo si una persona decide no asistir.
• Cada sesión, los participantes cambian el equipo . Esto permite a los participantes salir y venir en cualquier momento, y también puede familiarizarse con una gran cantidad de personas.
• Los equipos de dos personas antes de cada sesión se forman al azar , por lo que resulta más dinámico y más rápido.
• Se otorgan puntos por errores terminados (de 3 a 10) dependiendo de la criticidad .
• No se otorgan puntos por dobles.
• Los errores deben ser iniciados por un miembro del equipo de acuerdo con todos los estándares internos.
• Featurekvesta se inicia en una tarea separada y participa en una nominación separada.
• El cumplimiento del cumplimiento de todas las reglas es monitoreado por el equipo de auditoría.

Otros detalles

• Inicialmente, quería hacer un evento de prueba "avanzado", pero porque se inscribieron muchos tipos de equipos no productivos (SMM, abogados, relaciones públicas), tuve que simplificar enormemente el contenido y eliminar casos complejos / especializados.
• Debido al trabajo de las unidades en Jira en diferentes proyectos, de acuerdo con nuestro flujo, realizamos un proyecto por separado en el que configuramos una plantilla para crear errores.
• Para la puntuación, planeamos usar una tabla de clasificación, que se actualizó a través de webhooks, pero algo salió mal y, como resultado, el cálculo tuvo que hacerse manualmente.

Al organizar eventos, todos se topan con un rastrillo y, para hacerlo un poco más fácil, describiré nuestros problemas que puede evitar.

Uno de los oradores se enfermó repentinamente y tuvo que buscar uno nuevo .
Tuve mucha suerte de encontrar un reemplazo del mismo equipo a las 9 a.m.). Pero es mejor no confiar en la suerte y tener un repuesto. O usted mismo para estar listo para contar el informe deseado.

No logramos implementar la funcionalidad, tuvimos que intercambiar bloques .
Para no tirar todo el bloque, es mejor tener un plan de respaldo.

Algunos de los usuarios de prueba cayeron, tuve que recrear rápidamente otros nuevos .
Vuelva a consultar a los usuarios de prueba por adelantado o tenga la oportunidad de hacerlos rápidamente.

Casi ninguno de los chicos para quienes el formato fue simplificado vino .
No tienes que arrastrar a nadie por la fuerza. Humíllate.
Existe la opción de prescribir rígidamente el formato del evento: "aficionado" / "avanzado", o preparar dos opciones a la vez y decidir qué llevar a cabo.

Puntos organizativos útiles:

• reservar una sala de reuniones con anticipación;
• arregle las mesas, no se olvide de los cables de extensión y los protectores contra sobretensiones (cargar computadoras portátiles / teléfonos durante todo el día puede no ser suficiente);
• Automatizar el proceso de puntuación;
• preparar tablas de calificación;
• hacer folletos en papel con inicios de sesión y contraseñas de usuarios de prueba, instrucciones para trabajar con Jira, scripts;
• No olvide enviar recordatorios una semana antes del evento, además indique lo que necesita traer (computadoras portátiles / dispositivos);
• cuénteles a sus colegas sobre el evento en una demostración, en cenas, con una taza de café;
• acuerde con los devops no actualizar ni implementar nada en este día;
• preparar oradores;
• estar de acuerdo con los propietarios de las funciones y escribir más scripts para probar;
• pedir bocadillos (galletas / dulces) para bocadillos;
• No te olvides de hablar sobre el resultado del evento.

Resultados

Durante todo el día, los chicos lograron probar 4 proyectos y obtener 192 errores (de los cuales 134 son únicos) y 7 tareas con solicitudes de características. Por supuesto, los propietarios de proyectos ya sabían sobre algunos de estos errores. Pero hubo hallazgos inesperados.

Todos los participantes recibieron dulces premios.

Y los ganadores son termos, insignias, sudaderas.

Lo que resultó interesante:

• el formato de las sesiones difíciles fue inesperado para los participantes, cuando el tiempo es limitado y no se puede pasar mucho tiempo pensando en ello;
• Logré probar el escritorio, la versión móvil y las aplicaciones;
• miró muchos proyectos a la vez, no había tiempo para aburrirse;
• se reunió con diferentes colegas, examinó sus enfoques para el establecimiento de errores;
• sintió el dolor de los probadores.

Qué se puede mejorar:

• hacer menos proyectos y aumentar el tiempo de sesión a 1.5 horas;
• preparar regalos / recuerdos con mucha anticipación (a veces la coordinación / pago dura un mes);
• relájese y acepte el hecho de que algo saldrá mal y habrá fuerza mayor.

Comentarios

Anna Bystrikova, administradora del sistema: “La tienda de equipaje es muy informativa para mí. Aprendí el proceso de prueba, sentí todo el "dolor" de los probadores.
Al principio, durante el proceso de prueba, como usuario aproximado, verifica los puntos principales: toca el botón, va a la página, se mueve el diseño. Pero más tarde comprende que necesita pensar de manera no estándar e intentar "romper" la aplicación. Los probadores tienen un trabajo difícil, poco para "perforar" toda la interfaz, debe tratar de pensar fuera de la caja y estar extremadamente atento.
Solo quedaron impresiones positivas, incluso ahora, algún tiempo después del evento, veo cómo se está trabajando en los errores que encontré. Es genial sentirse involucrado en mejorar un producto ^ _ ^ ".

Dmitry Seleznev, desarrollador front-end : "Las pruebas en modo competitivo motivan en gran medida a encontrar más errores". Me parece que todos deben intentar participar en Baghanting. Las pruebas de investigación le permiten encontrar aquellos casos que no se describen 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 gustaba probarme a mí misma como probador. Este es un estilo de trabajo completamente diferente. Estás intentando romper el sistema, no hacer amigos con él. Siempre tuvimos la oportunidad de preguntarles a nuestros colegas algo sobre las pruebas. Aprendí más sobre priorizar errores (por ejemplo, estoy acostumbrado a buscar errores gramaticales en los textos, pero el "peso" de dicho error es muy pequeño; y viceversa, algo que me pareció poco importante resultó ser un error crítico que se solucionó de inmediato )
En el evento, los muchachos le dieron un apretón a la teoría de las pruebas. Esto fue útil para profesionales no técnicos. 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 describía en detalle mis expectativas del sitio y la realidad ".

Conclusión

Si desea diversificar la vida del equipo, mire con una nueva visión de la funcionalidad, organice un mini "Coma su propia comida para perros" , luego puede tratar de llevar a cabo tal evento, y luego podemos discutirlo juntos.

¡Todos buenos y menos errores!